4 ms·
If you read the response you'd realize that it depends on how the key is generated. Is not a "bad design", is a feature that allows to include or exclude deriv
by ausudhz 4y ago
If you read the response you'd realize that it depends on how the key is generated.
Is not a "bad design", is a feature that allows to include or exclude derived values, if you do so then the original values are used and the encoded private key would be smaller.
The reason why they'd keep the original values when the derived are available might have to do with backwards compatibility and/or legacy constraint
- Dylan16807 4y ago> If you read the response you'd realize that it depends on how the key is generated. Where does it say or imply that? When I read the answer it sounds like using them is optional but generating them is mandatory.
- ausudhz 4y ago> With this optimization, the values of n, e and d are not required, hence are ignored by typical implementations whenever p, q, dp, dq and qinv are available* > *at least for OpenSSH, they do not have to be present: setting p=q=1 and dp=dq=qinv=0 makes the implementation use n and d. https://crypto.stackexchange.com/questions/31807/why-does-my-ssh-private-key-still-work-after-changing-some-bytes-in-the-file https://crypto.stackexchange.com/questions/31807/why-does-my...
- deleted 4y ago[deleted]
- Dylan16807 4y agoI misread the second quote. I suppose that is evidence, but setting them to an incorrect value suggests that this might not be a valid file even if it works.
- layer8 4y agoThis is a particularity of OpenSSH though and not supported by RFC 8017. The fields are mandatory and required by the spec to contained the correct values.