cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3245
Views
5
Helpful
1
Replies

Symmetric encryption Asymmetric encryption

NDP
Level 1
Level 1

I read through few documents and see that IPsec uses asymmetric key cryptography in Phase 1 to create ike SAs and symmetric key cryptography for IPsec SAs which is bulk data .

 

Can someone please confirm if this is true. which key ( symmetric key or asymmetric ) the pre-shared key defined for specific peer belngs to . 

 

Thank you in advance

1 Accepted Solution

Accepted Solutions

As a rule of thumb: Whenever userdata needs to be protected, symmetric crypto is used as it's build for this task and is much faster then asymmetric crypto. Asymmetric crypto is not build for protecting big amounts of data.

With that, the IPsec SAs use only symmetric algorithms to protect the data.

For Phase 1, it depends on the way authentication is done.

If you are using PSKs and router1 wants to authenticate router2, there is the following process involved (slightly simplified):

  1. R1 sends a nonce to R2. This is basically a random nummer.
  2. R2 takes this nonce, hashes it together with the PSK and sends the result back to R1.
  3. R1 uses it's own generated nonce and the PSK and computes also a hash.
  4. If the received hash and the local computation are the same, R1 knows that R2 did the computation with the nonce that R1 provided and used the same PSK as R1: R2 is authenticated.
  5. In IPsec, these authentication is done mutually, also R2 authenticates R1.

No asymmetric crypto is involved when PSKs are used which makes the processing quite fast.

If you use digital certificates for authentication (method rsa-sig in the config) then the following happens (even more simplified):

  1. R1 sends a nonce to R2. This nonce gets hashed and the hash is encrypted with R2s private key (here we have asymmetric crypto). If a hash gets encrypted with a private key, the result is named a digital signature.
  2. The signature is sent back to R1.
  3. R1 uses the certificate of R1 to prove the correctness of the signature which is again an asymmetric crypto operation. Before that, the received certificate has to be validated which also involves one ore more asymmetric crypto operations.
  4. And the same happens the other way round. 

With authentication done with digital certificates we have asymmetric crypto.

In addition to that, there is also asymmetric crypto involved when DH calculates keymaterial for the session-keys.

View solution in original post

1 Reply 1

As a rule of thumb: Whenever userdata needs to be protected, symmetric crypto is used as it's build for this task and is much faster then asymmetric crypto. Asymmetric crypto is not build for protecting big amounts of data.

With that, the IPsec SAs use only symmetric algorithms to protect the data.

For Phase 1, it depends on the way authentication is done.

If you are using PSKs and router1 wants to authenticate router2, there is the following process involved (slightly simplified):

  1. R1 sends a nonce to R2. This is basically a random nummer.
  2. R2 takes this nonce, hashes it together with the PSK and sends the result back to R1.
  3. R1 uses it's own generated nonce and the PSK and computes also a hash.
  4. If the received hash and the local computation are the same, R1 knows that R2 did the computation with the nonce that R1 provided and used the same PSK as R1: R2 is authenticated.
  5. In IPsec, these authentication is done mutually, also R2 authenticates R1.

No asymmetric crypto is involved when PSKs are used which makes the processing quite fast.

If you use digital certificates for authentication (method rsa-sig in the config) then the following happens (even more simplified):

  1. R1 sends a nonce to R2. This nonce gets hashed and the hash is encrypted with R2s private key (here we have asymmetric crypto). If a hash gets encrypted with a private key, the result is named a digital signature.
  2. The signature is sent back to R1.
  3. R1 uses the certificate of R1 to prove the correctness of the signature which is again an asymmetric crypto operation. Before that, the received certificate has to be validated which also involves one ore more asymmetric crypto operations.
  4. And the same happens the other way round. 

With authentication done with digital certificates we have asymmetric crypto.

In addition to that, there is also asymmetric crypto involved when DH calculates keymaterial for the session-keys.