libtomcrypt
libtomcrypt copied to clipboard
libtom
Wishlist: Post-Quantum Cryptography
- [ ] Open Quantum https://github.com/open-quantum-safe/liboqs
- [ ] NTRU https://github.com/NTRUOpenSourceProject
- [ ] SPHINCS https://github.com/gravity-postquantum/gravity-sphincs and https://github.com/ahf/sphincs and https://github.com/sphincs
- [ ] XMSS https://github.com/libtom/libtomcrypt/issues/461#issuecomment-610423060
- [ ] LMS https://github.com/libtom/libtomcrypt/issues/461#issuecomment-610423060
Proven insecure and therefore removed from the list
- ~~SIDH https://github.com/Microsoft/PQCrypto-SIDH and https://github.com/sidh-crypto/sidh-c-reference and https://github.com/tigusoft/libsidhms~~, c.f. https://github.com/libtom/libtomcrypt/issues/461#issuecomment-1657137903
What about hash-based signatures?
- [ ] XMSS (RFC 8391 https://tools.ietf.org/html/rfc8391)
- [ ] LMS (RFC 8554 https://tools.ietf.org/html/rfc8554)
If I were to work on such a codebase, what would the preference be for integration into LTC? a) Add a new top-level directory for PQC with directories for types of crypto EX: src/pqc/hbs/xmss and src/pqc/hbs/lms b) Add these directly into existing structure without notation as to their PQC heritage EX: src/pk/xmss and src/pk/lms c) Add a new top-level directory for hash-based signatures, since they are kind of a new animal EX: src/hbs/xmss and src/hbs/lms
Or something else? Suggestions/direction being solicited. Thanks.
@dmwheel1 @sjaeckel I think the priorities are : complete cryptosystems with low footprint > complete cryptosystems with high footprints > pure signature schemes, also those who are being standardized > those made by others Please check https://en.wikipedia.org/wiki/Post-quantum_cryptography#Open_Quantum_Safe_project and https://en.wikipedia.org/wiki/Post-Quantum_Cryptography_Standardization#Round_Two
@DonaldTsang XMSS and LMS actually ARE part of the NIST PQC set, but are not experimental, so they do not fall into the Round Two set - their security is not in question, since they are based on solid cryptographic techniques going back to the mid-1970's. See https://csrc.nist.gov/Projects/stateful-hash-based-signatures/news and the draft standard here https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208-draft.pdf SPINCS+(one of the Round Two Candidates) is actually an extension of XMSS but using "many-time-signatures" instead of "one-time-signatures" and this extension needs some more scrutiny. HBS schemes have many advantages over the other PQC algorithms, including speed and root public key size; Signature size (and fully expanded public key) are an order of magnitude larger than RSA keys. All that to say, IMHO, the HBS schemes are an important (though perhaps less glamorous) addition to the PQC algorithm set.
BTW, one of my team members is working on BIKE and Classic McEliece, so a future contribution in this area would be possible.
@dmwheel1 in that case are there any documents that give info into which current cryptographic algorithms is based on what other algorithms/principles? Good to have BIKE people here tho.
@DonaldTsang I am not aware of a specific documentation that lists the relations among the PQC candidates, though I have seen some categorizations in various papers and presentations. My comment regarding SPINCS+ is based on my personal analysis reading the HBS academic papers and standards.
I think it makes sense to go with standardized solutions for now instead of spending effort on proposals. If it doesn't have an RFC or other freely available specification (i.e. IETF, NIST or some other standards body published it) it doesn't make sense to be included IMO.
Regarding the integration, I like the proposal of going with b) and putting them in src/pk/xmss resp. src/pk/lms as these are "simply" new PK algorithms IIUC.
If we'll ever go and add "draft" algorithms (which I doubt since the issue with #256) I'd propose to add new src/experimental/{cipher,pk,...} folders where they can be added.
The problem is that nothing Post-Quantum related are standardized yet, all the citations made are proposals that are so close of being standardized.
@DonaldTsang Respectfully, I believe you are mistaken regarding HBS algorithms not being standardized (or we have different views of that definition). Both XMSS and LMS are published standards out of the IETF Crypto Research Group (link above). NIST has published their DRAFT standard and the public comment period is over (link above), meaning that publication of the final standard is imminent (definition of imminent with a government involved and in these COVID-19 challenging times is up for debate ;-) ). If NIST publishes their specification, would that meet your definition of a standardized algorithm, or would you look for other criteria? @All - I'll begin work on this and in the meantime, perhaps NIST will publish their final specification.
They have an RFC -- yes I'm aware the RFC's are only informational and from the IRTF/CFRG, not IETF -- but I call this usually standardized. Or am I wrong there?
The CFRG (Crypto Forum Research Group) - the crypto group at IETF - only publishes informational RFCs. Until I started regularly attending IETF meetings, I was unaware of this fact. The CFRG actually is organized in the research side of the group (the IRTF) not the engineering side (the IETF). Anyway, from the IETF perspective, XMSS and LMS are available for use in standards, if a standards working group believes it is prudent. No further "standardization" steps are required for these algorithms to be brought into an IETF RFC (what we would more colloquially call a standard).
OpenSSH ships with a post quantum algorithm enabled by default.
OpenSSH 9.0/9.0p1 (2022-04-08)
-
ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default (
[email protected]). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.
SIDH/SIKE are proven "insecurable" & the authors have posted such @ NIST. Could the top post be updated?
