Gânduri Eclectice – Eclectic Thoughts

…but it might not be as onerous as you imagine.

Let’s dive right in; there is no time like the future!

• PQ What? PQC: Post Quantum Cryptography.
• Errrr…..? It’s all about using types of cryptography which will not be vulnerable once Quantum Computers become powerful enough to start cracking the vulnerable types.
• And the vulnerable ones are…? Symmetric encryption algorithms, broadly speaking^[2]. The encryption used to generate and verify digital signatures, providing integrity assurance and proof of originator. The encryption used to protect the session keys for bulk encryption.
• And when will Quantum Computing be powerful enough? No one really knows, but it could be just a few years away. Maybe 10. Maybe less. Maybe more.
• So why not wait until then to act? Because that would be far too late!
  • Information requiring confidentiality protection, and protected using encryption via the vulnerable algorithms can be captured years in advance and stored by an attacker, then decrypted.
    • Personal Information and Sensitive Personal Information; Health records for example, which remain sensitive for at least the lifetime of the subject
  • Information requiring long-term integrity protection, and protected by digital signatures based upon the vulnerable algorithms, can then be altered and new valid signatures faked.
    • Software archives, transaction records
    • Blockchains – all the major blockchains are currently based upon algorithms which will be vulnerable^[1] and of course, the integrity of the blockchain is somewhat fundamental to the whole concept of cryptocurrency.
• What can we do now? Plan.
  • Draw up a plan for your organisation.
    • You need to understand the things your organisation does which QC will impact; what sorts of data you hold, how long the C & I requirements must be maintained for.
  • Review developments regularly
    • Relevant changes to the previous assessment of the above
    • The new standards published so far only cover digital signatures (x2) and key exchange. For some organisations this may be sufficient for their needs, but others are likely to need futher future standards.
• Why not implement now? Because after the standards are established, there is an inevitable lead-time for toolsets to support the new standards, for these updated tools to become available within services you may consume.
• Why not implement the standards internally? Because, not to put too fine a point upon it, unless this is a genuine specialism of yours that would be an insane thing to do. Creating robust, correct, and secure implementations of cryptographic standards is really tough even for experts in the field.

Why plan now if we cannot implement yet?

This is the crux of the matter. And the answer isn’t necessarily obvious. However, consider data that you hold now for which the C&I requirement may last beyond a few years. Personal Data (and especially Sensitive Personal Data) needs protecting for at least the lifetime of the subject. What’s that? You delete the data, so you don’t need to worry about this? Wrong!

Why does it matter if I delete the data after use?

There are two issue here. Firstly, what if someone has acquired a copy of the encrypted data. Maybe they have captured it in transit across the network, or defeated other controls and taken snapshots of your encrypted volumes. The encryption here is relied upon to mitigate the risks around such captures; the attacker cannot read the data, so what use is it to them, and what risks does it present? Currently the assumption may be that there is no residual risk. But a patient and well-resourced attacker may retain such captures for long enough for the encryption to be at risk from QC. Remember, it’s not the bulk encryption that tends to be at risk (symmetric encryption, carried out using a random session key), but the asymmetric encryption used to protect the session key. Recovery of that session key, even years later, could prove to be embarrassing.

Secondly, if you are relying upon “crypto shredding“ to provide assurance of data destruction, you may have a problem. The idea here is that by deleting the key necessary to decrypt the session key for the data, the data is no longer accessible. However, if the session key wrapped using asymmetric encryption can be captured, even after the asymmetric key’s private component has been deleted, then it remains vulnerable to QC recovery of the session key at some time in the future.

The practical upshot of this is that data you are storing now and in the period between now and when QC becomes powerful enough may be decrypted at some point in the future, and that there is nothing you can do to prevent this once the encrypted data is held by your attacker.

What you CAN do, however, is demonstrate in the future that you took all reasonable steps to protect the data long-term, going back to now. One of the ways to help demonstrate this is showing that you carried out planning activities early on – because those plans will document the barriers (standards, tools support etc) to adoption of PQC within your specific organisation/systems.

Thus planning now can not only put you in the best position to adopt PQC early, but also to demonstrate (in the event of QC-based breaches) that you took reasonable steps to plan for and to provide the best defence of the stored data as early as it became possible.

Writing a plan, as outlined here, should not be a hugely onerous task. The most difficult part may be identifying what data you store, and the duration for which the C&I protections are required. But really, these should be known already, so effort here is not wasted. And you can always briefly bring in an expert for the odd day or so to compile an initial plan for you.

Footnotes, References, and AI Transparency Statement

[1] There will be some fascinating edge cases here (La spécialité de la maison Baskerville). Blockchains which have the necessary developer community size will necessarily migrate to PQC (the rest will die), and the users will have to migrate their old wallet contents to new PQC-safe wallets. But what happens to users who don’t migrate before the old wallets become vulnerable to Quantum Computing attacks? The first person to break an unconverted wallet can then perform the transfer of the old wallet content to a new wallet, all recorded blockchain. So what about Satoshi’s one million bitcoins, today valued at about £45 billion? That could be quite an interesting race to say the least, with quite a payout for the winner. This is the first problem I’d want to prove my candidate powerful Quantum Computer against; this might be a really interesting analogue to a Warrant Canary; if Satoshi’s coins have not moved, then either no one has enough QC power to break the key, or someone has unbelievable self-restraint. Ker-ching 🤑

[2] Whilst the impact upon symmetric algorithms is not as catastrophic (quadratic rather than exponential speedup of bruteforce attack), it is not trivial. The worst case appears to halve the effective key length, which is still a huge reduction in strength and will thus require future symmetric algorithms to have longer keys in the first place.