openssl: Shipping invalid key
I’ve noticed that the RSA key shipped in apps/rsa8192.pem is not actually a valid RSA key; openssl rsa -check -in <file> -noout displays these errors:
RSA key error: q not prime
RSA key error: n does not equal p q
RSA key error: d e not congruent to 1
RSA key error: dmq1 not congruent to d
RSA key error: iqmp not inverse of q
It’s hardly a showstopper, but I thought it might be nice to update it with a valid key. I can submit a PR if you’d like (and you trust my RNG 😀).
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 31 (26 by maintainers)
Commits related to this issue
- Fix rsa8192.pem Q: How did I do that? A: That's a long story. Precondition: I used sage 8.1 for the math, it could probably done with simple python as well but I did not try. First I extract numbe... — committed to bernd-edlinger/openssl by bernd-edlinger 4 years ago
- Fix rsa8192.pem Q: How did I do that? A: That's a long story. Precondition: I used sage 8.1 for the math, it could probably done with simple python as well but I did not try. First I extract numbe... — committed to openssl/openssl by bernd-edlinger 4 years ago
That is very true. Most of the bits in N after 3085 are flipped, so it’s not plausible that it’s a multi-corruption situation. I’m having trouble imagining a keyboard mashing that’d remove a
2an add aUa couple of characters later, though. My cats are good, but not that good…I find it faintly suspicious that the scribbled-upon bits are in the second, third, and fourth bytes of the last 128 byte chunk of the value. That’s the sort of place you’d expect might be stepped on by an errant write. Sadly the corruption is not as simple as “all bits set to 0” (or 1), the relevant bytes are (in big-endian)
0x0ddb6718in the broken key, and0x0dd9c614in the (Q-correct) key.At some point I guess we’re going to run out of ideas, but in the meantime this is a fun way to spend a Sunday night.
yeah, we are nerds 😄