CrypTech releases version 4.0

The Cryptech Project is pleased to announce that version 4 of our firmware and software package is now available.  Like versions 2 and 3, this runs on the Alpha board.

While most of this code became available without much fanfare as we finished writing it, it’s been quite a while since we last bumped the version number and announced new binary packages, and a lot has happened.


* New high speed ModExpNG core with CRT and RSA blinding factor support
* Clock FPGA synchronously from FMC bus with multipliers, to eliminate clock domain crossing bottlenecks
* New AES-keywrap core with direct connection to master key memory
* AES performance improvements
* SHA-2 timing fixes to support higher clock rates
* Redesign EC cores, adding support for ECDH (P-256 & P-384) and Ed25519
* Support for hash-based signatures
* Various I/O speedups on FMC bus
* Various fixes to Verilog synthesis placement and routing issues
* Faster prime generation algorithm (RSA key generation)
* API hardening and code cleanup in various Verilog and C modules
* Profiling and timing code to see where the HSM is spending its time

See git commit logs for more details.

See for information on how to download the new packages.  Please also note that if you have an old copy of the Cryptech repository GPG key you will almost certainly need to update it, as the old self-signature will have expired.

If you have keys that you care about on your HSM, we recommend backing them up before upgrading using the cryptech_backup tool.  Assuming you have only a single HSM, you will need to use the “soft backup” option (using a software-generated key) rather than backing up to another HSM.  Basic backup procedure using a software-generated backup key:

cryptech_backup setup -s -o kekek.json
cryptech_backup export -i kekek.json -o backup.json

… perform upgrade here …

cryptech_backup import -i backup.json
shred -u kekek.json backup.json

If the upgrade fails in some horrible way that bricks your HSM, see: and

CrypTech 2019 End of Year Report Available

The CrypTech End-of-Year Report for 2019 is now available. Progress on the CrypTech project has slowed considerably due to a serious slow-down in funding. However, we were still able to implement several FPGA enhancements, which added up to a more than 10x improvement in RSA signing speed.

At the end of 2018, CrypTech wrapped up its time under the administrative umbrella of NorduNet and SUnet and moved to the Commons Conservancy/NLnet Foundation. 2019 was CrypTech’s first full year as part of the Common’s Conservancy.

Finally, although CrypTech’s first commercial user, Diamond Key Security, NFP, shipped prototypes in 2018 and was well on its way to completing a commercial offering, it was unable to get sufficient funding to ship a supported product and ended up closing its doors. Acquiring funding remains the critical issue for CrypTech to continue and advance.

There is a link to the report on the main CrypTech website page or you can find it here:

CrypTech End-of-year Report for 2019

Thanks once again to all our supporters for past support and continuing support. Information about contributing to CrypTech can be found at:

CrypTech 2018 Report Available Now!

The CrypTech End-of-Year Report for 2018 is now available. The CrypTech project continues to make excellent progress. In 2018 we completed the implementation of hash-based signatures, Ed25519 cores, and continued to make improvements to the performance of the device. In addition, we completed an external security audit, published the results, and implemented the corrections. Additionally, at the end of 2018, CrypTech transitioned its administrative activities from NorduNet/SUnet and moved to the Commons Conservancy/NLnet Foundation. CrypTech’s first commercial user, Diamond Key Security shipped its first prototype HSMs incorporating the CrypTech Alpha device.

There is a link to the report on the main CrypTech website page or you can find it here:

CrypTech End-of-year Report for 2018

Thanks once again to all our supporters for past support and continuing support.

CrypTech implements hash based signatures

We are pleased to (belatedly) announce the implementation of hash-based signatures for the CrypTech project.  This work was discussed in the Internet Research Task Force (IRTF) Crypto Forum research group (cfrg) last year and announced in July 2018 on the technical mailing list for the CrypTech community ( This hashsig code is a clean-room implementation of draft-mcgrew-hash-sigs.  It has been shown to interoperate with the Cisco reference code (each can verify the other’s signatures).

Following the recommendations of the draft, we only store the topmost hash tree (the “root tree”) in the token keystore; lower-level trees are stored in the volatile keystore, and are regenerated upon a system restart.

This implementation has limitations on the number of keys, size of one time signature (OTS) keys, and size of signatures, because of the design of the keystore and of the RPC mechanism:

1. The token keystore is a fairly small flash, partitioned into 2048 8096-byte blocks. Therefore, we can’t support Leighton-Micali signature (LMS) algorithm types lms_sha256_n32_h10 (a.k.a. h=10, or 1024 keys per tree). In this case, keygen will return HAL_ERROR_NO_KEY_INDEX_SLOTS.

Additionally, the 8KB key storage size means that we can’t support LM-OTS algorithm type lmots_sha256_n32_w1, which has an OTS key size of 8504 bytes. In this case, keygen will return HAL_ERROR_UNSUPPORTED_KEY.

2. The volatile keystore is currently limited to 1280 keys, so only 2 levels at h=10, but more levels at h=5. One could easily increase the size of the volatile keystore, but L=2/h=10 gives us a key that can sign 1M messages, which is sufficient for development and testing purposes.

3. The RPC mechanism currently limits request and response messages to 16KB, so we can’t generate or verify signatures greater than that size. In this case, keygen will return HAL_ERROR_UNSUPPORTED_KEY.

Because the hashsig private key consists of a large number of one-time signing keys, and because only the root tree is stored in flash, it can take several minutes to reconstruct the full tree on system restart.During this time, attempts to generate a hashsig key, delete a hashsig key, or sign with a hashsig key will return HAL_ERROR_NOT_READY.

A hashsig private key can sign at most 2^(L*h) messages. (System restarts will cause the lower-level trees to be regenerated, which will need to be signed with by the root tree, so frequent restarts will rapidly exhaust the root tree.) When a hashsig key is exhausted, any attempt to use it for signing will return HAL_ERROR_HASHSIG_KEY_EXHAUSTED.

There are some trade-offs between keygen/signing time and key/signature size. As noted, w=1 produces keys that don’t fit in the keystore, while w=8 produces the smallest keys but excruciating keygen and signing times. The sweet spot seems to be w=4, where keys and signatures are about half the size of w=2, keygen is a bit slower, and signing is actually a wee bit faster (for reasons I haven’t fully explored).

Performance is not great at the moment. The keystore is slow, AES keywrap/unwrap is slow (although we’re working on it), and hashing is not super fast.

Also, there seems to be a bug in cryptech_muxd, where writing a signature of more than about 9000 bytes (for verification) causes a Tornado write timeout and exception in the RPC side of the muxd. (Reading the signature is fine.) This propagates back to the caller as HAL_ERROR_RPC_TRANSPORT. We’re looking into it, but didn’t want to hold up the hashsig code, since the error doesn’t seem to be in the hashsig code itself, hashsig is just the only thing the produces signatures long enough to trigger this behavior.

The test log posted to the tech mailing list shows the signature and key sizes, keygen and signing times, and the RPC transport error (see

There is one new RPC function: hal_rpc_pkey_generate_hashsig(), and functions to translate public keys between the SPKI format that we use and the XDR format specified in the draft: hal_hashsig_key_load_public_xdr() and
hal_hashsig_public_key_der_to_xdr(). Other than that, signing and verification are the same as with RSA and ECDSA keys. There’s no example code per se, but libhal/tests/test-rpc_hashsig.c should contain enough clues to get you started.

Paul Selkirk

CrypTech 2017 Annual Report is now available

The CrypTech End-of-Year Report for 2017 is now available.  It includes a summary of the work completed during 2017 including a new release of software for the CrypTech Alpha focused on improvements and optimizations. The list of accomplishments includes an improved keystore, multicore resource management, Verilog work on ECDSA point multiplier and Ed25519, and various bug fixes and performance enhancements.

Also in 2017, Diamond Key Security was established and is now working collaboratively with CrypTech on long term product development and sustainability for CrypTech.

There is a link to it on the main page or you can find it here:

CrypTech End-of-year Report for 2017

Thanks again to all our supporters for past support and continuing support.