I think it's funny that removing what looks like actual key material doesn't break a key, but having the wrong kind of newline, or trailing newline in a .pem file can cause certain programs (webservers etc) to not be able to load a cert or key.
I think this is an example of how, unless you're specifically designing a file format to be redundant for error detection/correction or similar reasons, having "this field must always be related to that field in this manner" types of constraints introduces redundancy, and with it, the associated ambiguities of inconsistency (and opportunities for code handling the format to behave erroneously.)
What I find interesting about RSA is how it became so popular and important in our daily life, yet it uses basic math from hundred or thousands of years back.<p>It uses the Fermat's little theorem of prime numbers, which was defined in 1640 then proved by Euler almost 100 years after that.<p>Plus uses the Chinese reminder theorem that was discovered in the 300 CE<p>What is more crazy is that RSA (or something comparable to that) was discovered in parallel also by another mathematician working for a government agency 4 years prior to the RSA algo
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.
I'm a newbie regarding computers and mathematics, but would it be possible to construct an ASN.1 privkey structure that would be interpreted by different libraries as different privkeys?<p>Could this be abused in any way?<p>What implementations use the legacy approach of using $d$?<p>Do TLS keys/x509 express the same phenomenon?
I actually use this as a form of a canary when ssh keys must be reside in multiple systems -- in the case where a key is found outside of is proper place it identifies the source during investigations.
This is pretty interesting. I wonder how much of the key you can gore out without affecting its functionality. Enough to pass compact messages to a modified service?
Off topic: audit tool for OpenSSH config files.<p>Posted here because SSH algorithms are a moving target.<p><a href="https://github.com/jtesta/ssh-audit/tree/e50ac5c84d46e902e026babd22b5f3b4465fa93c">https://github.com/jtesta/ssh-audit/tree/e50ac5c84d46e902e02...</a>