PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin

https://github.com/PurritoBin/PurritoBin

by zdw • 6 years ago

74 27 6 years ago

github.com

slykar• 6 years ago

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_kode3• 6 years ago

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• 6 years ago

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_kode3• 6 years ago

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.

philipkiely• 6 years ago

Yeah, this is clearly a situation where average is not the most meaningful metric.

CodeWriter23• 6 years ago

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?

rakoo4• 6 years ago

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

philplckthun• 6 years ago

Genuinely ignorant here and curious, would using OpenSSL’s salt option help here? I’m not quite sure why the instructions in the repo specify a fixed IV to begin with

rakoo4• 6 years ago

Just don't use openssl's command line for encrypting anything, there are better tools for that.

My guess is that the fixed IV is used because the IV is needed for decrypting, which means either you prepend the ciphertext with it (which means you need to buffer the whole ciphertext in memory, defeating the streaming functionality of the service) or you already know it because it's hardcoded.

In any case there is no authentication of the encrypted payload, so you have no idea if what you received really is encrypted by the person that claims to be the sender or if it was modified somewhere in the middle.

tialaramex2• 6 years ago

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.

rakoo4• 6 years ago

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

vesche• 6 years ago

http://ix.io/

zdw• 6 years ago

Also https://0x0.st

which has source available here: https://github.com/mia-0/0x0

StavrosK• 6 years ago

Is encryption a popular requirement? I made (and thus prefer) 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.

tialaramex2• 6 years ago

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.

pwdisswordfish22• 6 years ago

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• 6 years ago

You have missed the "meow" command.

pwdisswordfish22• 6 years ago

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.

throwawaygo• 6 years ago

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

smabie• 6 years ago

Why's that?

PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin

Related Stories