5 ms·

> 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 de

• philplckthun 6y 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
  • rakoo 6y 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.
    • gruez 6y ago
      >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?
      • LeoPanthera 6y ago
        You can specify an IV with -iv. If you don't, the IV is derived from the password.
      • rakoo 6y ago
        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 https://github.com/FiloSottile/age)
    • ta17711771 6y ago
      Just don't use OpenSSL for anything - how many times does the community have to be burned by the same project before they switch?
      • cjones26 6y ago
        What's a good alternative?
        • ta17711771 6y ago
          libressl is the only one I'm aware of.
• tialaramex 6y 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.
  • rakoo 6y 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