It is more like:

Pick any two: Fast, Secure, Cheap

You can make a very fast and secure product, people just won’t be able to afford it.

Similarly, you can make a fast & cheap solution, but it won’t be secure.

I’ve always believed it is a three-way trade-off between those variables.

It seems that the router does an ARP request on the Tomahawk server side but Tomahawk does not react.
Is this a know problem of the patch?

Thanks
Joris

If your generator (g) is 2 and if K_a only has 1 bit set (i.e. it is a power of 2), then log_g (K_a) is trivial. The K_a should be rejected.

I don’t see why only the initiator would want to ensure that they are sending strong keys. Look at OpenSSL’s verification. They check for the valid range and check to see if the key is a power of two ( twice for some reason ). Also, this does not address the issue of *protecting yourself*, which is the real problem IMHO.

The code for verification of generated and received keys is extremely basic. If I have time, I will look into writing a patch and unit test, but it’s your call whether or not you want to hinder the security of your system because you insist on every branch in the code having a unit test.

I don’t understand your argument against using INVALID-KEY-INFORMATION. NO-PROPOSAL-CHOSEN is not authenticated in phase1 either, but they both would be during phase2.

Finally, I sent an email to security@xelerance.com last month in an attempt to discuss this issue with your team. The gpg key advertised on openswan.org is broken, and I had to search for a while to find one that was not expired. Perhaps if your team would have been more willing to discuss security issues in OpenSwan, we could have had a less heated discussion concerning the non-conformant behavior that OpenSwan exhibits.

2) I see your point about an exponent of 0.

3) how can the initiator believe the INVALID-KEY-INFORMATION notify (which is not authenticated) to really be from the responder, and not the MITM?

Please see the update to the blog, it may answer some of your complaints.

You are correct in that an exponent of 1 will probably never occur. The point you missed is that an exponent of 0 is impossible.

You are also correct when saying that the pre-shared-key is never sent over the wire, and the attacks I described do not recover secret keys. This is all besides the point of the blog post, however.

As for what to do when a bad key is detected, there is a convenient informational message “INVALID-KEY-INFORMATION” which can be sent back to the peer. Are you suggesting that an invalid hash should also be accepted because the negotiations would have to re-start?

As for testing, I really don’t see your point. It took me a few minutes to grep through ike-scan and create a patch to test key validation.