[Cryptech Core] libhal / PKCS #11 status

[Leif Johansson]

On 2015-06-23 21:19, Rob Austein wrote:
> Brief update on current status, for those who have not been able to
> infer it from the commit history.
> 
> libhal has (apparently, somewhat tested) working implementations of
> AES keywrap, PBKDF2, RSA, HMAC, and the usual hash functions, as well
> as an interface to our CSPRNG.  Software bignum support (where needed,
> currently only in the RSA code) comes from libtfm (an aggressively
> open-source package written by Tom St Denis, somewhat easier to read
> than the Eric Young bignum code used by OpenSSL and Cryptlib).
> 
> I've rewritten my pkcs11 code to use libhal, and, as of last night,
> the result passes the same basic DNSSEC signer test as the earlier
> (Cryptlib-based) version did.

This sounds to me like a major milestone for us! Really cool!!!

> 
> I ended up not using any of Cryptlib's code for libhal, not because
> I've given up on Cryptlib (I haven't) but because the relevant bits of
> Cryptlib are fairly tightly integrated into the rest of Cryptlib (no
> surprise, no blame, that's the mission they were designed to support)
> and it turned out to be simpler get the job I needed done via a
> different path.  Will revisit this decision when I get back to
> Cryptlib support (read: when I have time to work on the RPKI signer).
> 
> The RSA implementation can use either the ModExp core or the
> equivalent software implementation from libtfm.  Obviously we'd prefer
> the former, but the most recent version I have (about a month old) is
> unusably slow with large keys at the moment and I was wasting too much
> time waiting for test runs to complete.
> 
> That's where things stand today.  There are a few missing bits around
> the edges (eg, the out-of-band code to set initial PINs -- right now
> I'm just whacking magic values directly into the database).
> 
> No ECDSA support yet, sorry.
> 
> Next step for me unless somebody has a better suggestion is to get
> this code to survive testing by hsmbully.  Right now it doesn't get
> very far for silly reasons (C_GetMechanismInfo() NIY), so I'll be
> working on that unless somebody has a better idea.
> _______________________________________________
> Core mailing list
> Core at cryptech.is
> https://lists.cryptech.is/listinfo/core
>