openssl
openssl copied to clipboard
openssl
Add design document for LMS.
Checklist
- [x] documentation is added or updated
- [ ] tests are added or updated
Put a hold on this to discuss within the OTC.. In particular the new API and what is supported/not supported need to be discussed.
May I ask for a requirement that if any signing operation is implemented that it can be disabled at built time, leaving only verification operations available?
LMS is something that should never been implemented in a generic software system, NIST and NSA as well recommend that LMS and XMSS signatures are implemented only in Hardware, and the reason is that duplicating state is catastrophic, and in software duplicating state is as simple as restarting a machine after a crash where updates didn't get to disk, or copying around files.
We do not want to give our users a knife that has cyanide laced razor blades for a handle.
May I ask for a requirement that if any signing operation is implemented that it can be disabled at built time, leaving only verification operations available?
LMS is something that should never been implemented in a generic software system, NIST and NSA as well recommend that LMS and XMSS signatures are implemented only in Hardware, and the reason is that duplicating state is catastrophic, and in software duplicating state is as simple as restarting a machine after a crash where updates didn't get to disk, or copying around files.
We do not want to give our users a knife that has cyanide laced razor blades for a handle.
There is no intention of implementing the sign or private key generation
I would go even further that what Simo said.
I consider not only presence of signature creation a problem, but signature verification too.
Safe use of any stateful hash based signature formats absolutely and unequivocally depends on the signature operation being performed in hardware. Doing it in a way that allows for disaster recovery, over 10, or 20+ years of use, is orders of magnitude harder still. That means that there will be very few originators of such signatures. Which means they will be used in very few places.
In case we have widely deployed implementations that can verify such signatures, there definitely will be people that don't know better and actually implement and use signature creation in software. So, just presence of signature verification is an incentive to do the wrong thing.
As such, I don't think openssl should ship with any code that can do LMS verification. It can have support for providers that support it (to support the hardware modules), but I think including verification code is a mistake. If there are specific users asking for it, it should be a separate provider module, not part of OpenSSL proper. Users should not be able to expect that LMS is supported out of the box.
See also: Nuclear Non-proliferation Treaty
I would go even further that what Simo said.
I consider not only presence of signature creation a problem, but signature verification too.
Safe use of any stateful hash based signature formats absolutely and unequivocally depends on the signature operation being performed in hardware. Doing it in a way that allows for disaster recovery, over 10, or 20+ years of use, is orders of magnitude harder still. That means that there will be very few originators of such signatures. Which means they will be used in very few places.
In case we have widely deployed implementations that can verify such signatures, there definitely will be people that don't know better and actually implement and use signature creation in software. So, just presence of signature verification is an incentive to do the wrong thing.
There is no state associated with the signature verification, so I dont agree. There are many things in crypto that you can do wrong if you dont know what you are doing. @t-j-h Would you care to respond to why we should do HSS signature and key generation in OpenSSL.
My point is that there is a difference between "it's hard to do it correctly" and "there's literally at most double digit number of corporations in the world that will be able to do a production deployment correctly".
While I agree that with hubert that only a handful of entities will be able to correctly deploy keygen and signatures, I don't agree verification will necessarily be wrong. Those handful of entities will be creating signatures that millions of users may need to verify. The use cases for these signature algorithms are basically sign an object once and many people verify that signature over the course of the next couple of decades.
Anyone with enough skill to replace the signature/keygen portion will also have enough skill to know the dangers of not doing this with hardware tokens. The guidance is pretty widespread.
And if we expect that only a handful of entities will be creating such signatures, why would we want to have code for verifying them when processing any and all signatures?
Reasonably there are two usages for stateful signatures: root CAs and signing software/firmware. In both cases you know a priori if you'll need support for a stateful hash signature. So if that need arises, the code can load the necessary provider ahead of time.
There's another reason for not including it in OpenSSL proper: stateful signatures are very much a transitionary, niche technology. Long term we will end up using stateless hash signatures, lattice based, or something else still. By including it in OpenSSL, the project commits to supporting them for a long time.
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 92 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 123 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 154 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 91 days ago
This PR is in a state where it requires action by @openssl/otc but the last update was 122 days ago
Considering the recent additions to the EVP_PKEY_ sign and verify functionality, maybe this needs an update? Is the new interface ready enough so this can simply be a matter of writing provider code?
