ssh-key: add ML-DSA keys (draft-sfluhrer-ssh-mldsa)#565
Conversation
|
That's still a draft in https://www.ietf.org/archive/id/draft-sfluhrer-ssh-mldsa-02.html right? |
|
@baloo Yes. OpenSSH implements experimental support for The current IETF discussion seems to lean towards implementing the pure PQ-sigs first, then later adopting / standardizing a hybrid construction. https://mailarchive.ietf.org/arch/msg/ssh/ys0vs2HtcPNSsJVLyGzN2vnXmQE/. There is an experimental set of patches for openssh and libssh too: https://mailarchive.ietf.org/arch/msg/ssh/rOlwUqiVbUueYh_BVkOzG5pLv4U/ / https://github.com/beldmit/openssh-ietf126-hackathon . From my perspective, I'd like to test and verify that the implementation interoperates correctly with the above implementations. Then, I'm happy to upstream, given that it's behind a compile time flag / opt-in. From RustCrypto's side, would you prefer this only to be upstreamed once the standard is finalized, or is it fine to upstream as long as we are reasonable certain that |
|
Speaking personally, I'm fine with merging a draft. I appreciate the draft to be behind a feature-flag (to track what comes from the draft mostly). We might want to comment about the draft in the Cargo.toml feature flag. |
quexten
changed the title
| const CERT_SK_SSH_ED25519: &str = "sk-ssh-ed25519-cert-v01@openssh.com"; | ||
|
|
||
| /// OpenSSH certificate for ML-DSA-44 public key | ||
| const CERT_MLDSA_44: &str = "ssh-mldsa-44-cert-v01@openssh.com"; |
There was a problem hiding this comment.
Please note, these were not actually specified in any draft, but the match later expected all algorithms to have a cert identifier, so I extrapolated what this would likely be called.
quexten
force-pushed
the
ml-dsa
branch
2 times, most recently
from
41588a9 to
da9aa44
Compare
quexten
changed the title
quexten
changed the title
|
|
||
| /// Raw FIPS 204 public key bytes. | ||
| /// <https://sfluhrer.github.io/ssh-mldsa/draft-sfluhrer-ssh-mldsa.html#name-public-key-format> | ||
| key: Vec<u8>, |
There was a problem hiding this comment.
We should use something similar to EcdsaPublicKey and have an enum that wraps mldsa::EncodedVerifyingKey. That would push the serialization / sizing errors over the serializer instead of having them in the verifier logic.
| @@ -9,6 +9,8 @@ mod ecdsa; | |||
| mod ed25519; | |||
| mod key_data; | |||
| #[cfg(feature = "alloc")] | |||
There was a problem hiding this comment.
only gate on feature "mldsa", the alloc logic should be handled by ml-dsa (it uses MaybeBox internally (there might be a "bug"/oversight on the EncodedVerifyingKey, but this is on the ml-dsa side))
2 participants
Implements support for ML-DSA keys and cert keys, as specified in https://www.ietf.org/archive/id/draft-sfluhrer-ssh-mldsa-02.html.
Please note, support for adopting the draft seems good, but it is still a draft. This is added to the Cargo.toml as a comment on the feature.