I would like to point out that unlike you make it out to be in this video, reusing keys with CTR mode isn't insecure by design. The actual problem lies in reusing the same initialization vector value (IV) with multiple encryptions with the same key. The IV values should be nonces (or 'number used only once') to protect against this attack. Usually these nonce values are achieved by using a running counter value added to the original IV value (IV || CTR[i]), hence the name counter mode. Let me demonstrate the attack and how to prevent it: Ciphertext1 = Plaintext1 ⊕ AES(key, IV) Ciphertext2 = Plaintext2 ⊕ AES(key, IV) Which leads to the following ciphertext pair: Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ AES(key, IV) ⊕ Plaintext2 ⊕ AES(key, IV) Now, because the (key, IV) pair is reused, the AES(key, IV) will yield the same result for both ciphertexts. This means that an attacker can now compute Ciphertext pairs easily by cancelling the AES encryption out of the equation (XORing anything by itself will always yield to 0): Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ Plaintext2 Therefore an attacker can easily get the Plaintext2 value by computing the following operation: Plaintext2 = Plaintext1 ⊕ Ciphertext1 ⊕ Ciphertext2 As was demonstrated in this video. When using the counter mode properly, we get the ciphertexts in the following way: Ciphertext1 = Plaintext1 ⊕ AES(key, (IV || CTR[0])) Ciphertext2 = Plaintext2 ⊕ AES(key, (IV || CTR[1])) Which leads to the following ciphertext pair: Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ AES(key, (IV || CTR[0])) ⊕ Plaintext2 ⊕ AES(key, (IV || CTR[1])) Now, because the AES encryption operations yield different results, an attacker can no longer just cancel the AES encryptions out and would actually need to compute the values themselves. Even if the attacker knows the original IV value, they have no way of actually computing these without obtaining the key! Therefore, the attack is rendered useless whenever unique (key, IV) pairs are used. The code in question should be fixed by making the following change to the counter: iv = os.urandom(16) ctr = Counter.new(128, int.from_bytes(iv, byteorder='big')) cipher = AES.new(KEY, AES.MODE_CTR, counter=ctr)
I find it interesting that you use the syntax "Ciphertext1 = Plaintext1 ⊕ AES(key, IV)" and have a few questions: 1. Is the plaintext itself not actually fed into the AES algorithm? 2. Is the plaintext really just XORed with the AES output using some IV as input? 3. Would feeding the plaintext itself into the AES algorithm provide any marginal security benefit vs XORing it with the AES output of some IV? 4. My understanding is that AES outputs the same number of bytes in the input. For the XOR operation to work, does the IV need to be the same length as the plaintext? Put differently, how is the AES output padded (if at all) to allow for an XOR with the plaintext?
@@ghawk1347 1. Counter mode operation works by encrypting a counter or other number only used once (nonce) with a key to produce a unpredictable output. This output is usually called "keystream" and must never be reused, as Arttu explained. This keystream is xor'd with the plaintext to produce ciphertext. CTR mode does not put the plaintext into the AES algorithm. Look up a diagram of counter mode operation on wiki etc. 2. No - only the counter is put into the AES cipher. This works so long as you're careful about how you choose / maintain those inputs. 3. Done properly AES-CTR is secure. It's used in AES-GCM (Galois counter mode) which is still pretty much state of the art for example. The main difference between these two is that AES-CTR does nothing whatsoever to protect the integrity of the encrypted message - only its confidentiality. 3. The AES block cipher (for any key length - 128/192/256) has a block size of 128 bits. That means the input to the cipher is 128 bits, as is the output. CTR mode effectively converts a block cipher into a stream cipher meaning you can encrypt arbitrary sized plaintexts without padding. This is achieved by discarding the unused bits of keystream produced from the final encrypt operation; no padding is necessary.
You missed something critical with the source code in the CTF: each encryption run was initialiazing a new counter with no added variables, and so, each plaintext actually ended up using up the same initial value of the counter (because if both times the counter was initialized in the same way, which it was, then the initial counter value would also be the same). When John says 'keys', I think he probably means the end key which was used to encrypt the plaintext, and not the key which was provided from urandom. The end key remains the same, because this key is a 'mix' of the urandom key and the counter, both of which remains the same in both encryption runs, thus resulting in key reusage. Thanks for the comment though, it made me wanna look deeper into the problem.
I did not have the right understanding for this challenge and did not give the right explanation in the video, and I'm sorry for that. You can find a solid explanation in Arttu Paju's comment pinned below and the other comments that explain where I went wrong in this one. Sorry!
Hope you know your sleep deprivation hasn’t gone unappreciated, I seriously like camp out everyday after work looking forward to these. Love and appreciate you John!
In this specific scenario, the actual vulnerability is the non-unique (nonce, key) pair between 2 distinct encryptions. As during the creation of the AES object no value for nonce(=IV) is specified, a default one is used and thus, 2 ciphertext will share the same default IV and key which makes it vulnerable
Oh, so all you had to do was Xor? I did not know that worked for AES! I thought you had to brute force the urandom-value against the know string to find the key and then decrypt the flag. :p
if you know enrypted text and plaintext...then you acquire the KEY (and IV in this example). but same key was used again, so you know Key (with same IV) and encrypted-Flag...then you acquire plaintext of Flag.
I would like to point out that unlike you make it out to be in this video, reusing keys with CTR mode isn't insecure by design. The actual problem lies in reusing the same initialization vector value (IV) with multiple encryptions with the same key. The IV values should be nonces (or 'number used only once') to protect against this attack. Usually these nonce values are achieved by using a running counter value added to the original IV value (IV || CTR[i]), hence the name counter mode. Let me demonstrate the attack and how to prevent it:
Ciphertext1 = Plaintext1 ⊕ AES(key, IV)
Ciphertext2 = Plaintext2 ⊕ AES(key, IV)
Which leads to the following ciphertext pair:
Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ AES(key, IV) ⊕ Plaintext2 ⊕ AES(key, IV)
Now, because the (key, IV) pair is reused, the AES(key, IV) will yield the same result for both ciphertexts.
This means that an attacker can now compute Ciphertext pairs easily by cancelling the AES encryption out of the equation (XORing anything by itself will always yield to 0):
Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ Plaintext2
Therefore an attacker can easily get the Plaintext2 value by computing the following operation:
Plaintext2 = Plaintext1 ⊕ Ciphertext1 ⊕ Ciphertext2
As was demonstrated in this video.
When using the counter mode properly, we get the ciphertexts in the following way:
Ciphertext1 = Plaintext1 ⊕ AES(key, (IV || CTR[0]))
Ciphertext2 = Plaintext2 ⊕ AES(key, (IV || CTR[1]))
Which leads to the following ciphertext pair:
Ciphertext1 ⊕ Ciphertext2 = Plaintext1 ⊕ AES(key, (IV || CTR[0]))
⊕ Plaintext2 ⊕ AES(key, (IV || CTR[1]))
Now, because the AES encryption operations yield different results, an attacker can no longer just cancel the AES encryptions out and would actually need to compute the values themselves. Even if the attacker knows the original IV value, they have no way of actually computing these without obtaining the key! Therefore, the attack is rendered useless whenever unique (key, IV) pairs are used.
The code in question should be fixed by making the following change to the counter:
iv = os.urandom(16)
ctr = Counter.new(128, int.from_bytes(iv, byteorder='big'))
cipher = AES.new(KEY, AES.MODE_CTR, counter=ctr)
This is exactly right - the real issue here is not re-using a key but re-using the IV / nonce for a given key. That is a school boy fail!
I find it interesting that you use the syntax "Ciphertext1 = Plaintext1 ⊕ AES(key, IV)" and have a few questions:
1. Is the plaintext itself not actually fed into the AES algorithm?
2. Is the plaintext really just XORed with the AES output using some IV as input?
3. Would feeding the plaintext itself into the AES algorithm provide any marginal security benefit vs XORing it with the AES output of some IV?
4. My understanding is that AES outputs the same number of bytes in the input. For the XOR operation to work, does the IV need to be the same length as the plaintext? Put differently, how is the AES output padded (if at all) to allow for an XOR with the plaintext?
@@ghawk1347 1. Counter mode operation works by encrypting a counter or other number only used once (nonce) with a key to produce a unpredictable output. This output is usually called "keystream" and must never be reused, as Arttu explained. This keystream is xor'd with the plaintext to produce ciphertext. CTR mode does not put the plaintext into the AES algorithm. Look up a diagram of counter mode operation on wiki etc.
2. No - only the counter is put into the AES cipher. This works so long as you're careful about how you choose / maintain those inputs.
3. Done properly AES-CTR is secure. It's used in AES-GCM (Galois counter mode) which is still pretty much state of the art for example. The main difference between these two is that AES-CTR does nothing whatsoever to protect the integrity of the encrypted message - only its confidentiality.
3. The AES block cipher (for any key length - 128/192/256) has a block size of 128 bits. That means the input to the cipher is 128 bits, as is the output. CTR mode effectively converts a block cipher into a stream cipher meaning you can encrypt arbitrary sized plaintexts without padding. This is achieved by discarding the unused bits of keystream produced from the final encrypt operation; no padding is necessary.
@@gareth4168 Thanks so much for the answer! That makes a lot of sense. I'll look into CTR and the other modes a bit more.
You missed something critical with the source code in the CTF: each encryption run was initialiazing a new counter with no added variables, and so, each plaintext actually ended up using up the same initial value of the counter (because if both times the counter was initialized in the same way, which it was, then the initial counter value would also be the same).
When John says 'keys', I think he probably means the end key which was used to encrypt the plaintext, and not the key which was provided from urandom. The end key remains the same, because this key is a 'mix' of the urandom key and the counter, both of which remains the same in both encryption runs, thus resulting in key reusage.
Thanks for the comment though, it made me wanna look deeper into the problem.
I did not have the right understanding for this challenge and did not give the right explanation in the video, and I'm sorry for that. You can find a solid explanation in Arttu Paju's comment pinned below and the other comments that explain where I went wrong in this one. Sorry!
I really love how humble John is. You're the best man
you + sleep deprivation = hilarious
Lmao
It was 2 40 am
Hope you know your sleep deprivation hasn’t gone unappreciated, I seriously like camp out everyday after work looking forward to these. Love and appreciate you John!
"Your life should be in Dark Mode...." John Hammond
That should be a famous quote!
In this specific scenario, the actual vulnerability is the non-unique (nonce, key) pair between 2 distinct encryptions. As during the creation of the AES object no value for nonce(=IV) is specified, a default one is used and thus, 2 ciphertext will share the same default IV and key which makes it vulnerable
I really learn a lot through your videos, best part I also enjoy watching them again and again ❤️
your videos are so fun to watch and so educating
This is my new favorite channel.
nice video, I enjoyed the end credit bonus scene of crazy john with the lights. Keep it up, buddy.
Dark mode John isn't bad at all
Thanks for the video John!
Its 2 : 11 and im watching your video , i should also have to go to bed now good night John, btw awesome content as always ❗
amazing John
learned something new again. Thanks John
bro , the dark mode in the end was super duper cool ! test it one in a while :)
DarkMODE for the Win.
Real talk? The room looks great at the end there!
Just reusing a key and it breaks one of the most popular encryption algorithms
That’s why randomization is such an important factor in crypto
There's no crypto algorithm on the world that's immune to being used wrong.
IV should not be the same 🤦♂️
Awesome!
john sir king🤴🤴🤴🤴
I like dark mode ! Keep it :-)
Addicted to you sir
Cool video in dark mode ...
Nice
how many hours do you actually sleep in a day? appreciate your videos and knowledge sharing
Oh, so all you had to do was Xor? I did not know that worked for AES! I thought you had to brute force the urandom-value against the know string to find the key and then decrypt the flag. :p
if you know enrypted text and plaintext...then you acquire the KEY (and IV in this example). but same key was used again, so you know Key (with same IV) and encrypted-Flag...then you acquire plaintext of Flag.
how would you attempt this if the source string wasn't supplied?
Hahaha well It's just a CTF challenge my boy, It's like think and solve it that's all.
I wonder if they called it PhaseStream3, or PS3, on purpose.. The first PS3 hack involved a bad PRNG .
1 dislike is the ip john hammond hacked
why don't u make python series where u gonna teach pentesting python to us. If this would happen gonna appreciate it vro🙏
"pentesting python" is just advanced python...
@@agowa338agreed. that's why we want little series where he gonna teach us all the modules. of python3.
@@malfoytech4601 Why? Because you never learned how to read the documentation???
Love from india
I see that you have Linux but... it’s not kali bro you need to try kali Linux it will change your life. Ps I love your videos keep up the good work 🙂🙂
Bro he Completed oscp and i think he is going to tak OSCE this year ,and there you are saying him to use Kali.💀
What can you hack is the sky the limit or are their specifics
You explained absolutly nothing in this video..Reusing the key is not the only problem here.
ok
HTB{ {H)igh (E)ducation (A)ttentional (R)ight (NOW) (T)raffic! } --->Thx!
yeah I just start the video ... (i wr0t3 c0mm3n7 b3f0r3 st4r7ing l0l)
John You really need to sleep
Heartt