> 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
PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
11–20 of 30 posts
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#12Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#13> 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
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
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.
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#14Earlier quoted context omitted.
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 au…
Can't you generate an IV, write it out to the stream, then encrypt/write the ciphertext?
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#15http://ix.io/
which has source available here: https://github.com/mia-0/0x0
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#16Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#17Earlier quoted context omitted.
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 au…
>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?
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#18> 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
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.
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#19Earlier quoted context omitted.
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 detectio…
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#20Earlier quoted context omitted.
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 au…