pgpfan:seip
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| pgpfan:seip [2024/10/10 15:27] – [Protection] Sounded editorial and was confusing. Create narrative arc. 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: | ||
| //< | //< | ||
| - | 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, | 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, | ||
| Line 104: | Line 104: | ||
| ===Creation=== | ===Creation=== | ||
| - | {{seip_cre.svg}} | + | {{seip_cre.svg}}\\ |
| //< | //< | ||
| Line 173: | 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/ | 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/ | ||
| + | |||
| + | A bit of insight from this discussion... The damage amplification of CFB is helpful here but would not have been as helpful if " | ||
| [[pgpfan: | [[pgpfan: | ||
pgpfan/seip.1728574024.txt.gz · Last modified: by b.walzer