4 ms·

That wiki went over my (fairly) technical head. Care to ELI5?

msm_ 3y ago
My attempt of explanation with a (hopefully) relatable example: imagine that you store all your backup files encrypted, then restore the backup on your machine. The backup is stored on untrusted NAS but it's OK since it's encrypted, right? With OFB (and CTR, and any other unauthenticated cipher basically), no. Ciphers guarantee confidentiality, but nothing else. This means that the attacker can alter one of your encrypted backed-up files. It's not a hypothetical attack. For example your backed up /bin/ls file likely starts with something like (hexencoded): 7f454c4602010100000000000000000002003e000100 .ELF..............>... Let's assume attacker wants to trick you into running "echo hacked" on your system. They may achieve this by altering your backed up /bin/ls such that it decrypts to something like this: 23212f62696e2f73680a6563686f206861636b65640a #!/bin/sh\necho hacked\n And it's really easy! Stream ciphers work by XORing input plaintext with keystream: ciphertext = plaintext ^ generate_keystream(key) plaintext = ciphertext ^ generate_keystream(key) If you look closely at the equations, it's apparent that one can flip a byte in decrypted plaintext by flipping a byte in the ciphertext. To drive the point home, a small demonstration in Python (I'll use CTR instead of OFB but it's the same): >>> from Crypto.Cipher import AES >>> def xor(a, b): return bytes([ac ^ bc for ac, bc in zip(a, b)]) >>> aes_enc = AES.new(b"mysupersecretkey", AES.MODE_CTR) >>> plaintext = open("/bin/ls", "rb").read(32) >>> ciphertext = aes_enc.encrypt(plaintext) >>> known_plaintext = bytes.fromhex("7f454c4602010100000000000000000002003e000100") >>> wanted_plaintext =bytes.fromhex("23212f62696e2f73680a6563686f206861636b65640a") >>> flip = xor(known_plaintext, wanted_plaintext) >>> flipped_ciphertext = xor(flip, ciphertext) >>> aes_dec = AES.new(b"mysupersecretkey", AES.MODE_CTR, nonce=aes_enc.nonce) >>> aes_dec.decrypt(flipped_ciphertext) b'#!/bin/sh\necho hacked\n\\d\xc3\xd9\*o.sh\n' In this example attacker can change the first 22 bytes of file to arbitrary payload by abusing the predictable header of the ELF file. No knowledge of the key is necessary.
- byteknight 3y ago
  Thank you!
