A roadmap to migrating the internet to quantum-safe cryptography

Transcription

1 A roadmap to migrating the internet to quantum-safe cryptography William Whyte, Security Innovation

2 Conditions for successful deployment Post-quantum crypto must be: Agreed Standardized in core standards Standardized in protocol standards Accepted in certified cryptographic modules Available in certs issued by CAs Deployed in software Usable under licensing terms the industry finds acceptable

3 Agreement! We need to agree what quantum-safe cryptography is The academic track All cryptography that is believed quantum-safe is vulnerable to criticism that is hasn t received enough scrutiny (Hat tip to hash tree signatures) It may be vulnerable to classical attacks as well as quantum attacks Or to fear of classical attacks, see The Factoring Dead presentation Or to fear of NSA backdoors, see widespread fear of NSA backdoors We should look at combining public key algorithms 3 public-key encryption algorithms each transmit 32 bytes of key material, hash or XOR them together Countersign documents 3 times This gives greater security against unexpected attacks Allows greater confidence to start migration now as opposed to panicking and picking a single algorithm Potentially allows quantum-safe algorithms to be combined with ECC/RSA to meet existing FIPS certification requirements Cost: greater packet size & processing time but in a lot of settings these are both very cheap nowadays

4 Core crypto standards Official standards development organizations (SDOs): ASC X9, IEEE 1363, ISO/IEC JTC 1/SC 27/WG 2, ETSI SAGE Pet standards organizations SEC, PKCS, CEES, See my poster session, A non-scary guide to standards for people who only know about cryptography NB guide not guaranteed not to be scary, no money will be returned

5 Protocol standards IETF: TLS, IPSec, S/MIME, OpenPGP, TLS is the big dog

6 Procurement and certification FIPS, NIST Special Publications, Common Criteria FIPS 140-X, cryptographic module validation: Modules must support specific ( FIPS-approved ) algorithms Only FIPS approved mechanisms may be used for key establishment On the face of it, rules out double-encryption No specified process by which an algorithm becomes FIPSapproved When secure double-encryption frameworks are standardized, NIST should consider allowing doubleencryption where one algorithm is already a FIPS-approved algorithm but the other need not be

7 Certs Need CAs to issue certs: Signed with post-quantum crypto algorithms Containing keys for post-quantum crypto algorithms CAs are slow to add support for additional algorithms Symantec apparently only added support for ECC and DSA in February CA root certs are hard to roll over and some of the most long-lived trusted data elements in the Internet Ideally, want to lock in new signature algorithms for root certs first but this is the area where new algorithms are hardest to introduce Building new CA technology will take many years and market will be slow to reward early adopters

8 Deployment Once standards are written, software needs to be deployed How to encourage deployment before a crisis hits?

9 Licensing and patents post-quantum crypto algorithms must be available under reasonable licensing conditions Hard to compete with free though free and broken is easier to compete with Different standards bodies have different approaches to patented technologies IETF strongly opposed IEEE / ISO / ETSI accept patented technologies if accompanied by FRAND statement Free or Reasonable And Non-Discriminatory license policy Licensing issues are perceived as slowing down the adoption of many new crypto technologies DIgiCash, ECC, Whatever standards bodies think, companies need to make commercial decision Hard before RoI is demonstrated Also, both endpoints need to talk the same algorithm If algorithms are not widely licensed, no guarantee that your client can talk to your server

10 Announcement NTRU Patents and reference code to be available under GPL Work in progress Includes new signature algorithm, PASSSign Provably secure against transcript attacks via rejection sampling See my otherposter in the poster session Go use it! Also, we re hiring:

11 Encrypt / Decrypt Performance Comparison Security Level (Classical!) NTRU Key Size ECC Key Size RSA Key Size NTRU Ops/ Sec ECC Ops/ Sec RSA Ops/ Sec Comparisons in C on a 2 GHz Platform 2. RSA ops are private-key; public-key are considerably faster 3. NTRU parameters are the cost-optimized ones from ASC X9.98; can also be optimized for speed or size. 4. RSA and ECC figures are from highly optimized toolkits: NTRU figures are from reference toolkit and can be significantly improved with optimization 11