Re: [MLS] MLS Compatibility with PQC

[Alexander Sherkin <[e-mail]>]

Nice. I think the KEM-based approach will make it much simpler for PQC cipher suite integration. Another part is allowing for PQC signatures such as SPHINCS. Arguably, PQC authenticity may not be such an urgent problem because an attacker needs a quantum computer now to be able to attack message authenticity. In contrast, messages intercepted and recorded now may be decrypted by a quantum compute in the future; hence, the urgent need for PQC for confidentiality.

Kyber public key length is about 1.5Kb, and private key length is about 3Kb. Sphincs+ public key is 64 bytes, and the private key is 128 bytes.

Two octet length is probably fine for Lattice-based schemes. However, Code-based crypto schemes may have public keys on the order of 1 Mb. Code-based crypto may be considered as one of the most conservative choices so supporting Code-based crypto would be nice if possible.

Thanks.
Alex.




Alexander Sherkin
        Software Architect



[cid:image2c07ae.PNG@ef92dce9.428574ae]<http://www.darkmatter.ae>

2 Robert Speck Parkway, Suite 1610
Mississauga ON  L4Z 1H8
Canada
MT+1 416 414 7117<tel:+1%20416%20414%207117>
[e-mail]<mailto:[e-mail]>

darkmatter.ae<http://darkmatter.ae>

[Linkedin]<https://www.linkedin.com/company/dark-matter-llc> [Twitter] <https://twitter.com/GuardedbyGenius>

The information in this email is intended only for the person(s) or entity to whom it is addressed and may contain confidential or privileged information. If you receive this email by error, please notify us immediately, delete the original message and do not disclose the contents to any other person, use or store or copy the information in any medium and for whatever purpose. Any unauthorized use is strictly prohibited.

From: MLS [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: February 22, 2019 6:16 PM
To: Alexander Sherkin <[e-mail]>
Cc: [e-mail]
Subject: Re: [MLS] MLS Compatibility with PQC

Hi Alex,

Karthik and I have been working on a hybrid PKE primitive in CFRG, with the idea that it could be re-used in MLS:

https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00

In the CFRG discussion of that draft, several folks suggested that we adapt it to accommodate a general KEM.  I have a draft-01 of that in the works that does that.  So there is something of a plan here!

Another thing that some folks have observed is that the length fields for public keys are two octets long.  Would the keys for the schemes you're interested in overflow those fields?

Thanks,
--Richard



On Fri, Feb 22, 2019 at 3:16 PM Alexander Sherkin <[e-mail]<mailto:[e-mail]>> wrote:
Hello,

The current protocol draft specifically relies on Diffie-Hellman crypto primitive. This makes perfect sense when classic crypto is used, but may be a limitation when post-quantum crypto (PQC) is required.

If we assume that powerful enough quantum computers will become a reality in the next 10-15 years, any data protected with classic crypto we exchange today will be decryptable by a third party in 10-15 years. Hence, using classic crypto for new systems may not be a good idea.

At the same time, it seems that the protocol is well positioned to rely on KEM crypto primitive. Relying on KEM instead of DH allows for a wider range of options including PQC primitives such as New Hope and Crystals Kyber making the protocol PQC-ready at least from the confidentiality perspective.

To make it more general, KEM primitive may be defined as (C, s) = KEM-Encapsulate(PublicKey) and s = KEM-Decapsulate(PrivateKey, C).

Thoughts?

Thank you.
Alex.



Alexander Sherkin | Software Architect
Tel:  | Mob: [phone]
[e-mail]<mailto:[e-mail]>

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.








_______________________________________________
MLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mls