3 ms·

Are you saying the hash I mentioned doesn't prevent tampering? And I thought xoring them forces attackers to have to break all of the ciphers instead of just o

Are you saying the hash I mentioned doesn't prevent tampering? And I thought xoring them forces attackers to have to break all of the ciphers instead of just one. That seems pretty useful.

Retr0id 3y ago
If you hashed the plaintext, you leak information about the plaintext, and depending on the hash it's vulnerable to length extension attacks. If you hashed the ciphertext then anyone can re-hash a modified version. What you're looking for is a HMAC, which works, but it's usually slower than a block mode that integrates authentication functionality (like OCB, or GCM). It's true that you'd have to break all the ciphers, but we're generally very confident about the security of our symmetric ciphers, so unless you're very paranoid it's just a waste of clock cycles,
- dataflow 3y ago
  I think you misunderstood what I wrote. What I said was you finish off by hashing the plaintext and xoring it with the final chunk of your random stream. So you're not sending over the hash itself, but the encryption of it. I don't buy the confidence thing but sure.
  - Retr0id 3y ago
    This violates the Cryptographic Doom Principle https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...
    - dataflow 3y ago
      That's about padding (in CBC), IIUC. There was no padding in what I wrote. If you believe what I wrote is vulnerable to that could you explain how?
      - tptacek 3y ago
        No, it's not. CBC padding oracles are just the most popular incarnation of the underlying problem. https://crypto.stanford.edu/RealWorldCrypto/slides/phil.pdf https://crypto.stanford.edu/RealWorldCrypto/slides/phil.pdf
  - tptacek 3y ago
    A hash of the plaintext isn't an authenticator; it doesn't have a key, so anybody can compute the hash of an intended plaintext. The CTR cipher by itself is very malleable; if you know a run of plaintext characters, you can rewrite it to anything with XOR: https://cryptopals.com/sets/4/challenges/26 https://cryptopals.com/sets/4/challenges/26 You could CTR-encrypt a message, and then use a hash function in an HMAC construction. HMAC takes a secret key, so an attacker can't compute the HMAC of some other message and swap it in. CTR+HMAC is pretty common, though it's a design smell in a modern system, virtually all of which use AEADs rather than hand-rolled ("generic composition") systems.
    - dataflow 3y ago
      I'm not following unfortunately. To be clear, what I'm saying is ciphertext = Encrypt(plaintext || Hash(plaintext)) where Encrypt(data_stream)[i] = data_stream[i] XOR random_stream[i]. I'm not following how an attacker can tamper or decipher anything in the ciphertext here. The moment you tamper with any bit, the hash would become invalid. You can XOR it with whatever you want but you can't turn it into anything valid... right? What am I missing?
      - tptacek 3y ago
        If you know the plaintext, you know the hash of the plaintext, because the hash doesn't have a key. Encrypt() is CTR, so you can flip bits in ciphertext to alter the same bits in the plaintext. You know the plaintext and the hash and you know where the hash is, so you can mechanically rewrite the hash to be whatever you need it to be. You can prove this to yourself in Python or Ruby or whatever: just CTR-encrypt "We all live in a yellow submarine", along with its hash. Then bitflip "yellow" to "orange", compute the hash for "We all live in a orange submarine" (ignore the grammar), and bitflip that into the original hash. There are formalisms to why hash-then-encrypt is unsafe that I'm not giving you here, because I'm not smart enough to pull them out of the top of my head, but the scenario I just described is already a game-over vulnerability in many settings; a similar fact pattern has broken lots of encrypted cookie schemes, which you do in fact know the plaintext, and some bit of the plaintext (like "admin=n") happens to be incovenient to attackers.

Are you saying the hash I mentioned doesn't prevent tampering? And I thought xoring them forces attackers to have to break all of the ciphers instead of just one. That seems pretty useful.

Retr0id 3y ago

If you hashed the plaintext, you leak information about the plaintext, and depending on the hash it's vulnerable to length extension attacks. If you hashed the ciphertext then anyone can re-hash a modified version. What you're looking for is a HMAC, which works, but it's usually slower than a block mode that integrates authentication functionality (like OCB, or GCM). It's true that you'd have to break all the ciphers, but we're generally very confident about the security of our symmetric ciphers, so unless you're very paranoid it's just a waste of clock cycles,

dataflow 3y ago
I think you misunderstood what I wrote. What I said was you finish off by hashing the plaintext and xoring it with the final chunk of your random stream. So you're not sending over the hash itself, but the encryption of it. I don't buy the confidence thing but sure.
- Retr0id 3y ago
  This violates the Cryptographic Doom Principle https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...
  - dataflow 3y ago
    That's about padding (in CBC), IIUC. There was no padding in what I wrote. If you believe what I wrote is vulnerable to that could you explain how?
    - tptacek 3y ago
      No, it's not. CBC padding oracles are just the most popular incarnation of the underlying problem. https://crypto.stanford.edu/RealWorldCrypto/slides/phil.pdf https://crypto.stanford.edu/RealWorldCrypto/slides/phil.pdf
- tptacek 3y ago
  A hash of the plaintext isn't an authenticator; it doesn't have a key, so anybody can compute the hash of an intended plaintext. The CTR cipher by itself is very malleable; if you know a run of plaintext characters, you can rewrite it to anything with XOR: https://cryptopals.com/sets/4/challenges/26 https://cryptopals.com/sets/4/challenges/26 You could CTR-encrypt a message, and then use a hash function in an HMAC construction. HMAC takes a secret key, so an attacker can't compute the HMAC of some other message and swap it in. CTR+HMAC is pretty common, though it's a design smell in a modern system, virtually all of which use AEADs rather than hand-rolled ("generic composition") systems.
  - dataflow 3y ago
    I'm not following unfortunately. To be clear, what I'm saying is ciphertext = Encrypt(plaintext || Hash(plaintext)) where Encrypt(data_stream)[i] = data_stream[i] XOR random_stream[i]. I'm not following how an attacker can tamper or decipher anything in the ciphertext here. The moment you tamper with any bit, the hash would become invalid. You can XOR it with whatever you want but you can't turn it into anything valid... right? What am I missing?
    - tptacek 3y ago
      If you know the plaintext, you know the hash of the plaintext, because the hash doesn't have a key. Encrypt() is CTR, so you can flip bits in ciphertext to alter the same bits in the plaintext. You know the plaintext and the hash and you know where the hash is, so you can mechanically rewrite the hash to be whatever you need it to be. You can prove this to yourself in Python or Ruby or whatever: just CTR-encrypt "We all live in a yellow submarine", along with its hash. Then bitflip "yellow" to "orange", compute the hash for "We all live in a orange submarine" (ignore the grammar), and bitflip that into the original hash. There are formalisms to why hash-then-encrypt is unsafe that I'm not giving you here, because I'm not smart enough to pull them out of the top of my head, but the scenario I just described is already a game-over vulnerability in many settings; a similar fact pattern has broken lots of encrypted cookie schemes, which you do in fact know the plaintext, and some bit of the plaintext (like "admin=n") happens to be incovenient to attackers.