Re: [Cfrg] Applied Quantum Resistant Crypto

[Douglas Stebila <[e-mail]>]

Hi Kris and Panos,

As part of our Open Quantum Safe project (https://github.com/open-quantum-safe), we have made a variety of prototypes of post-quantum key exchange (hybrid or PQ-only) and post-quantum signatures in (modifications to) OpenSSL and OpenSSH. 

In particular we have:
- hybrid key exchange in TLS 1.2 via modifications to OpenSSL 1.0.2 (see the "OQS-OpenSSL_1_0_2-stable" branch in our openssl fork)
- hybrid and PQ-only key exchange in TLS 1.3 via modifications to OpenSSL 1.1.1  (see the "OQS-master" branch in our openssl fork)
- PQ-only auth in TLS 1.3 via modifications to OpenSSL 1.1.1  (see the "OQS-master" branch in our openssl fork)
- hybrid and PQ-only key exchange in SSH 2 via modifications to OpenSSH 

All of this is built on our core library "liboqs", which provides a variety of PQ KEMs and signature schemes.

There are a few different versions and we are in the middle of some refactoring, so if it is hard to find what you are looking for, feel free to email me and I can explain what's going on.  Happy to discuss further and certainly welcome any ideas or participation.

Douglas


> On Jul 18, 2018, at 5:45 AM, Kris Kwiatkowski <kris=[e-mail]> wrote:
> 
> Hi Panos,
> 
> Definitely hybrid approach, I just quickly looked at a draft, but I it's good base. Nevertheless
> I'm planning to start TLS part somewhere next week and maybe.
> 
> In fact, we would like to experiment with many different KEMs (based on different hard problems). 
> At a time SIDH looked quite promising (indeed key sizes). It is simply first one to try. It's also
> interesting to see if work done around ECC could be "reused" for some parts of QR algorithms.
> 
> Kind regards,
> Kris
> 
> 
> On 7/18/18 4:01 AM, Panos Kampanakis (pkampana) wrote:
>> Hi Kris,
>>  
>> Thank you for the update. Interested to see your results and SIKE’s performance.
>>  
>> Were you thinking to use SIKE in TLS 1.3 a similar manner to the one proposed inhttps://tools.ietf.org/html/draft-whyte-qsh-tls13-06 which uses a hybrid approach (traditional+QRC) KEM?
>>  
>> Also, SIKE has pretty small keys, but performance is much higher. From the reference benchmarks performance SIKE seemed to be 10^4 more expensive than the best candidate that does not have prohibitive KEM pk and ciphertext sizes. Any reason why you chose SIKE that you can share?
>>  
>> Rgs,
>> Panos
>>  
>>  
>> From: Cfrg [mailto:[e-mail]] On Behalf Of Kris Kwiatkowski
>> Sent: Tuesday, July 17, 2018 5:28 PM
>> To: [e-mail]
>> Subject: Re: [Cfrg] Applied Quantum Resistant Crypto
>>  
>> Hi,
>> 
>> At Cloudflare we are currently implementing SIKE/SIDH in Go (https://github.com/cloudflare/p751sidh/pulls). Next step will be to add it to TLS 1.3 (https://github.com/cloudflare/tls-tris). We may want to use it for some some other things.
>> I'm definitely interested in discussion regarding QRC in real-world crypto.
>> 
>> Kind regards,
>> Kris Kwiatkowski
>> 
>> 
>> On 7/17/18 8:35 PM, Dr. Pala wrote:
>> Hi all,
>> 
>> I was wondering if there are people interested in setting up some sort of discussion forum where to discuss the deployment (from a practical point of view) for QRC in their systems. The intent here would be to share the experiences, provide feedback, and possibly even share implementations/references/etc.
>> 
>> Moreover, being this quite a new field when it comes to real-world applications, it would be interesting to understand the new requirements so that we can plan for algorithm agility correctly and not having to go through what we suffered in the past (and in some cases with current protocols) to upgrade/switch among different schemes/algorithms.
>> 
>> For example, some of the topics might include:
>> 
>> 	• How to deploy PKI services
>> 	• Mixed environments considerations (QRC and "Traditional" Crypto)
>> 	• Mixed environments (stateful vs. stateless)
>> 	• Encryption and Key-Exchange for QRC - what are the options there (it seems auth is well understood, but other problems are still open)?
>> 	• Are there implications for the deployment of PKIs we need to be aware of and are not currently mentioned/addressed?
>> 	• Any real-world deployment out there (or plans for it)?
>> 	• Algorithm Agility, what to plan for?
>> 	• Applicability to Revocation Services
>> Most of the activities to standardize QRC in CMS/SecFirmware/etc. that I can see are related to the use of Stateful HASHSIG and I have not seen any "standardization" activities around stateless schemes (e.g., SPHINCS), but if I am wrong, please let me know (and if you could provide some interesting links, that would be great). I think it would be useful to understand how to practically deploy these new schemes and how to refine / provide the building blocks required for their implementation and deployment.
>> 
>> Here's some references:
>> 
>> Merkle Tree Signatures (Stateful):
>> 
>> 	• https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/
>> 	• https://datatracker.ietf.org/doc/draft-housley-cms-mts-hash-sig/
>> 	• https://www.ietf.org/id/draft-housley-suit-cose-hash-sig-04.txt
>> 	• https://datatracker.ietf.org/doc/rfc8391/ (XMSS)
>> 	• https://eprint.iacr.org/2018/063 (Viability of Post Quantum X.509 Certs Paper)
>> 	• Implementations:
>> 		• https://github.com/cisco/hash-sigs
>> SPHINCS Related (Stateless):
>> 
>> 	• https://sphincs.org/
>> 	• Implementations:
>> 		• https://sphincs.org/data/sphincs+-reference-implementation-20180313.tar.bz2
>> Other Relevant Links:
>> 
>> 	• https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/
>> 	• https://csrc.nist.gov/Projects/Post-Quantum-Cryptography
>> 	• http://test-pqpki.com/
>> I guess this is all for now - you can reply privately at the following addresses:
>> 
>>     [e-mail]
>>     [e-mail]
>> 
>> Thanks,
>> Max
>> 
>> -- 
>> Best Regards, 
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>> <image001.png>
>> 
>> 
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>> 
>> 
>> 
>> -- 
>> Kris Kwiatkowski
>> Cryptography Engineer
>> Cloudflare
> 
> -- 
> Kris Kwiatkowski
> Cryptography Engineer
> Cloudflare
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg