<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>As in, we&#39;re down from three, or more ...  - so this is a good thing:-)<br><br></div>So, I&#39;ve been moving around, and occasionally breaking, the deck chairs pluto uses to generate its IKE and CHILD_SA keying-material  (the scrap wood got used to build crypt_prf, ikev2_prfplus and ikev1_prf_appendix_b versions) (look for  &quot;prf(&quot; and &quot;prf+(&quot; in rfc7296 and rfc2409 and see rfc2104).<br><br></div>The motivation came from wanting to put our code through the test vectors found in:<br><a href="http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev1.zip">http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev1.zip</a><br><a href="http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev2.zip">http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev2.zip</a><br></div>which would let us &quot;verify&quot; our IKE and CHILD_SA crypto code.  I&#39;m going to import those files and add them to &quot;make check&quot;.<br><br>Of course, nothing is easy.  We had a problem: our internal interfaces and these test vectors did not align (they didn&#39;t exactly align with the RFCs either ... :-).  This triggered a straight forward re-org.<br><br>Unfortunately, as is always the case, this just flushed out a bigger problem: our existing code (once you figured out what it did) didn&#39;t even implement IKEv2 child-sa-with-dh and skeyseed-rekey.  This triggered a re-implementation of the underlying code.<br></div></div><br></div>The result (to be merged) is:<br><br></div>- the relevant test vectors run and pass (we don&#39;t do SHA-224 among other things)<br><br></div>- we have tested code that generates (IKEv2) child-sa-with-dh and ike-rekey keying material (we don&#39;t use it yet, lets ignore that :-)<br><br></div><div>- I suspect I even fixed a bitsize(pre-shared-key)==64 bug Paul found<br></div><br></div>Which is of course all good news :-^  The not so good news is that after this we&#39;ve still got two PRF implementations; sigh:<br><br>crypt_prf.c.- used to generate &quot;secure&quot; keying material<br><br></div><div>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&#39;t be fooled by the hmac like crypt_prf.c interface, internally it manipulates symkeys).<br></div><div><br></div>hmac.c - used to authenticate packets sent across the wire (what else?)<br><br></div>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&#39;t as much shuffling of bits.  On the other hand, the result is stored in a byte buffer so &quot;security&quot; goes out the window :-) .  This isn&#39;t as bad as it sounds - the output is promptly broadcast across the internet :-)<br><br></div><div>So why didn&#39;t I merge them?  As I&#39;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&#39;t find it under the mound of NSS documentation :-^).  I think crypt_prf.h serves as a model for what is needed :-)<br><br></div><div>Andrew<br><br></div></div>