Hacker News Reader

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

View on HN

> 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.

> 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...

I 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.

This 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.

Reply on news.ycombinator.com