Conversation
Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
| "variant": [ | ||
| { | ||
| "pattern": "RSA-PSS[-{digestAlgorithm}][-{saltLength}][-{keyLength}]", | ||
| "pattern": "RSA-PSS[-{hashAlgorithm}][-{maskGenAlgorithm}][-{saltLength}][-{keyLength}]", |
There was a problem hiding this comment.
Nice addition — adding {maskGenAlgorithm} closes the semantic gap in the RSA-PSS pattern.
One question: since maskGenAlgorithm in RFC 8017 is an AlgorithmIdentifier (typically id-mgf1 with a HashAlgorithm parameter), should {maskGenAlgorithm} here represent just the MGF function (e.g., MGF1), or the full concrete instantiation (e.g., MGF1-SHA256)?
Clarifying this would help avoid ambiguity for tooling that derives canonical names from these patterns.
There was a problem hiding this comment.
Ideally both (mgf with hash), if available.
| { | ||
| "pattern": "[(gost-|sm3-)]yescrypt[-{N_log2}][-{r}][-{p}][-{t}]", | ||
| "primitive": "hash" | ||
| } |
There was a problem hiding this comment.
Two clarification questions to make sure we’re modeling this consistently in the registry (especially for downstream tooling / policy):
1. For this family, should primitive be hash or kdf? The scheme is commonly described both as a password hashing scheme and as a scalable KDF — I’m trying to align with the registry’s intended classification rule.
2. For the optional (gost-|sm3-) prefix: is the intent that it selects the internal hash algorithm? If so, would it be preferable to model that as a {hashAlgorithm} placeholder (similar to other variants), rather than encoding specific algorithm names in the pattern?
There was a problem hiding this comment.
Agreed with both. For 1, this would also apply to the other password-based kdfs (scrypt, bcrypt)
2 participants
Adds yescrypt
Closes #757
Consistent use of hashAlgorithm in patterns
Closes #800
Adds maskGenAlgorithm to RSA-PSS pattern
Closes #801
Adds URL for CMEA
Closes #805
Removes duplicate KMAC -> merge with SP800-108r1 kdf
Closes #824