10 ms·
Why does my SSH private key still work after changing some bytes? (2016)
- wstuartcl 4y agoI 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.
- kazinator 4y agoNutshell: lack of an integrity check (such as CRC32) over an object that contains fluff fields that don't affect the crypto.
- ksaj 4y agoThis 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?
- lucakiebel 4y agoWell, the answer says > With this optimization, the values of n, e and d are not required
- dataflow 4y agoThe thing is, that depends on if the client wants to use the other bits instead. The key is broken if the parts are out of sync, even if some clients ignore some parts.
- drewtato 4y agoIt's a private key so sharing it kinda defeats the purpose. This also only works because the modified part isn't being used.
- bawolff 4y agoI mean,if you want compact just use ECC key instead of rsa. It will be much shorter (and arguably more secure)
- ausudhz 4y agoWhat 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
- eric__cartman 4y agoI really enjoyed a piece of coursework that I was given on a discrete mathematics course that consisted of implementing RSA using the math theory taught in class. It's a very clever algorithm.
- oraetlabora 4y ago> yet it uses basic math from hundred or thousands of years back as if that was an argument. We use the wheel for a gazillion o "important and f daily life" applications.
- ausudhz 4y agoGreat, you totally missed the point. While the wheel has been used from the next day of its invention till today, the Fermat's little theorem had no application outside of pure math for roughly 400 years.
- trompetenaccoun 4y agoTo be fair there was no obvious point, so how could it be missed? You simply wrote it's interesting without explaining what you find interesting about it.
- ausudhz 4y ago[flagged]
- userbinator 4y agoI 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.)
- locusofself 4y agoI 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.
- ausudhz 4y agoThat's the difference between format and content. Web servers make sure the format is correct, they won't inspect the content
- Dylan16807 4y agoI'm pretty sure they mean a web server configured to use the content for TLS.
- marcosdumay 4y agoIsn't the whitespace in pem files just recommended? AFAIK, it's there just for interoperability with old transport protocols and not a part of the data at all.
- IshKebab 4y agoA good example of the robustness of binary formats compared to text formats.
- metafunctor 4y agoThis has nothing to do with binary versus text.
- myself248 4y agoI think it does, insofaras OSs feel free to just fuck with the contents of files they think are text, replacing newlines willy-nilly. Files not identified as text are safe from such automatic tampering.
- ulrikrasmussen 4y agoI'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.
- ausudhz 4y agoIf 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
- Dylan16807 4y ago> 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.
- ausudhz 4y ago> 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-ssh-private-key-still-work-after-changing-some-bytes-in-the-file https://crypto.stackexchange.com/questions/31807/why-does-my...
- deleted 4y ago[deleted]
- 4y ago
- g0xA52A2A 4y agoWhat a beautifully formatted reply.
- logicallee 4y ago(comment withdrawn)
- bawolff 4y agoWhy? it got the correct answer (guess #3 was arguably correct, albeit phrased a bit misleadingly)
- deleted 4y ago[deleted]
- perlgeek 4y agoFinally I understand why private RSA keys are so freaking long; storing redundant information explains it.
- jesprenj 4y agoI'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?
- ondhbcjg 4y agoIt shouldn't be possible to manipulate the ASN.1. The answer to your first question should be no, to the second yes. See this brand-new paper which briefly discusses the desired property of "non-malleability": https://www.fstar-lang.org/papers/asn1star.pdf https://www.fstar-lang.org/papers/asn1star.pdf "DER are designed to ensure that every value of a given ASN.1 type has a distinct, canonical wire format representation. That is, DER formats are intended to be unambiguous and non-malleable, in the sense that given a bit string b that encodes a value v, every parser will yield back o, whereas changing any bit in b either produces an invalid representation or yields a distinct value o' + v. These properties are particularly important in security applications, inasmuch as they depend on values u but apply cryptographic protection only on binary formats b."
- layer8 4y agoThis is incorrect. The properties of DER you cite do not prevent changing parts of an RSAPrivateKey structure (i.e. replacing o by an arbitrary o' is perfectly possible). The properties only prevent two different DER structures from representing the same value. It is possible to have an RSAPrivateKey structure where the privateExponent field is inconsistent with the exponent1/exponent2 fields, effectively representing two different private keys, and where one library uses the one and another uses the other. However, that just means that only one of the two would work with the given public key. That can be exploited only insofar as it will break interoperability depending on which library is used. In addition, an attacker would need access to the private key in order to create the inconsistent values, or would need to install a key creation software producing such inconsistent values, in which case the attacker probably can already do much worse.
- vasqw 4y agoIt's important for the title to say (2016) because things have changed A LOT.
- muhehe 4y agoCare to elaborate?
- mkj 4y agoOpenSSH private keys are now their own format, not ASN.1 encoded. There is still two 4 byte "checkint" values that can vary (but must match), but less redundant overall. https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.key?annotate=HEAD https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.key?anno...
- egberts1 4y agoOff topic: audit tool for OpenSSH config files. Posted here because SSH algorithms are a moving target. https://github.com/jtesta/ssh-audit/tree/e50ac5c84d46e902e026babd22b5f3b4465fa93c https://github.com/jtesta/ssh-audit/tree/e50ac5c84d46e902e02...
- deleted 4y ago[deleted]