On Tue, 21 Apr 2015, Andrew Cagney wrote: Thanks for the background story on this :)
- I suspect I even fixed a bitsize(pre-shared-key)==64 bug Paul found
I'll double check the == 64 and > 64 issues are gone.
Which is of course all good news :-^ The not so good news is that after this we've still got two PRF implementations; crypt_prf.c.- used to generate "secure" keying material This version tries to keep things secure by using PK11SymKeys for everything (...). Since the NSS hash function at the core of the PRF code takes a SymKey and returns a SymKey we expend a noteable mount of code (but probably not much time) concatenating SymKeys (and bits). (Aside #1 I suspect Pluto could do better at storing more keying material in SymKeys). (Asside #2 don't be fooled by the hmac like crypt_prf.c interface, internally it manipulates symkeys). hmac.c - used to authenticate packets sent across the wire (what else?) This uses a lower level, and slightly more efficient, hash interface. Since the low-level interface lets you feed the hash code raw buffers and symkeys there isn't as much shuffling of bits. On the other hand, the result is stored in a byte buffer so "security" goes out the window :-) . This isn't as bad as it sounds - the output is promptly broadcast across the internet :-) So why didn't I merge them? As I've tried to explain, they have different security vs performance trade offs. In my opinion, merging them really requires NSS to add a secure low-level hash interface (Perhaps it is already there, I couldn't find it under the mound of NSS documentation :-^). I think crypt_prf.h serves as a model for what is needed :-)
On an IKE/IPsec server, I'm not very concerned about IKE performance. The bulk of the CPU will be doing packet encryption/decryption I hope. So the only performance concern is for DDoS attacks. And I don't think hashing is the worst part in that compared to the DH work? So I'm fine with consolidating this to one, even if it is the "slower" one. Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
