midgard/zeus.ugent.be
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge branch 'csc_radium' of github.com:ZeusWPI/zeus.ugent.be into csc_radium

Browse source
This commit is contained in:
David Vandorpe 2018-03-09 12:03:37 +01:00
commit ab7f50a0a9
No known key found for this signature in database
GPG key ID: 750319296238238A
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/blog/17-18/cscbe.md
View file

@ -48,7 +48,7 @@ So, how do we get our flag? Let's list some ideas:
Let's see what these ideas lead to. 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? And the program used the same function to encrypt and decrypt! So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. Some testing proved that our logic was flawed: using the same function worked because of the symmetry of the XOR operation in OFB mode, and not because `IV == AES(AES(IV))` which would break AES OFB. 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 (guaranteeing `x == DES(DES(x))`), in combination with OFB. But wait a second, the program uses the same function to encrypt and decrypt as well! So basically we would expect the second block of ciphertext to just be the plaintext XOR'd with the IV. Some testing proved that our logic was flawed: using the same function worked because of the symmetry of the XOR operation in OFB mode, and not because `IV == AES(AES(IV))` which would break AES OFB.
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). 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).