We're deploying ipsec on embedded devices and getting catastrophic performance from the diffie hellman 2048 group in ike.. afterwards the shared securet is used for 3des, sha1. ipsec negiation is well over 20s for a single tunnel.. the network stack is using openssl to the negotiation
Am I correct to say that 1024 is sufficiently secure for use in DH, in this context ? My understanding is that dh 1024 is ok to negotiate ipsec sa with lifetime of 24 hours until such a time as dh 1024 can be forced in < 24 hours. That is very unlikely to be before 2030
There's no confidentiality requirement so we dont care if someone can decrypt the traffic after 24 hours, as long as they cant re-inject it or tamper with current packets that's fine.
The reason given to use dh 2048 is because "1024 is no longer secure".. I've nothing against dh 2048 but given the performance problem i'm trying to push the 1024 group. I dont want to do that if I've missed some problem though.
The advice that 1024 is insecure relates to long lived (1-2 year) RSA keys. As DH negotiates short lived (24 hour) session keys, DH in 1024 group is ok for us.
In the use of dh in 2048 group, then the resulting shared secret has 160 bits of security which cant be forced for 10 - 15 years. 10-15 years because rsa 2048 is considered safe until 2030 and I'm assuming dh 2048 is similar
If dh in 1024 group is used, then the resulting shared secret is probably safe for a few years. The RFC 2409 which defines dh 1024 for ike says it generates more than 160 bits of security. It should however be twice the number of security bits needed, we need 224 as 224 = 2 * 112 and 3des needs 112. So what is meant by "more than" in the rfc.
By default, openssl generates the dh secret as a random number of length equal to the dh shared prime, so i'm thinking it will be at the large end of what the "more than" means.. I'm not sure how to verify that though
RSA 1024 hasnt been forced yet but is expected to be in near future, probably with months or years of computation. However, our product will still be in use in 10 years time. Maybe RSA 1024 will be easily forceable in 2025, as long as it takes more than a day dh 1024 is still ok. (I'm not saying dh 1024 will be a good choice in 2025, i'm saying if we choose it today then we wont have to phase it out before 2025)
The shared secret resulting from our dh is only used for 24 hours. SA lifetime is 24 hours so we're going to renegotiate our tunnels every 24 hours. That means a new DH secret every 24 hours. So as long as dh 1024 cannot be forced in a 24 hour period it's ok for us to use dh 1024. As long as we think it will still take more than a day to DH 1024 the resulting shared secret of a dh 1024 can be forced in maybe a few weeks.
Follow up question, if we use 3des tat needs 112 bits of security, DH should generate twice as many bits as needed, but DH 1024 only generates 160 bits.. How big a problem is that in practice ?
We also have the option to modify the negotiation, we could say with dh 2048, but generate the secret in a smaller value space. In openssl we can set the q parameter on the DH structure to determine the number of bytes to generate in DH_generate_key.. that seems less attractive an option than using dh 1024 however
If this doesnt hold water could somebody correct me ? thanks