|
Home > Archive > 70-216 > December 2003 > Diffie-Hellman
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Tech Ranger 2003-12-07, 7:14 pm |
| I have tried to understand how IPSEC can secure data and authenticate machines especially when a CA is not used. My research has taken me to Diffie-Hellman. I have read that DH initially involves the creation of public and private keys and that the public keys are exchanged. The literature I have read acknowledges what I figured on my own which is the susceptibility inherent in this exchange. If DH is used to securely exchange encrypted session keys how can it use as part of its algorithm the open exchange of public keys? The public keys ultimately are used to create the shared secret which encrypts the session key. It seems to me also that an unsigned public key is a strange animal. Does anyone out there understand Diffie-Hellman? | |
|
|
|
| oh and heh miss the other part.
public key.
public key require CA, may be public, or private, doesn't matter, the authentication issue is their problem, not the problem of session authentication.
to authenticate, for example cisco stuff
3 methods
1. preshared key
2, ca
3. RSA nounces, a random number.
they also require a peer id, IP or name
now this is IKE phase 1, DH happens here
for example, command in cisco would be like
crypto isakmp sfjksdfksihdflsfjksjfjsf address 111.111.111.111
then you know the rest.
this is phase 1, phase 2 is ipsec stuff. | |
| Tech Ranger 2003-12-07, 7:58 pm |
| My point is who is to stop a man in the middle from intercepting the freshly generated public keys and without a signature how do the machines know that the public keys come from whom they are supposed to? Diffie-Hellman uses this complex Einsteinian algorithm to create the shared secret without sending out over the network, but the process still involves this initial sharing of public keys. | |
|
| cuz public key require the use of CA, the CA can be a public or a private authority, no matter, it goes through the same authentication process anyway, even if it authenticate to some gimp machine in your cube.
that's process 1.
if you do not have a CA set up to authenticate all your network devices for whatever reason, then your choice is to use another method, the method often use is pre-shared key...
now... as far as preshared key is concern, there is still a best practice regarding htat... and preshared key is not sent across the network, so that's not an issue.
when you use your own CA, there is no difference in your understanding of hijack, it is the same, what issue exist there exist here, what is secure there is secure here also.
*** EDIT ****
hmmmmm... I thought I stated as much in the other post... so let me try again. tired and not thinking clearly at the moment...
your confusion is in that you think that when we do not involve CA, public key is use, or that using a public key iwthout involvement from a well known CA does not involve the authentication process associated with using a certificate. Someone still has to sign it anyway. Again, the CA can be a recognized authority or one in hte internal organization.
Say if you have 200 network devices, you may want to have your own CA. so you take 2 machines, 1 root CA locked off line, 1 out side. boom, that CA/public key process is just the same as it would be if the certificate is issued by verisign.
so to sum up, machines don't just randomly generate a public key, probe an ipsec partner on the internet and tell it to use this key to set up a VPN session with them. concept of public/private key exchange require a signee, and that signee can be publicly recognized or a private authority so that device receiving the request would still go, hmmm here someone sent me this, let me confirm it with the CA my admin configure... same authentication process. | |
| Tech Ranger 2003-12-08, 8:50 am |
| I reread Diffie. I think I get it now, but I find it mind boggling. According to Diffie, the shared secret cannot be derived from possession of the 2 public values. So, this is my understanding:
2 people each choose a random number independently.
They both apply the same publicly available mathematical formula to their numbers.
The result is that they each end up with a private value and a public value.
They send each other their respective public values.
Using their private values and the other guys public value they each apply a publicly available formula.
The result is that they each end up with the same value, which they use as a key.
An outsider listening to these guys gets both the public values. He knows the formula, but he can't discern the key. | |
| jocampo 2003-12-08, 9:24 am |
| quote:
Originally posted by Tech Ranger
I reread Diffie. I think I get it now, but I find it mind boggling. According to Diffie, the shared secret cannot be derived from possession of the 2 public values. So, this is my understanding:
2 people each choose a random number independently.
They both apply the same publicly available mathematical formula to their numbers.
The result is that they each end up with a private value and a public value.
They send each other their respective public values.
Using their private values and the other guys public value they each apply a publicly available formula.
The result is that they each end up with the same value, which they use as a key.
An outsider listening to these guys gets both the public values. He knows the formula, but he can't discern the key.
Tech, do you speak/understand spanish? I have a good article for this made by myself, but it is in spanish. | |
| Tech Ranger 2003-12-08, 9:34 am |
| me gustaria muchisimo recibir su articulo. Esta tema me facina bastante. Muchas gracias por su oferta. Favor de mandarmelo por PM. | |
| jocampo 2003-12-08, 9:40 am |
| Diffie/Hellman encryption uses symmetric, not asymmetric encryption. Asymmetric encryption is most related with PKI. You encrypts the message with Diffie/Hellman alglorythm, symmetric...ONE KEY. But you will use PKI and Certificates, in order to exchange the 1st and unique Symmetric key encryptions. Says, for example, that the unique encryption is: 1&$Jklm^ ....
...ok...the 2 machines will use Certificates (Public + Private Keys) to exchange this UNIQUE key. The client has the Public Key (all W2K Microsoft Os comes with hundreds of CAs preinstalled) and the Server has the Private Key. So...in the network, the 1st key...the unique key, used for encrypts the data, travels secure on the network, because PKI is in charge of this.
 | |
| jocampo 2003-12-08, 9:41 am |
| quote:
Originally posted by Tech Ranger
me gustaria muchisimo recibir su articulo. Esta tema me facina bastante. Muchas gracias por su oferta. Favor de mandarmelo por PM.
Hola Tech, este tema es SUPER interesante! No es complicado si se estudia de las fuentes o libros correctos. Te lo envio ahora mismo por PM. | |
|
|
|
|
|