[Swan-dev] And then there were two (PRF implementations)

[Andrew Cagney]

As in, we're down from three, or more ...  - so this is a good thing:-)

So, I'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  "prf(" and "prf+(" in rfc7296 and rfc2409 and see
rfc2104).

The motivation came from wanting to put our code through the test vectors
found in:
http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev1.zip
http://csrc.nist.gov/groups/STM/cavp/documents/components/800-135testvectors/ikev2.zip
which would let us "verify" our IKE and CHILD_SA crypto code.  I'm going to
import those files and add them to "make check".

Of course, nothing is easy.  We had a problem: our internal interfaces and
these test vectors did not align (they didn't exactly align with the RFCs
either ... :-).  This triggered a straight forward re-org.

Unfortunately, as is always the case, this just flushed out a bigger
problem: our existing code (once you figured out what it did) didn't even
implement IKEv2 child-sa-with-dh and skeyseed-rekey.  This triggered a
re-implementation of the underlying code.

The result (to be merged) is:

- the relevant test vectors run and pass (we don't do SHA-224 among other
things)

- we have tested code that generates (IKEv2) child-sa-with-dh and ike-rekey
keying material (we don't use it yet, lets ignore that :-)

- I suspect I even fixed a bitsize(pre-shared-key)==64 bug Paul found

Which is of course all good news :-^  The not so good news is that after
this we've still got two PRF implementations; sigh:

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 :-)

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20150421/f6199911/attachment.html>