Differences

This shows you the differences between two versions of the page.

--- pgpfan:seip [2024/09/11 22:42] – [SEIP for TLS] We are not doing advocacy here. b.walzer
+++ pgpfan:seip [2026/03/14 17:55] (current) – [The Output Feedback (OFB) Block Cipher Mode] Missed a detail. b.walzer
@@ Line 14: / Line 14: @@
 //<sub>Output Feedback (OFB)</sub>//
-We start with a 128 bit Initialization Vector (IV) (any previously unused 128 bits) and encrypt it using the key to produce the first 128 bits of the Bitstream. Then we take the first segment of the Bitstream and encrypt it. We encrypt the IV over and over again until we have a long enough Bitstream. Then we XOR the Bitstream with the Plaintext to produce the Ciphertext. The interesting thing here is that we are not actually using the encryption function to encrypt anything we care about. We are using the encryption function to do something else and then use that result to do the actual encryption. We don't even need a separate decryption function for OFB. When we want the plaintext back we just use the key to generate the Bitstream again and XOR it with the Ciphertext. That is based on a helpful property of the XOR function. If you XOR something with the same bitstream twice, you end up with what you started with.
+We start with a 128 bit Initialization Vector (IV) (any previously unused 128 bits) and encrypt it using the key to produce the first 128 bits of the Bitstream. Then we take the first segment of the Bitstream and encrypt it. We encrypt the IV over and over again until we have a long enough Bitstream. Then we XOR the Bitstream with the Plaintext to produce the Ciphertext. The interesting thing here is that we are not actually using the encryption function to encrypt anything we care about. We are using the encryption function to do something else and then use that result to do the actual encryption. We don't even need a separate decryption function for OFB. When we want the plaintext back we just use the key and IV to generate the Bitstream again and XOR it with the Ciphertext. That is based on a helpful property of the XOR function. If you XOR something with the same bitstream twice, you end up with what you started with.
 The OFB mode has a fairly serious failure possibility. If you use the same IV and key on two or more messages then you get the same bitstream which causes, essentially, one-time pad key reuse. An unhelpful property of the XOR function is that when you XOR two ciphertexts that were produced with the same bitstream, the bitstream cancels out. You are left with the two plaintexts XORed together. Separating such combined plaintexts is usually not very hard.
@@ Line 40: / Line 40: @@
 //<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}}\\
@@ Line 104: / Line 104: @@
 ===Creation===
-{{seip_cre.svg}}
+{{seip_cre.svg}}\\
 //<sub>Protection against creation</sub>//
@@ Line 111: / Line 111: @@
 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====
@@ Line 131: / Line 133: @@
 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====
@@ Line 171: / Line 173: @@
 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]]\\