Hacker News Reader

Comment by ulrikrasmussen | Hacker News Reader

I'm a bit uncomfortable with the fact that the ASN.1 encoding is actually inconsistent but that the implementation happily ignores that and just uses the derived values. Since these values are entirely redundant, it feels like a bad design to include them in the key file. I guess the point of them is to make operations faster, and therefore they have to be cached to make any sense.

View on HN

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

> 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