I'm not sure whether this is what you mean, but secappdev.org has a great lecture on internet security protocols by Bart Preneel: th-cam.com/video/CZzd3i7Bs2o/w-d-xo.html.
He talks about key algorithms in the beginning and then advice to use RSA because that is widely supported. Then, he says not to use RSA when talking about key exchange. Can some one shed some light?
as he said: wit RSA keyexchange, the keyexchange has a direct bond to the server's private key. Once you change the RSA key, the bond changes in exactly one way. it is simple, therefor was easy to implement with no further hassle. It is static and has no additional subset of identification or variation for how the keyexchange is actually performed - means there is not enough of additional random in a "second dimension" as it is the case with PFS keyexchanges like the EC keyechange provides. They use mathematical functions which do not relate at all to the actual keys, but their primes are choosen from within a whole (very big) range, resulting in a much larger number of possible keyexchanges. So, every keyexchange performed by EC is different, even if the server key stays one and the same. RSA-based encrypted traffic is still being (ab-)used to be "passively decrypted".(allows deep traffic inspection by middleboxes - it only requires the current server key of course to do so and can decrypt all traffic from and to the particular server). Which is not possible anymore when a connection uses strong EC keyexchange over a mathematical function (e.g. x25519) AND AEAD ciphers (such as AES256) . So, you can not revert the results in any way for extracting or relating to a specific key being used. For a wanna-be-middlebox in such case, solely owning the server key is no longer enough here. It also would require to know about all the random going on in the server when doing the EC keyexchange for every single connection. which is - simply spoken - impractical.
RSA is good to use because of how prolific it is. However it’s not the best idea for key exchange because it doesn’t support forward secrecy by default. Ecdhe supports forward secrecy by default but it’s more difficult to implement in larger enterprises. So the answer- it depends.
Material actually starts at 3:30
Do you have a link to your theory session ?
I'm not sure whether this is what you mean, but secappdev.org has a great lecture on internet security protocols by Bart Preneel: th-cam.com/video/CZzd3i7Bs2o/w-d-xo.html.
He talks about key algorithms in the beginning and then advice to use RSA because that is widely supported. Then, he says not to use RSA when talking about key exchange. Can some one shed some light?
as he said: wit RSA keyexchange, the keyexchange has a direct bond to the server's private key. Once you change the RSA key, the bond changes in exactly one way. it is simple, therefor was easy to implement with no further hassle. It is static and has no additional subset of identification or variation for how the keyexchange is actually performed - means there is not enough of additional random in a "second dimension" as it is the case with PFS keyexchanges like the EC keyechange provides. They use mathematical functions which do not relate at all to the actual keys, but their primes are choosen from within a whole (very big) range, resulting in a much larger number of possible keyexchanges. So, every keyexchange performed by EC is different, even if the server key stays one and the same. RSA-based encrypted traffic is still being (ab-)used to be "passively decrypted".(allows deep traffic inspection by middleboxes - it only requires the current server key of course to do so and can decrypt all traffic from and to the particular server). Which is not possible anymore when a connection uses strong EC keyexchange over a mathematical function (e.g. x25519) AND AEAD ciphers (such as AES256) . So, you can not revert the results in any way for extracting or relating to a specific key being used. For a wanna-be-middlebox in such case, solely owning the server key is no longer enough here. It also would require to know about all the random going on in the server when doing the EC keyexchange for every single connection. which is - simply spoken - impractical.
RSA is good to use because of how prolific it is. However it’s not the best idea for key exchange because it doesn’t support forward secrecy by default. Ecdhe supports forward secrecy by default but it’s more difficult to implement in larger enterprises.
So the answer- it depends.