| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| pgpfan:seip [2024/09/11 22:42] – [SEIP for TLS] We are not doing advocacy here. b.walzer | pgpfan:seip [2024/10/10 15:37] (current) – [SEIP for TLS] Consistency. b.walzer |
|---|
| //<sub>OpenPGP's CFB prefix</sub>// | //<sub>OpenPGP's CFB prefix</sub>// |
| |
| The original IV is replaced with zeros and the IV is shifted down to the first part of the message. Encrypting zeros is a common way to generate a new key from the existing key. For example, the popular [[wp>Galois/Counter_Mode|Galois/counter]] (GCM) block cipher mode does this to generate the key for the GHASH used. Encrypting zeros can be thought of as hashing the key using the [[wp>One-way_compression_function#Davies–Meyer|Davies-Meyer]] method. So we can redraw the diagram to make it easier to understand: | The original IV is replaced with zeros and the IV is shifted down to the first part of the message. Encrypting zeros is a common way to generate a new key from the existing key. For example, the popular [[wp>Galois/Counter_Mode|Galois/counter]] (GCM) block cipher mode does this to generate the key for the GHASH used. The [[https://www.cs.ucdavis.edu/~rogaway/ocb/|OCB]] mode does this to prevent attacker knowledge of of the Δ chain. Encrypting zeros can be thought of as hashing the key using the [[wp>One-way_compression_function#Davies–Meyer|Davies-Meyer]] method. So we can redraw the diagram to make it easier to understand: |
| |
| {{ocfb_hash_se.svg}}\\ | {{ocfb_hash_se.svg}}\\ |
| This sort of attack is not possible in the case of SEIP. The attacker can get the victim to create a new MDC for them (the MDC is not protected against creation). The secret IV is not encrypted in the same way as the Plaintext (and is thus protected). If the attacker embeds an entire valid message, IV and all, inside the message the victim creates for them, then the IV will eventually get decrypted in a different way than it was encrypted. Alternatively, if the attacker lets the victim encrypt the IV for them, then the attacker will not know what the IV was to start with (the victim provides it) and will not be able to create a valid MDC. | This sort of attack is not possible in the case of SEIP. The attacker can get the victim to create a new MDC for them (the MDC is not protected against creation). The secret IV is not encrypted in the same way as the Plaintext (and is thus protected). If the attacker embeds an entire valid message, IV and all, inside the message the victim creates for them, then the IV will eventually get decrypted in a different way than it was encrypted. Alternatively, if the attacker lets the victim encrypt the IV for them, then the attacker will not know what the IV was to start with (the victim provides it) and will not be able to create a valid MDC. |
| |
| If the attacker knows the secret IV then they can probably create a new and valid message. So IV disclosure is significant at this level of threat. Still, the situation where the attacker can make the victim encrypt messages for them is fairly unlikely. It seems to me that, overall, SEIP is better than GCM((I acknowledge that GCM is not all that popular in some circles. But what other popular cipher block mode is available right now for use as a counterexample?)) for IV misuse considering how much worse GCM is than SEIP on IV reuse. | If the attacker knows the secret IV then they can probably create a new and valid message. So IV disclosure is significant at this level of threat. |
| | |
| | If an attacker could somehow come up with an encrypted suffix with appropriately encrypted MDC, splicing that suffix on the end of an existing message to extend it would result in a block of damage. The MDC would pick that block up and fail the modification detection in a way the attacker could not anticipate. So it is very possible that damage amplification could save the day for message creation if an attacker becomes aware of the secret IV. |
| |
| ====Luck==== | ====Luck==== |
| I have to admit that this seems more straightforward than all the stuff about protection. But be careful here. Most are not very knowledgeable about the properties of a MAC buried under the encryption. A MAC is most often used where the material being MACed and the MAC tag are available to the attacker. That is not the case here. I would like to think that the protection discussion is better for ultimately understanding //why// things work the way they do verses //what// results things provide. That was certainly the case for me while developing the protection discussion. | I have to admit that this seems more straightforward than all the stuff about protection. But be careful here. Most are not very knowledgeable about the properties of a MAC buried under the encryption. A MAC is most often used where the material being MACed and the MAC tag are available to the attacker. That is not the case here. I would like to think that the protection discussion is better for ultimately understanding //why// things work the way they do verses //what// results things provide. That was certainly the case for me while developing the protection discussion. |
| |
| It should be pointed out that SEIP, while using a hash, is not an [[wp>HMAC|HMAC]] as such things are normally understood. The most significant difference is that the internal state of the hash is disguised in a different way to prevent length extension attacks. An HMAC does this by hashing in a secret key to the output of the hash of the protected material. SEIP instead encrypts the output of the hash of the protected material, thus preventing attacker access in the first place. It seems to me at least, that it is easy to understand why encrypting the hash prevents length extension. Preventing attacker knowledge of a value is after all the primary function of encryption. Easier than understanding why rehashing the hash in an HMAC prevents length extension where we are ultimately using the output of the same hash we are protecting. | It should be pointed out that SEIP, while using a hash, is not an [[wp>HMAC|HMAC]] as such things are normally understood. The most significant difference is that the internal state of the hash is disguised in a different way to prevent length extension attacks. An HMAC does this by hashing in a secret key to the output of the hash of the protected material. SEIP instead encrypts the output of the hash of the protected material, thus preventing attacker access in the first place. It seems to me at least, that it is easy to understand why encrypting the hash prevents length extension. Preventing attacker knowledge of a value is after all the primary function of encryption. Easier than understanding why rehashing the hash in an HMAC prevents length extension where we are ultimately using the output of the same type of hash we are protecting. |
| |
| The CFB damage amplification is beneficial here as well. If an attacker could somehow come up with an encrypted suffix with appropriately encrypted MDC, splicing that suffix on the end of an existing message to extend it would result in a block of damage. The MDC would pick that block up and fail the modification detection in a way the attacker could not anticipate. | The topic of key committing block cipher modes is popular right now (2024)((Much of the excitement seems to have come from: [[https://eprint.iacr.org/2019/016.pdf|Fast Message Franking: From Invisible Salamanders to Encryptment]])). This property ends up being related to MAC behaviour in most contemporary block cipher modes so this is as good a place as any to have the discussion. A key committing block cipher mode will make it impossible for an attacker to produce a message that will pass the integrity check with two different keys. The SEIP mode is key committing for a simple, easy to understand, reason. SEIP decrypts first and then checks for modifications using the MDC (MAC then encrypt). Changing the key used to decrypt a message with SEIP changes, well, everything. The plaintext and the MDC change to entirely different values in a very complicated, unpredictable, way. The encrypted IV changes as well, but in a predictable way. Then the MDC check is applied to the wreckage. An attacker would have a very difficult time coming up with two keys that would cause the eventual MDC to pass. If the MAC had been done first on decryption (encrypt then MAC) as, say, GCM does, then the attacker would only have to figure out how to come up with two keys that would produce the same MAC value. With the GHASH used for GCM this is fairly easy. As a result, GCM is not key committing. |
| |
| ====Hash Properties==== | ====Hash Properties==== |
| |
| Up to this point we assumed a cipher with 128 bit blocks. The OpenPGP standard supports ciphers with 64 bit blocks. Use of a 64 bit cipher in a SEIP formatted message would result in the secret IV only being 64 bits long. So the strength of the modification detection would be reduced. It's not clear to me that SEIP with 64 bit blocks is something that anyone ever implemented and that such messages/files were ever generated. This is still an important point as a dependency on block size for modification detection strength is not something that anyone would expect. | Up to this point we assumed a cipher with 128 bit blocks. The OpenPGP standard supports ciphers with 64 bit blocks. Use of a 64 bit cipher in a SEIP formatted message would result in the secret IV only being 64 bits long. So the strength of the modification detection would be reduced. It's not clear to me that SEIP with 64 bit blocks is something that anyone ever implemented and that such messages/files were ever generated. This is still an important point as a dependency on block size for modification detection strength is not something that anyone would expect. |
| | |
| | A bit of insight from this discussion... The damage amplification of CFB is helpful here but would not have been as helpful if "encrypt then MAC" had been used. So "MAC/hash then encrypt" is synergistic with damage amplification. The OCB mode seems to me to be an extreme version of this principle. It could be classed as a "XOR then encrypt" mode. There is no MAC/hash used as all, OCB simply XORs the plaintext together to create a checksum and then encrypts the whole message. It seems to rely on the superior damage amplification of the ECB (electronic code book) mode to make this effective. |
| |
| [[pgpfan:index|PGP FAN index]]\\ | [[pgpfan:index|PGP FAN index]]\\ |
