From e6bf46d17cd07893eb0ec647d20e8d279b5cc41c Mon Sep 17 00:00:00 2001 From: David Vandorpe Date: Fri, 9 Mar 2018 09:37:09 +0100 Subject: [PATCH 1/4] Link to other writeup This one is a lot clearer --- content/blog/17-18/cscbe.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/17-18/cscbe.md b/content/blog/17-18/cscbe.md index 04a0fa4..e4ea346 100644 --- a/content/blog/17-18/cscbe.md +++ b/content/blog/17-18/cscbe.md @@ -48,7 +48,7 @@ So, how do we get our flag? Let's list some ideas: Let's see what these ideas lead to. -We found a [writeup](https://github.com/Alpackers/CTF-Writeups/tree/master/2016/BostonKeyParty/Crypto/des-ofb) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. +We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. Setting the encryption key to NULL on the server seemed easy enough, but sadly this would also mean that the server couldn't decrypt the messages from the client (as this key was used for both encryption and decryption by both sides). From 0f62e9b62966f27d462aefd28e37ccb635a789f8 Mon Sep 17 00:00:00 2001 From: David Vandorpe Date: Fri, 9 Mar 2018 09:51:41 +0100 Subject: [PATCH 2/4] Added Toon's explanation about AES --- content/blog/17-18/cscbe.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/blog/17-18/cscbe.md b/content/blog/17-18/cscbe.md index e4ea346..9475894 100644 --- a/content/blog/17-18/cscbe.md +++ b/content/blog/17-18/cscbe.md @@ -48,7 +48,9 @@ So, how do we get our flag? Let's list some ideas: Let's see what these ideas lead to. -We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. +We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. **Update:** Thanks to Toon Willems for pointing out that AES modifies the key after every round. For those interested, see [act 3](http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html). + +![AES Key Expansion](http://www.moserware.com/assets/stick-figure-guide-to-advanced/aes_act_3_scene_06_key_expansion_part_1_1100.png) Setting the encryption key to NULL on the server seemed easy enough, but sadly this would also mean that the server couldn't decrypt the messages from the client (as this key was used for both encryption and decryption by both sides). From 91636b541691b85e8b24f41497db170800a2e1c7 Mon Sep 17 00:00:00 2001 From: lorin Date: Fri, 9 Mar 2018 10:37:45 +0100 Subject: [PATCH 3/4] http -> https --- content/blog/17-18/cscbe.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/17-18/cscbe.md b/content/blog/17-18/cscbe.md index 9475894..29087bf 100644 --- a/content/blog/17-18/cscbe.md +++ b/content/blog/17-18/cscbe.md @@ -48,7 +48,7 @@ So, how do we get our flag? Let's list some ideas: Let's see what these ideas lead to. -We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. **Update:** Thanks to Toon Willems for pointing out that AES modifies the key after every round. For those interested, see [act 3](http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html). +We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. **Update:** Thanks to Toon Willems for pointing out that AES modifies the key after every round. For those interested, see [act 3](https://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html). ![AES Key Expansion](http://www.moserware.com/assets/stick-figure-guide-to-advanced/aes_act_3_scene_06_key_expansion_part_1_1100.png) From 2b605cd6774cd4325681f3f5d585efcd820c37b0 Mon Sep 17 00:00:00 2001 From: lorin Date: Fri, 9 Mar 2018 10:38:24 +0100 Subject: [PATCH 4/4] more http -> https --- content/blog/17-18/cscbe.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/17-18/cscbe.md b/content/blog/17-18/cscbe.md index 29087bf..06c096d 100644 --- a/content/blog/17-18/cscbe.md +++ b/content/blog/17-18/cscbe.md @@ -50,7 +50,7 @@ Let's see what these ideas lead to. We found a [writeup](https://shrikantadhikarla.wordpress.com/2016/03/08/des-ofb-writeup-boston-key-party-ctf/) from another CTF that cracks DES encryption in OFB mode. The key weakness here is using a weak DES key (making encryption symmetric), in combination with OFB. But wait a second, isn't AES a symmetric algorithm? So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. However, for reasons unknown to me this turned out not to be the case. **Update:** Thanks to Toon Willems for pointing out that AES modifies the key after every round. For those interested, see [act 3](https://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html). -![AES Key Expansion](http://www.moserware.com/assets/stick-figure-guide-to-advanced/aes_act_3_scene_06_key_expansion_part_1_1100.png) +![AES Key Expansion](https://www.moserware.com/assets/stick-figure-guide-to-advanced/aes_act_3_scene_06_key_expansion_part_1_1100.png) Setting the encryption key to NULL on the server seemed easy enough, but sadly this would also mean that the server couldn't decrypt the messages from the client (as this key was used for both encryption and decryption by both sides).