zamadatix 3y ago
My blind stab at it is this encryption always produces an output that's not validated to be what was originally encrypted and it does so in a way you could even intentionally damage a specific portion of the data without needing to know how to decrypt it. Curious to see how wrong I am :).
- Polycryptus 3y ago
  That's right, there's no guarantee the data hasn't been tampered with after encryption. The mechanics of the tampering you could do depend on the cipher mode you use. To give a simplified example (which doesn't match what this program does but is useful to demonstrate), ECB is the simplest mode (which really shouldn't be used for anything). Your input is split into fixed-length blocks (16 bytes for AES) and each block is encrypted separately, producing a deterministic ciphertext for each block. (e.g. a block of all "A" will always encrypt to the same thing). So if an attacker is able to figure out what plaintext a block of encrypted data corresponds to, they could use that knowledge to build a "fake" encrypted message. They could also remove blocks from a message, or shuffle them around. If you're interested in playing around more practically with this kind of thing, I highly recommend the https://cryptopals.com/ https://cryptopals.com/ challenge sets.
  - Levitating 3y ago
    I just finished the first 11 challenges, including detecting ECB ciphers. Thank you for sharing these! They are very fun and interesting challenges.
- SV_BubbleTime 3y ago
  It’s this. A cipher with a MAC or authentication (like an AEAD) will return “TRUE” and the data that was definitely decrypted properly. A normal cipher just returns data and it has no idea if it was decrypted correctly, so if you decrypt ABC and it should be XYZ, the wrong key will still “work” but the data will be X@9 which means nothing to you. Normally, you would validate your data after encryption. Like using something “Here is my result, and it has to start with the ascii characters of a valid date.” An authenticated cipher allows you to not care or have to know anything about the data at all, they’re nice. With the downside that you also need to supply the MAC or TAG or SIG along with the data package.
deleted 3y ago
[deleted]
d-z-m 3y ago
Modes like OFB effectively produce a keystream(not unlike a stream cipher) which is then XOR'd with the plaintext to produce the ciphertext. To decrypt, the same keystream is XOR'd with the ciphertext to produce the plaintext. If there is no integrity on the ciphertext, you can simply start flipping bits in the ciphertext, and arbitrarily change what the resulting XOR with the keystream will be.

msm_ 3y ago

My attempt of explanation with a (hopefully) relatable example: imagine that you store all your backup files encrypted, then restore the backup on your machine. The backup is stored on untrusted NAS but it's OK since it's encrypted, right? With OFB (and CTR, and any other unauthenticated cipher basically), no. Ciphers guarantee confidentiality, but nothing else. This means that the attacker can alter one of your encrypted backed-up files. It's not a hypothetical attack. For example your backed up /bin/ls file likely starts with something like (hexencoded): 7f454c4602010100000000000000000002003e000100 .ELF..............>... Let's assume attacker wants to trick you into running "echo hacked" on your system. They may achieve this by altering your backed up /bin/ls such that it decrypts to something like this: 23212f62696e2f73680a6563686f206861636b65640a #!/bin/sh\necho hacked\n And it's really easy! Stream ciphers work by XORing input plaintext with keystream: ciphertext = plaintext ^ generate_keystream(key) plaintext = ciphertext ^ generate_keystream(key) If you look closely at the equations, it's apparent that one can flip a byte in decrypted plaintext by flipping a byte in the ciphertext. To drive the point home, a small demonstration in Python (I'll use CTR instead of OFB but it's the same): >>> from Crypto.Cipher import AES >>> def xor(a, b): return bytes([ac ^ bc for ac, bc in zip(a, b)]) >>> aes_enc = AES.new(b"mysupersecretkey", AES.MODE_CTR) >>> plaintext = open("/bin/ls", "rb").read(32) >>> ciphertext = aes_enc.encrypt(plaintext) >>> known_plaintext = bytes.fromhex("7f454c4602010100000000000000000002003e000100") >>> wanted_plaintext =bytes.fromhex("23212f62696e2f73680a6563686f206861636b65640a") >>> flip = xor(known_plaintext, wanted_plaintext) >>> flipped_ciphertext = xor(flip, ciphertext) >>> aes_dec = AES.new(b"mysupersecretkey", AES.MODE_CTR, nonce=aes_enc.nonce) >>> aes_dec.decrypt(flipped_ciphertext) b'#!/bin/sh\necho hacked\n\\d\xc3\xd9\*o.sh\n' In this example attacker can change the first 22 bytes of file to arbitrary payload by abusing the predictable header of the ELF file. No knowledge of the key is necessary.

byteknight 3y ago
Thank you!

zamadatix 3y ago

My blind stab at it is this encryption always produces an output that's not validated to be what was originally encrypted and it does so in a way you could even intentionally damage a specific portion of the data without needing to know how to decrypt it. Curious to see how wrong I am :).

Polycryptus 3y ago
That's right, there's no guarantee the data hasn't been tampered with after encryption. The mechanics of the tampering you could do depend on the cipher mode you use. To give a simplified example (which doesn't match what this program does but is useful to demonstrate), ECB is the simplest mode (which really shouldn't be used for anything). Your input is split into fixed-length blocks (16 bytes for AES) and each block is encrypted separately, producing a deterministic ciphertext for each block. (e.g. a block of all "A" will always encrypt to the same thing). So if an attacker is able to figure out what plaintext a block of encrypted data corresponds to, they could use that knowledge to build a "fake" encrypted message. They could also remove blocks from a message, or shuffle them around. If you're interested in playing around more practically with this kind of thing, I highly recommend the https://cryptopals.com/ https://cryptopals.com/ challenge sets.
- Levitating 3y ago
  I just finished the first 11 challenges, including detecting ECB ciphers. Thank you for sharing these! They are very fun and interesting challenges.
SV_BubbleTime 3y ago
It’s this. A cipher with a MAC or authentication (like an AEAD) will return “TRUE” and the data that was definitely decrypted properly. A normal cipher just returns data and it has no idea if it was decrypted correctly, so if you decrypt ABC and it should be XYZ, the wrong key will still “work” but the data will be X@9 which means nothing to you. Normally, you would validate your data after encryption. Like using something “Here is my result, and it has to start with the ascii characters of a valid date.” An authenticated cipher allows you to not care or have to know anything about the data at all, they’re nice. With the downside that you also need to supply the MAC or TAG or SIG along with the data package.

deleted 3y ago

[deleted]

d-z-m 3y ago

Modes like OFB effectively produce a keystream(not unlike a stream cipher) which is then XOR'd with the plaintext to produce the ciphertext. To decrypt, the same keystream is XOR'd with the ciphertext to produce the plaintext. If there is no integrity on the ciphertext, you can simply start flipping bits in the ciphertext, and arbitrarily change what the resulting XOR with the keystream will be.