
PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin - zdw
https://github.com/PurritoBin/PurritoBin
======
rakoo
> openssl enc blablabla

 _Don 't_ use that line for encrypting stuff. There is no authentication and
the IV is static. You're just asking for your secrets to be decrypted or
modified without anyone noticing

~~~
tialaramex
The static IV is a brown M&M but not in itself fatal because this seems to use
fresh random keys each time. If your keys end up re-used (NB don't fret about
somehow choosing the same random key as somebody else that's astronomically
unlikely, but _do_ fret about your choices not actually being random after
all) then you're screwed anyway.

There's no obvious route to decrypt these messages without the secret key,
though it's up to you to not send that key anywhere (HTTP clients don't send
fragment identifiers as part of the HTTP request, but of course a _Javascript-
enabled_ client can be instructed with Javascript to simply inspect the whole
URL...)

The lack of authentication does mean you have no reason whatsoever to be sure
this is the message intended. Regardless of IV anyone with control over the
encrypted data gets to selectively alter the plaintext you'll decrypt even
though they can't read it.

~~~
rakoo
Indeed in that particular case since key is randomly generated it's ok to have
a static IV. However I feel it's important to understand why it's ok in that
case; in the general case, even though it's not technically required, it's
always easier to have a random IV

------
joan_kode
This is neat and has potential. But I was somewhat arrested by this feature:

" _all pastes are cleared daily at 1:30am EST, so you have 12 hrs on average
for your paste_ "

So, 12 hours on average... zero seconds if you're unlucky.

~~~
CodeWriter23
> zero seconds if you're unlucky.

Predictably unlucky by putting your paste in at 1:30 EST. But yeah, why not
timestamp each record and give it a 24hr TTL?

------
slykar
> When you visit the html webpage the key is in the hash property of the
> webpage, which is never sent to the server.

So it's only safe if you trust the server, which kind of defies the purpose?

~~~
joan_kode
The command line version actually allows you to "not trust the server". But
thinking it through I agree that the in-browser version could get served a
different JS that grabs the hash and sends it to the server. This would be
easily detectable, but it does seem like problem with the concept.

~~~
nullc
> This would be easily detectable, but it does seem like problem with the
> concept.

I think it would be better to describe it as detectable but not practically
so.

There have been many javascript "bitcoin wallet generators" that defrauded
users this way. In both cases where they were backdoored from day one and
cases where they changed the code later (sometimes on the fly based on
useragent and referrer!) the detection has always been from users noticing
their coins were stolen.

Its simply too difficult to review a javascript application given the ubiquity
of deeply nested superfluous dependencies and toolkits-- and too pointless
given that the code can be selectively substituted any any time, so almost no
one does the review.

~~~
joan_kode
You're right, too late to edit but the "easily" was wrong. More like
"theoretically".

------
pwdisswordfish2
The author calls this "command line" pastebin. It uses curl and openssl to
encrypt and submit. However it uses a Javascript-enabled web broswer to do the
retrieval and decryption. Can we use the command line to do the retrieval and
decryption?

This way, we are not restricted to the ciphers supported by the "Crypto-JS"
NodeJS package. Not meaning to take anything away from the venerable Crypto-JS
library of "standards" including RC4 and TripleDES.

~~~
faaabio1618
You have missed the "meow" command.

~~~
pwdisswordfish2
No, that is an incorrect assumption. The meow command does not decrypt data.
The author is suggesting that users resort to using a web browser and Crypto-
JS in order to decrypt.

------
StavrosK
Is encryption a popular requirement? I made (and thus prefer)
[https://www.pastery.net/](https://www.pastery.net/), but nobody has asked me
to add encryption, I assume that privacy (not having a list of pastes anywhere
and deleting them from disk when they expire) is enough, at least for me.

~~~
tialaramex
I can think of one very good reason to have clients encrypt pastes for you as
service provider:

If the pastes are encrypted by somebody else you simply have no idea what's
inside them. You can easily find an expert who will explain to a jury, or a
journalist, that you had no way to know it was an assassination plot / stolen
bitcoin wallet / confession of child molestation. I'm sure you don't look
(other people's business is quickly boring) but it may be difficult today to
prove you didn't, because you could have.

But in terms of what I've used, in some tech jobs I've used in-house HTTPS
pastebin sites. If we control the machine with the data in it then we get to
decide what policies to apply, and if things go bad we know who (us) needs to
fix that. In the last place I worked they used GitHub gists, so in principle
Microsoft could snoop those and I'd have been uncomfortable seeing anything
secret in them.

------
vesche
[http://ix.io/](http://ix.io/)

~~~
zdw
Also [https://0x0.st](https://0x0.st)

which has source available here:
[https://github.com/mia-0/0x0](https://github.com/mia-0/0x0)

------
throwawaygo
This is some scary shit. Don't use this.

~~~
smabie
Why's that?

