PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin(github.com)
github.com
PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
https://github.com/PurritoBin/PurritoBin
7 comments
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.
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.
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
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
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.
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.
>which means you need to buffer the whole ciphertext in memory, defeating the streaming functionality of the service
Can't you generate an IV, write it out to the stream, then encrypt/write the ciphertext?
Can't you generate an IV, write it out to the stream, then encrypt/write the ciphertext?
You could indeed, I didn't think of that. But it starts to beheavier and heavier, and the risk of making subtle mistakes increases. That's why it's better to use tools that do it properly, like age (https://github.com/FiloSottile/age)
You can specify an IV with -iv. If you don't, the IV is derived from the password.
Just don't use OpenSSL for anything - how many times does the community have to be burned by the same project before they switch?
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.
"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.
> 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?
Predictably unlucky by putting your paste in at 1:30 EST. But yeah, why not timestamp each record and give it a 24hr TTL?
Yeah, this is clearly a situation where average is not the most meaningful metric.
> 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?
So it's only safe if you trust the server, which kind of defies the purpose?
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.
> 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.
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.
You're right, too late to edit but the "easily" was wrong. More like "theoretically".
[deleted]
[deleted]
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.
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.
You have missed the "meow" command.
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.
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.
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.
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.
Also https://0x0.st
which has source available here: https://github.com/mia-0/0x0
which has source available here: https://github.com/mia-0/0x0
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