by locusofself on 12/31/22, 7:12 AM
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.
by userbinator on 12/31/22, 7:11 AM
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.)
by ausudhz on 12/31/22, 7:13 AM
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.
It uses the Fermat's little theorem of prime numbers, which was defined in 1640 then proved by Euler almost 100 years after that.
Plus uses the Chinese reminder theorem that was discovered in the 300 CE
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
by ulrikrasmussen on 12/31/22, 7:30 AM
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.
by jesprenj on 12/31/22, 10:30 AM
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?
Could this be abused in any way?
What implementations use the legacy approach of using $d$?
Do TLS keys/x509 express the same phenomenon?
by g0xA52A2A on 12/31/22, 7:56 AM
What a beautifully formatted reply.
by kazinator on 12/31/22, 8:00 AM
Nutshell: lack of an integrity check (such as CRC32) over an object that contains fluff fields that don't affect the crypto.
by perlgeek on 12/31/22, 8:50 AM
Finally I understand why private RSA keys are so freaking long; storing redundant information explains it.
by wstuartcl on 1/1/23, 5:41 PM
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.
by ksaj on 12/31/22, 6:52 AM
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?
by vasqw on 12/31/22, 11:47 AM
It's important for the title to say (2016) because things have changed A LOT.
by egberts1 on 12/31/22, 4:28 PM
by logicallee on 12/31/22, 8:01 AM
(comment withdrawn)