On Thu, Apr 10, 2014 at 11:43:22AM -0400, Paul Wouters wrote: > And use 15 year old cryptographic code that has seen no audit?
Well that was a different problem. Almost everything uses openssl or gnutls. Picking the 3rd but not very common option is rather annoying for embedded systems. > And having to extend that old code that only supports AES/3DES and > MD5/SHA1 with newer algorithms to support SHA2, SHA3, AES-GCM, AES-CCM, > AES-CTR, and IPsec suite B Elliptic Curves? > > And than who will pay to audit/certify that code? > > We had to switch to a library to do this work. As the codebase already > supported using NSS instead of our old code, we opted to continue > that path. Hmm, I hadn't realized it already had some NSS support. > The same is true for the X.509 support required, and adding to the code > that deals with ASN.1/X.509 parsing of the above mentioned new crypto. > > And this is true not only for the userland, but also applies to KLIPS > versus NETKEY/XFRM. We gave up on klips many years ago in favour of netkey. > Now, we only use a very small portion of NSS, and perhaps we can talk to > the NSS people about factoring that out into a separate smaller library. It might reduce the size a bit, but I don't see it reducing the verification/certification work. Oh well I guess triplicate crypto is the future we are stuck with then. > We understand the pain of having to add NSS to embedded platforms. But > there is really no alternative. The only switching that is possible > would be from NSS to openssl. It would make life easier on embedded > platforms that already need openssl. But for us it adds the overhead > of all the certificate loading/parsing code as openssl does not have > the same concept as the NSS DB for a "store" of cryptographic information. So any work on the openssl option that paul mentioned about a year ago as a future option? Of course openssl's crazy license makes trouble for some projects too. Of course I am wondering what kind of work will be involved in generating the nss database each boot from the configuration database. Probably not too hard. -- Len Sorensen _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev