So I’ve maybe caught your attention with the title of my blog. How can these two disparate subjects possibly be related? Well there are actually a couple of angles. First, the company I work for, Entrust Security, has an active Cambridge Crypto Whisky Club (CCWC) formed from current and past Entrust malt whisky enthusiasts who meet on a regular basis to share a few drams (usually the proper single malt stuff) from around the world. A few years ago I participated in the CCWC Grand Tour to the Isle of Islay (pronounced Eye-la) one of the beautiful islands off the north west coast of Scotland, famous for its smoky, peaty malt whiskies. Half a dozen of us from the CCWC spent a fabulous three days touring the island visiting the distilleries including Lagavulin, Laphroaig, Caol Ila, Ardbeg and Bowmore. So Entrust crypto developers and cryptographers appreciate a good whisky!

The second angle is one of time and maturity. Whisky as many of you will know comes out of the copper stills as a clear and pure spirit. The tone and rich, complex flavours of malt whisky come from being matured in second-hand oak barrels that have been previously used in the production of other alcoholic drinks such as bourbon, sherry, port or rum. The inside of the oak barrels are typically charred before being filled with the spirit alcohol and left to mature for a minimum of three years, but usually 10, 12, 15 years or more. It is the chemical reaction between spirit and charred wood that makes malt whisky so distinctive. Good things take time to mature!

In the world of cryptography things also take time to mature. For example, consider back in January 1997 when the National Institute for Science and Technology (NIST) first invited the cryptography community to join in the process of replacing the DES algorithm which was known to be vulnerable to brute force attacks. Nine months later NIST invited the crypto community to submit their suggested replacement algorithms. A further nine months on, invitations were closed with 15 candidate algorithms submitted for consideration. In August 1999 NIST announced they had narrowed the field from fifteen to five: MARS, RC6, Rijndael, Serpent, and Twofish. And on October 2, 2000, after detailed cryptanalysis from NIST and other interested parties around the world, NIST announced Rijndael as the new Advanced Encryption Standard (AES). A year later, on November 26, 2001, it was approved as FIPS PUB 197. So looking back it took roughly four years to bring a shiny new algorithm to the market. Twenty years later and AES is still the gold standard for symmetric encryption today so the industry’s inclusive, transparent process has been demonstrated to be a success – ensuring good acceptance in the market.

So where does quantum cryptography tie into this blog? Well a new algorithm selection process is already in play by NIST for a set of quantum resistant algorithms. NIST has also recently published a draft white paper, Getting Ready for Post-Quantum Cryptography: Explore Challenges Associated with Adoption and Use of Post-Quantum Cryptographic Algorithms. The paper outlines the challenges we’ll face once exploitation of Shor’s algorithm becomes practical – a topic I covered in a previous blog – Quantum TV. The new NIST paper states that “algorithm selection is expected to be completed in the next year or two, and work on standards and implementation guidelines will proceed expeditiously.” However, it then goes on to say “experience has shown that, in the best case, 5 to 15 or more years following the publication of cryptographic standards will elapse before a full implementation of those standards is completed.” 5 to 15 years is a substantial amount of time! A cask of single malt whisky could be fully matured in that same timeframe! I put in a call to my colleague Pali Surdhar, Entrust Security’s Chief Security Officer to get his perspective on the draft white paper. Pali acknowledged that the 5 to 15 year timeframe was a sizeable amount of time but not a total surprise. Pali reminded me that good crypto takes a long time to gestate from postulation through detailed industry cryptanalysis and selection to actual practical algorithms that can be used in enterprise and industry.

However, while the crypto (like a good whisky) may take time to mature, as the white paper reminds us, even though it feels like a long time away we should resist kicking this one into the long grass. As the authors state, “We need to determine where, why, and with what priority vulnerable public key algorithms will need to be replaced, and we need to understand the constraints that apply to specific use cases. These initial steps in developing and implementing algorithm migration playbooks can and should begin immediately.“

Usefully the white paper does provide some help here and outlines some initial discovery steps to support planning migration to post-quantum cryptography. Here’s the examples they provide:

  • Outreach to standards organizations to raise awareness of necessary algorithm and dependent protocol changes (e.g. IETF, ISO/IEC, ANSI/INCITS X9, TCG)
  • Discovery of all instances where Federal Information Processing Standards and NIST Special Publication 800-series documents will need to be updated or replaced
  • Identification of automated discovery tools to assist organizations in identifying where and how public-key cryptography is being used in systems that are connected to data centers and distributed network infrastructures
  • Development of an inventory of where and for what public-key cryptography is being used in key enterprises

So that all sounds like good common sense for any team working in crypto, putting some rigour and process in place.

Next the white paper lists the usage characteristics that should be considered and captured in the context of a public key infrastructure (PKI) deployment.

  • Current key sizes and hardware/software limits on future key sizes and signature sizes
  • Latency and throughput thresholds
  • Processes and protocols used for crypto negotiation
  • Current key establishment handshake protocols
  • Where each cryptographic process is taking place in the stack
  • How each cryptographic process is invoked (e.g., a call to a crypto library, using a process embedded in the operating system, calling to an application, using cryptography as a service)
  • Supplier(s) and owner(s) of each cryptographic hardware/software/process
  • Source(s) of keys and certificates
  • Contractual and legal conditions imposed by and on the supplier
  • Intellectual property impacts of the migration

Again it’s all good common sense – stuff that any security team should be capturing and documenting as part of their crypto agility planning.

So for me, the main take away is start planning. Like a good single malt the post-quantum resistant algorithms will take time to mature, but keep yourself in the loop and perhaps review, comment and contribute to white papers like the one I’ve just discussed.

Back to the CCWC. Despite lockdown we’ve managed to keep things ticking over. There have been several virtual whisky nights over the past few months and I’m waiting on a set of miniature bottles to arrive by post for the next one. Happy days!