Diffie-Hellman key exchange, vpn

[sarahr202]

Hi every body

How is every one doing?

I was reading about vpn  and  how the problem---  exchanging the shared --  is  solved  by  diffie-Hellman exchange process.

The assumption  is data encrypted y public key can only be decrypted y corresponding private key  ( The author  also  mentioned the data can also be decrypted y using the  same public key used to encrypt the data in the first place)

Here is Understanding.

pc1----------Internet--pc2

generate a shared key and want to share it with pc1.  PC2  encrypt the  shared key using pc1 public key and sends it over Internet to pc1.

PC1  will receive the  encrypted key and decrypt it using its private key and recover the shared key.

My question  one can   intercept the encrypted key sent by pc1 in transit.  Since  pc1 's  public key  is known, armed with the pc1's public key, one can intercept and decrypt the packet and recover the shared key.  So  How is it safe ?

Thanks.

[Peter Paluch · Accepted solution]

Hi Sarah,

As a matter of fact, with Diffe-Hellman key exchange, we do not talk about private and public keys. Using public/private keys (i.e. asymmetric cryptography) is another and different way of safely sending a shared secret over an untrusted network.

The assumption  is data encrypted y public key can only be decrypted y 
corresponding private key  ( The author  also  mentioned the data can 
also be decrypted y using the  same public key used to encrypt the data 
in the first place)

The statement in the parentheses is wrong. Once a block of data is encrypted by someone's public key, there is no way of decrypting it other than using the appropriate private key. It is not possible to encrypt and decrypt the same block of data using the same key - that would not be an asymmetrical cryptography at all.

Perhaps what the author wanted to say is that the keys are always generated in pairs, and data encrypted by one key from the pair can be decrypted by the other key from the keypair. Which one is public and which one is private does not depend on the keys themselves. It is how you use and publish them which makes the difference to what is a private and public key. Encrypting by one's private key and decrypting by the corresponding public key is the foundation of digital signatures.

My question  one can   intercept the encrypted key sent by pc1 in 
transit.  Since  pc1 's  public key  is known, armed with the pc1's 
public key, one can intercept and decrypt the packet and recover the 
shared key.  So  How is it safe ?

Can you please rephrase the question? I am confused by the wording (key sent by PC1 - which key?)

Regarding the Diffie-Hellman exchange, you may find the following reading quite illustrative:

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Note that the point of Diffie-Hellman exchange is not to encrypt/decrypt a block of data but rather to exchange partial results of a computation in such a way that each side can complete the computation and yield the same result (the shared secret) while an external observer cannot derive some of the essential values to compute the same shared secret.

Best regards,

Peter

[Jon Marshall]

Peter

Good point. I was so busy explaining public/private key mechanics that i overlooked DH not being public/private key mechanism.

Jon

[Peter Paluch · Accepted solution]

Hi Jon,

A pleasure to discuss things again with you!

i overlooked DH not being public/private key mechanism. 

It seems that this is a matter of terminology. The Wikipedia article I have referenced in my previous post actually does use the terminology of private and public keys with respect to DH (which surprised me ). However, I like to avoid this particular terminology when not talking about asymmetric cryptography as I find these concepts slightly overlapping and I want to make as much distinction as possible.

Best regards,

Peter

[Jon Marshall · Accepted solution]

Hi Peter

Actually you raise a very interesting point. Contradicting myself somewhat from my earlier post, DH does involve public/private keys but i think the main difference is that both keys are temporary, only being used to securely exchange a shared key.

So unlike certificates the public key is never actually published anywhere, it is simply generated on demand when the VPN is setup.

My understanding of DH is that it is indeed a form of asymmetric encryption although with a slight difference. The 2 sides exchange public keys and using their own private keys together with the other sides public key they then derive a shared key. This shared key will be identical. However this key is not a symmetric key but an asymmetric key apparently. I say apparently because i always thought a key that is the same at both ends is symmetric. However after doing some more reading it appears that this key, even though the same at both ends is still mathematically considered an asymmetric key and thus is computationally inefficient for bulk encryption.  (learn something new every day!)

This key is then used to further encrypt another key which is the symmetric key. Once this has been derived data exchange can then being.

So it really is a bit of a grey area in terminology terms. My understanding of certificates is that the additional step of of using an asymmetric key (which is the same at both ends) to encrypt a symmetric key is not needed but perhaps i have misunderstood that as well (further reading is needed i guess).

Apologies if you already know all this and i am just playing catch-up

Jon

[sarahr202]

HI Jon and Peter.

Thanks for responses.

I am going to quote from my book.

"  The longer the encryption key that needs to be exchanged,the longer the DH key needs to be"

i was reading about the "  DH option"  available in Diffie-Hellman key exchange.  

Keeping the above quote in mind,  can i use DH1-768 bit to encrypt DES -56- bit- share- key ?

Thanks and have a great day.

[Peter Paluch]

Hi Sarah,

Keeping the above quote in mind,  can i use DH1-768 bit to encrypt DES -56- bit- share- key ?

I believe this question is not quite correct. You can use the same 256-bit AES key to encrypt gigabytes of data. The statement about longer DH shared keys being necessary to support longer keys for symmetric ciphers most probably refers to the fact that the shared key is used in a key derivation function to produce a suitable key for a particular cipher, and if insufficient bits are available, the key derivation function may not have enough data from which a particular key is derived. If my memory serves, I have seen that if ISAKMP policy used DH Group 1, I was not able to use AES-256 in the IPsec transformation set - the IPsec tunnel simply did not came up. When I changed to Group 2 or Group 5, all was fine. Obviously, the Group 1 DH exchange provided too few bits of shared secret for the key derivation function.

Best regards,

Peter

[Peter Paluch]

