Lightboard Lessons: Perfect Forward Secrecy

awesome...glad it's all cleared up now! and, sorry if the video was a bit confusing :)

Hi,

Thanks a lot for explanation. Now it's clear, as mentioned, in video it looked like client is not using his random key to generate value send to server - it was in contrast with what server did, that's why I was a bit confused. Now it's clear that both server and client uses their random numbers (secrets) to generate values that they exchange :-)

Thanks again,

Piotr

Hi Piotr!! Thanks for all the great questions! I'll attempt to answer them all, but if I miss something, please let me know, and I'll follow up with more information.

The random integer is used as a part of the Diffie Hellman key exchange, and the basic idea works like this:

The server comes up with two prime numbers g and p and tells you (client) what they are. You then pick a secret, random number (a), but you don't tell anyone. Instead you (client) compute g^a mod p and send that result back to the server. (We'll call that A since it came from a). The server does the same thing, but we'll call the server's secret, random number b. So the server computes g^b mod p and sends you (client) the result (we'll call it "B") Now, you (client) take the number the server sent you and do the exact same operation with it. So that's B^a mod p. The server does the same operation with the result you (client) sent it, so: A^b mod p.

As it turns out, A^b mod p is the same value as B^a mod p. That's the cool, genius magic behind Diffie Hellman. All of these values can be (and are) sent in cleartext, but no one who might capture them will be able to figure out the value of the final operation because they would need the value a or b to figure it out. And, those values are the secret, random values that the client and server have generated.

As for the ephemeral part, if you don't use ephemeral keys, then the same random values would be used for a longer period of time between a specific client and server. However, if ephemeral keys are used, then the random values are new with every session, so the keys will then change with every session.

Finally, on the server certificate...yes, it's still sent via the RSA algorithm but it's never used for creating keys for bulk data encryption. Rather, like you said, it's only used for server identity purposes.

Thanks again for the great questions!!

Hi John,

Thanks a lot for keeping promise :-) Great lesson!!

I am a bit puzzled about how client uses it's random integer. You stated that client is using known (provided by server) prime number, modulo and value A to calculate its own value B. If so what client random integer is used for?

If client uses only values that are public (prime number, modulo and value A) - if I am not wrong those are not encrypted, so can be picked up from stored session - then anyone can recreate value B - or I am wrong here?

Next question - what is purpose of generating pre-master secret? In case of RSA it's necessary because only client generates pre-master secret and then sends it to server. But in case of DH both client and server are able to generate the same pre-master after exchanging A and B values, so why not generate master secret skipping pre-master?

I assume that never sending pre-master secret over the wire is the reason why asymmetric encryption is not necessary and DH is safer than RSA?

What is necessary to compromise TLS session in this case - both server and client random integer? Those are only two pieces of info that are never exchanged and if I am right discarded after given session is over?

I am not sure as well what is exact difference between ephemeral and not ephemeral cipher suite. You said that in case of ephemeral for every session new random integers are chosen - so far so good

But what if ephemeral is not used? For given client, server is always using same random integer? Seems a bit unlikely, server would have to store a lot of info (like client to random integer mapping) for a long time.

Is random integer only piece that is changing, so for every client and every session server is using the same prime number and modulo?

Last but not least :-) I assume that server is still sending it's certificate so client can verify server identity, only difference is that public key from server certificate is never used for encrypting any piece of exchanged data?

Piotr