Open geedo0 opened 1 month ago
Hmm -- generating certs looks like operating keygen and sigs for XMSS would be necessary, i.e., activating OQS_HAZARDOUS_EXPERIMENTAL_ENABLE_SIG_STFL_KEY_SIG_GEN and somewhat disregarding this concern. Do we really want this? How does upstream openssh
handle this concern (and the XMSS state safely)?
I don't feel strongly in favor of implementing this (on the contrary actually). I cut this issue to track the idea since Spencer brought it up during the standup. I'll see if I can answer how upstream OpenSSH deals with state as I'm also intrigued by it.
There's a lot of overhead and custom logic (as expected) around managing state. They basically include the signature count into the serialized form of the SSH keys. This is then hydrated into the internal structs to select the correct signing key, enforce the signature limit, and whatever other logic is needed. I'm not sure what safeguards are in place to protect the integrity of that serialized state though. AFAICT it's all still considered "experimental" by the project is is not compiled by default.
That said, it would be complicated to get a liboqs version of this. Assuming liboqs delegates dealing with the state outside the library, we'd have to replace all the XMSS algorithm code with calls to liboqs. This won't align with the existing templating for stateless signatures so that's also all net-new to handle the specific XMSS insertion points.
Code pointers:
Upstream OpenSSH has support for XMSS-based SSH Keys and Certificates ref. Equivalent and interoperable support can be implemented in the OQS fork and liboqs's XMSS implementation. It would be good to implement this if issue #24 were to be picked up.
Implementation-wise this means adding an implementation of the
sshkey
interface for liboqs's sig_stfl API tossh-oqs
and adding a generator entry for XMSS.