Hello Jon,

I am glad you responded - and no, this is a fairly new territory for me so please continue challenging me

Let us talk about the basic DH exchange as described on the Wikipedia page I've referenced - there may be more sophisticated schemes deployed basing on DH in real life but for the sake of clarity, the basic DH exchange will suffice.

The article calls the numbers a and b as private keys, and numbers A and B as public keys. These numbers may be called that way but their usage differs from, say, the RSA, in several aspects:

• To exchange a shared secret in RSA, it is sufficient for either party to encrypt the shared secret using the other party's public key and send the encrypted data to it, i.e., it is not necessary for both parties to exchange public keys. In DH, both parties absolutely must exchange their public keys, otherwise they cannot arrive at the same shared secret.
• In RSA, the public key is used to encrypt a separate block of data to be used as a shared secret, i.e. the shared secret is generated first, only then it is encrypted via the other party's public key and sent to it. The shared secret, in other words, existed before the key exchange, and the RSA was merely used to protect it. In DH, there is nothing encrypted per se - you do not have a pre-existing block of data that is encrypted at one side, then transmitted and then decrypted on the other side, emerging in its original form. Rather, in DH, you are using both public keys to actually arrive at the same block of data that is going to be used as a shared secret. It did not actually exist before both parties exchanged their public keys. So in DH, the shared secret is a product of the public keys but it comes into existence only after the public keys are exchanged. I would therefore not call the DH an encryption. Surely, you cannot encrypt something that does not exist yet.

However this key is not a symmetric key but an asymmetric key 
apparently. I say apparently because i always thought a key that is the 
same at both ends is symmetric. However after doing some more reading it
 appears that this key, even though the same at both ends is still 
mathematically considered an asymmetric key and thus is computationally 
inefficient for bulk encryption.

Hmmm, I am afraid I cannot agree with this - are we on the same ground with the terminology? I am not familiar with asymmetric keys, at least if they come single and not in pairs - I know only about asymmetric ciphers. In any case, if there is only one key then the cipher cannot be considered asymmetric. What is true, however, is that the shared secret yielded by the DH exchange does not need to be directly used as the key in practical systems; rather, it can be used as an input to key derivation functions that will subsequently produce the keys to be used for actual ciphers. For example, the Group 1 in ISAKMP policies produces 768 bits of shared secret, the Group 2 produces 1024 bits of shared secret, and the Group 5 generates 1536 bits of shared secret. Any of these shared secrets is too long for common symmetrical ciphers, so a KDF is used to produce an appropriately sized key for the particular cipher - this is how I see it - please correct me if I am wrong on the subject!

I would love to read your thoughts on this.

Best regards,

Peter

[Jon Marshall]

Hi Peter

Firstly i think this is one of those areas where terminology is all important so i'll hold my hands up -

asymmetric key - you are correct in that asymmetric implies 2 keys (public/private) and not one so i should have said a symmetric key derived from a calculation using asymmetric keys.

Secondly i think it does depend on what you read ie. see the attached pdf (paragraph after Figure 2) which is where i read about the symmetric key (as above) being generated from the public/private key and that symmetric key is then used to encrypt a shared secret key which is the one actually used for data encryption. So according to this there is indeed a block of data that is encrypted.

Having said that, this is the only reference so far i have found that suggests this extra step. And i agree totally that using RSA certificates does not require this extra step ie. you can simply encrypt a shared secret with the public key and decrypt at the other end (hence my surprise in my previous post). So i'll do some more research on this. Unfotunately a lot of papers on the internet only give a very brief outline and they skim over the details, and not being particularly good at maths i find the "pure" papers a little difficult to follow

So in DH, the shared secret is a product of the public keys but it comes into existence only after the public keys are exchanged. I would therefore not call the DH an encryption. Surely, you cannot encrypt something that does not exist yet.

What is true, however, is that the shared secret yielded by the DH exchange does not need to be directly used as the key in practical systems; rather, it can be used as an input to key derivation functions that will subsequently produce the keys to be used for actual ciphers.

I guess this is where the specifics become important. Certainly with certificates the shared secret is directly encrypted with the public key without having to actually exchange public keys so something exists ie. the unencrypted shared key, to encrypt. With DH it depends on whether the key derived from the public/private keys is then used to encrypt a further key which is used for data encryption in which case there still is something to encrypt it just takes a bit longer to get there !  Or whether the key derived from the public/private keys is simply used as input to the algorithm that actually generates the shared key used for encrypting/decrypting data.

From memory, when i was doing a lot of IPSEC, i have to say that your version rings a bell for me. Perhaps i just read the wrong doc !

Jon

[Jon Marshall · Accepted solution]

Sarah

Haven't spoken to you for a while, hope everything is okay with you.

Not sure i fully understand your question.

If you intercept the key you cannot decrypt with with the public key because it was never encrypted with the private key.

A public/private key pair are linked as you say. If you encrypt with the public key you can only decrypt with the private key of that pair and vice-versa. The private key is never transmitted so it could not be intercepted and the shared key is never encrypted with the private key so even if you -

a) managed to intercept the encrypted shared key

and

b) obtained the public key from the private/public key pair

you still cannot decrypt the shared key.

The key thing to understand is that you only encrypt with the public key. So -

pc1 wants to send shared key to pc2. pc1 gets pc2's public key and encrypts the shared key. The only thing that can now decrypt that message is pc2's private key and that key is only known by pc2 and never transmitted. This is how public/private key pairs allow secure exchange of data.

Jon

[sarahr202]

Thanks Peter and Marshall.

Please disregard my last question concerning pc1.  As both of you mention  that public can not be used to encrypt  and decrypt the same data.

It is nice seeing you again Jon.

you guys have a great day  . ( i am going to study the responses)