[Openswan dev] Openswan + FIPS thoughts

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "David" == David McCullough <David_Mccullough at securecomputing.com> writes:
    David> We are considering two possible approaches:

    David> 	1) Replace all the libgmp/crypto code in Openswan user
    David> space to use libssl/openssl exclusively.  This will mean we
    David> have a single point of testing/implementation for FIPS.  It
    David> also means that OpenSwan will continue to use OCF for user
    David> space as appropriate, but can also take advantage of the many
    David> other openssl engines and accelerators.

    David> 	2) The second, perhaps not so pretty solution, is to
    David> hook everything in openswan userspace as has been done
    David> already for OCF, but to do it for everything that FIPS cares
    David> about.

    David> I am not sure of the history here, so perhaps there is a
    David> reason why it should or shouldn't be done this way or that.

  The history is several fold:
  a) FreeSWAN couldn't be sure of the origin of the libssl code
     (back 10 years ago), and so was cautious.
  b) libssl is significantly overkill if you just need to do DH
     calculations, and you don't want to use certificates.
     And libssl has never had very good documentation, or very good
     testing.  
  c) openssl/libssl does experience a large number of CVEs. While
     replacing the .so is easy, the .so is also way-overkill. It
     requires pthreads, and all sorts of stuff, and that really hurts
     on small platforms, and makes linking pluto statically annoying.

  I am happy with the libgmp code we have, I think it's easy to
understand, and really compact.

  I would suggest that the right thing to do is to slightly refactor the
crypt_*.c files, to split the OCF, gmp "invoke" code into seperate
files.  Then replace the gmp code with calls to openssl routines in
seperate C files.  That should be really easy to unit test.
  (see testing/crypto/pk-dh-01 in 2.5.xx series, and in the OCF-rich
3.xx series, there are half a dozen unit tests too)

  Alternatively, you could use the OCF interface and provide software
implementations of the bignum operations in your kernel, if you don't
always have hardware that is useable.

  Then, you can have a makefile option which decides if you are going to
use the GMP code, or the Openssl code. 
	
    David> Would switching from libgmp/ouwn crypto to a completely
    David> libssl solution for the big num and user space crypto code be
    David> attractive to the openswan community ?

  I would accept the code to optionally use it. 

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRyi+EoCLcPvd0N1lAQJAGAf9ELICZOTBalQMYWKxW42VflD1crMV2gGY
8eP95RLOd51hAOVfNcGEyHetZ+jpHioz/NtWcqgFHtYa8P680UcFCrLpDiLyQ2fz
oL9tyb8AxPa7J7mkP6yyFU5s5dIfJYHLPKJv4BYHgIy5jLxUzXXVZd0Jb/ngIs9O
CtA/hcvENqoXbPU5mEPgAcumju2f1desubkblql4oNxBD78ZqDjUDMW/vkYdrxnD
p4nhvVTO5xbMY5y2G2H3PlKx33H8mloGQomHkQm5QwNv1vjrDicHddLda8p+wih7
x56m2cMt6NIxZhoay2CC2J1rV0JNKgSbmYPyEpyY11jKLDkviHZLyA==
=9XUy
-----END PGP SIGNATURE-----