Hi thanks for this video. I have two questions : 1- 2:42 for me the "A" part of the "AE" provide not only integrity but also Authentication . am I wrong ? 2 - For AD part of "AEAD" : Could you please tell me explicitly which part of the (IP, TCP ? ) headers are considered when generating the HMAC with AES_GCM ? because, among other things, the source IP address might change by the time the encrypted packet get to the server . And if it's the case, the server would not be able to validate the HMAC of the received packet (since the source ip changed) ... many thanks,
Hi Karim, great questions! The "AE" stands for "Authenticated Encryption" so that is definitely provides authentication. The ciphertext is MAC'd (preferably using a strong MAC like HMAC-SHA). As for the Authenticated Data, it could be the IP packet header. Here's a link to a little more info on the Authenticated Data part: security.stackexchange.com/questions/4694/what-is-the-purpose-of-aead
Thanks for the video. I have a question, is Chacha20 Poly1305 more secure than AES GCM? i have seen Facebook uses this cipher suite while Google uses AES 128 GCM.
No. It is not. But yeah, they have comparable security. AES is a Block cipher, whereas ChaCha20 is a stream cipher. Although CTR modes and friends converts AES into a stream cipher.
Chacha20_Poly1305 is a cipher suite good for software encryption. And AES is a hardware based encryption.. many modern/advance systems rely on hardware based encryption.. chacha20_poly1305 is a good choice to support multiple devices..
You can certainly use HMAC. When I mentioned "MAC" I was using the term just to discuss the idea of message authentication rather than saying you should only use MAC vs. HMAC. Here's a good document that outlines options for HMAC while using AEAD ciphers: tools.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-03.html
great question! here's a good thread that sheds some light on this: stackoverflow.com/questions/187655/are-https-headers-encrypted the short answer is, yes. the HTTP headers are encrypted...the TCP and IP headers are not (because the packets would not be routable if they were)
I'm assuming that the headers mentioned here is IP and TCP headers, so what would that mean for packets that passes through a BIG-IP without SSL profiles? Since the BIG-IP has different TCP connections clientside and serverside, will the client/server no longer consider that traffic to be secure since the Associated Data is different?
Hi Henrik...great question! You are correct that the example given here for the associated data is for IP headers (although, associated data doesn't have to be IP packet headers...it's just a common example when discussing AEAD ciphers). As for the BIG-IP and SSL profiles, in order for traffic to be encrypted, the SSL profile would need to be set up on the BIG-IP. When you set up the SSL profile on the BIG-IP, you would need to configure the cipher suites to use AEAD ciphers. For example, you would need to ensure AES-GCM is part of one of the available cipher suites configured on the SSL profile. As for the TCP connections, you are correct that the BIG-IP has a full proxy architecture, so it establishes separate connections to the client and the backend server(s), and you can configure client SSL profiles as well as server SSL profiles to handle traffic to/from the client and to/from the backend servers. So, the BIG-IP can theoretically use AEAD ciphers on one side and not on the other...or it could use them on both...or not at all...whatever you need to do! Typically, organizations are interested in the client to BIG-IP connection, so most people would configure the client SSL profile to use AEAD ciphers. I hope this helps!
I give a thumbs up to your video bcoz I can see you have an organized presentation tool and voice quality. But I don't see what key is used to which part. Also what Wikipedia describes as: "The header part is intended to provide authenticity and integrity protection for networking or storage metadata for which confidentiality is unnecessary, but authenticity is desired." Seems to be opposite to what you explained. Can you please add some info in terms of what key is used where. How is the "AD" generated? Thanks.
where do I find the math for all these cipher suits for tls 1.3?
In Simple terms is this bulk encryption with authentication for the data.
I thinks hmac only using for authentication and integrity of data.
Hi thanks for this video. I have two questions :
1- 2:42 for me the "A" part of the "AE" provide not only integrity but also Authentication . am I wrong ?
2 - For AD part of "AEAD" : Could you please tell me explicitly which part of the (IP, TCP ? ) headers are considered when generating the HMAC with AES_GCM ? because, among other things, the source IP address might change by the time the encrypted packet get to the server . And if it's the case, the server would not be able to validate the HMAC of the received packet (since the source ip changed) ...
many thanks,
Hi Karim, great questions! The "AE" stands for "Authenticated Encryption" so that is definitely provides authentication. The ciphertext is MAC'd (preferably using a strong MAC like HMAC-SHA). As for the Authenticated Data, it could be the IP packet header. Here's a link to a little more info on the Authenticated Data part: security.stackexchange.com/questions/4694/what-is-the-purpose-of-aead
Pppp
Thanks for the video. I have a question, is Chacha20 Poly1305 more secure than AES GCM? i have seen Facebook uses this cipher suite while Google uses AES 128 GCM.
No. It is not. But yeah, they have comparable security. AES is a Block cipher, whereas ChaCha20 is a stream cipher. Although CTR modes and friends converts AES into a stream cipher.
Chacha20_Poly1305 is a cipher suite good for software encryption. And AES is a hardware based encryption.. many modern/advance systems rely on hardware based encryption.. chacha20_poly1305 is a good choice to support multiple devices..
Why not use HMAC instead of MAC for the additional authentication?
You can certainly use HMAC. When I mentioned "MAC" I was using the term just to discuss the idea of message authentication rather than saying you should only use MAC vs. HMAC. Here's a good document that outlines options for HMAC while using AEAD ciphers: tools.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-03.html
Hey John, great video!
Quick question, does that mean that TLS 1.2 and below encrypted the headers?
great question! here's a good thread that sheds some light on this: stackoverflow.com/questions/187655/are-https-headers-encrypted
the short answer is, yes. the HTTP headers are encrypted...the TCP and IP headers are not (because the packets would not be routable if they were)
Thanks for the explanation!
You're welcome! Glad you enjoyed it.
I'm assuming that the headers mentioned here is IP and TCP headers, so what would that mean for packets that passes through a BIG-IP without SSL profiles? Since the BIG-IP has different TCP connections clientside and serverside, will the client/server no longer consider that traffic to be secure since the Associated Data is different?
Hi Henrik...great question! You are correct that the example given here for the associated data is for IP headers (although, associated data doesn't have to be IP packet headers...it's just a common example when discussing AEAD ciphers). As for the BIG-IP and SSL profiles, in order for traffic to be encrypted, the SSL profile would need to be set up on the BIG-IP. When you set up the SSL profile on the BIG-IP, you would need to configure the cipher suites to use AEAD ciphers. For example, you would need to ensure AES-GCM is part of one of the available cipher suites configured on the SSL profile.
As for the TCP connections, you are correct that the BIG-IP has a full proxy architecture, so it establishes separate connections to the client and the backend server(s), and you can configure client SSL profiles as well as server SSL profiles to handle traffic to/from the client and to/from the backend servers. So, the BIG-IP can theoretically use AEAD ciphers on one side and not on the other...or it could use them on both...or not at all...whatever you need to do! Typically, organizations are interested in the client to BIG-IP connection, so most people would configure the client SSL profile to use AEAD ciphers. I hope this helps!
I give a thumbs up to your video bcoz I can see you have an organized presentation tool and voice quality. But I don't see what key is used to which part. Also what Wikipedia describes as: "The header part is intended to provide authenticity and integrity protection for networking or storage metadata for which confidentiality is unnecessary, but authenticity is desired." Seems to be opposite to what you explained. Can you please add some info in terms of what key is used where. How is the "AD" generated? Thanks.
Thank you very much!
Very interesting!
glad you enjoyed it!
Message Authentication Code