From cc0d3dbaa5f9850014e362f04dfbd0b7aa3789de Mon Sep 17 00:00:00 2001 From: Yan Date: Sat, 28 Sep 2024 16:11:15 -0700 Subject: [PATCH] cbc --- cryptography/aes-cbc/DESCRIPTION.md | 20 ++++++++++++++++++++ cryptography/aes-cbc/run | 15 +++++++++++++++ cryptography/module.yml | 2 ++ 3 files changed, 37 insertions(+) create mode 100644 cryptography/aes-cbc/DESCRIPTION.md create mode 100755 cryptography/aes-cbc/run diff --git a/cryptography/aes-cbc/DESCRIPTION.md b/cryptography/aes-cbc/DESCRIPTION.md new file mode 100644 index 0000000..69a9e2b --- /dev/null +++ b/cryptography/aes-cbc/DESCRIPTION.md @@ -0,0 +1,20 @@ +Okay, hopefully we agree that ECB is a bad block cipher mode. +Let's explore one that isn't _so_ bad: [Cipher Block Chaining (CBC)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_block_chaining_(CBC)). +CBC mode encrypts blocks sequentially, and before encrypting plaintext block number N, it XORs it with the previous ciphertext block (number N-1). +When decrypting, after decrypting ciphertext block N, it XORs the decrypted (but still XORed) result with the previous ciphertext block (number N-1) to recover the original plaintext block N. +For the very first block, since there is no "previous" block to use, CBC mode XORs it with a block of random data, called the _Initialization Vector_, that it simply prepends to the concatenated ciphertext blocks! +This means that if you encrypt one block of plaintext in CBC mode, you'll get _two_ blocks of "ciphertext": the IV, and your single block of actual ciphertext. + +All this means that, when you change any part of the plaintext, those changes will propagate through to all subsequent ciphertext blocks because of the XOR-based chaining, preserving ciphertext indistinguishability for those blocks. +That will stop you from carrying out the chosen-plaintext prefix attacks from the last few challenges. +Moreover, every time you re-encrypt, even with the same key, a new (random) IV will be used, which will propagate changes to all of the blocks anyways, which means that even your sampling-based CPA attacks from the even earlier levels will not work, either. + +Sounds pretty good, right? +The only relevant _disadvantage_ that CBC has over EBC is that encryption has to happen sequentially. +With ECB, you could encrypt, say, only the last part of the message if that's all you have to send. +With CBC, you must encrypt the message from the beginning. +In practice, this does not tend to be a problem, and ECB should never be used over CBC. + +This level is just a quick look at CBC. +We'll encrypt the flag with CBC mode. +Go and decrypt it! diff --git a/cryptography/aes-cbc/run b/cryptography/aes-cbc/run new file mode 100755 index 0000000..1f16922 --- /dev/null +++ b/cryptography/aes-cbc/run @@ -0,0 +1,15 @@ +#!/opt/pwn.college/python + +from base64 import b64encode +from Crypto.Cipher import AES +from Crypto.Util.Padding import pad +from Crypto.Random import get_random_bytes + +flag = open("/flag", "rb").read() + +key = get_random_bytes(16) +cipher = AES.new(key=key, mode=AES.MODE_CBC) +ciphertext = cipher.encrypt(pad(flag, cipher.block_size)) + +print(f"AES Key (b64): {b64encode(key).decode()}") +print(f"Flag Ciphertext (b64): {b64encode(ciphertext).decode()}") diff --git a/cryptography/module.yml b/cryptography/module.yml index ad268a2..191059f 100644 --- a/cryptography/module.yml +++ b/cryptography/module.yml @@ -31,6 +31,8 @@ challenges: name: AES-ECB-CPA-Prefix-Miniboss - id: cpa-http-boss name: AES-ECB-CPA-Prefix-Boss +- id: aes-cbc + name: AES-CBC - id: level-6 name: DHKE - id: level-7