6 ms·
Private key redaction: Ur doin it rong (2020)
- EAtmULFO 3y agoThat's a pretty brutal bit of public shaming. Would it not have been better for the security community at large to instead reach out to Sven and have him address the issue privately?
- gomoboo 3y agoI agree. I'd expect something like this after reaching out to both Sven and Hilton Hotels with no cooperation from either of them.
- graypegg 3y agoDefinitely. This was obviously a big mistake on Sven’s part but someone just announcing it to the world, presumably making the chance of this being used for something nefarious more likely, and attaching Sven’s full name to it with a link-back so it’ll be caught in search engine results forever… not a great move from the author.
- dang 3y agoThanks. How about we change the URL to the more general article, which has more information and doesn't shame anybody. I've changed it from https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key-redaction-redux.html https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key... now.
- lynx23 3y agoI thought the same when I read this article on Planet Debian. Pretty weird for an organisation that has spent the last 5 to 8 years alienating contributors with CoCs and outreachy projects. Looks like as if the fight isn't over yet.
- josephcsible 3y agoLet's Encrypt has an automated way for anyone who comes into possession of a private key to get the corresponding certificate revoked: https://letsencrypt.org/docs/revoking/#using-the-certificate-private-key https://letsencrypt.org/docs/revoking/#using-the-certificate... I wish this were a standardized thing every CA had to have, to avoid things like this: > As of the time of writing, that certificate is not marked as revoked
- michaelt 3y ago> In short: don’t ever try and redact real private keys. For documentation purposes, just put “KEY GOES HERE” in the appropriate spot, or something like that. Personally I've always liked redacted keys because it makes it clear to users what they should expect. Does this system want a PEM or a DER or a CER or a CRT or a JKS or a P7B or a P11? Or some vendor-specific format? The public key or the private key? Or both in the same file? A literal value, or a filename of a certificate on disk? A keyring? It'd all be a heck of a lot easier if we didn't have such a mess of key formats.
- AnonCoward42 3y agoInstead you could vary it by using i.e. "PEM KEY GOES HERE". Tho I must admit there is no real harm in producing a new private key that is not used - at least not directly; it might lead to copy/paste usage, which is obvious user error, but depends on the audience.
- gvx 3y agoIMO, if you're writing documentation, you should be aware that any sample text or code will be copy/pasted by someone and will end up in production there.
- lifthrasiir 3y agoPEM headers can be safely kept, otherwise base64-encoded payload has no discernible pattern at all and thus should be removed entirely even in your reasoning.
- crote 3y agoSomeone should make a set of documentation keys which are invalid, but still look valid. That way they could be used for documentation, but couldn't accidentally be copied into a production environment.
- gvx 3y agoThe simplest thing I can think of is by generating keys that follow the exact right structure but some invariant like n = p * q is broken. Of course that relies on the assumption that implementations do some basic sanity checks like that. I don't know if that's a fair assumption to make.
- nailer 3y ago> In short: don’t ever try and redact real private keys. For documentation purposes, just put “KEY GOES HERE” in the appropriate spot, or something like that. I would define replacing the entire body of the key as redacting a private key. I would define the behaviour of the author as advocating against as partially redacting a private key.
- jeroenhd 3y agoRedacting the private key without knowing the structure of the private key is unfortunate. Trying to fix the issue with a Git commit even more so. I hope this got fixed in the end. Why redact keys with PRIVATE KEY here when you can have more fun with it. You can put any base64 in there, put a nice image file in there (a logo if you're a boring company, a meme if you're writing a blog).
- Phemist 3y agoPet peeve: similar thing goes for QR-code redaction. People nearly always block out the middle part of the QR-code. However, actual information, the zigzag pattern, starts from the bottom-right. For many QR-code versions, the middle part encode _mostly_ ECC blocks, which are by definition redundant. The fact that a QR-code doesn't decode in the regular scanning apps does not mean you cannot read any information from it.
- tgsovlerkhgsel 3y agoAlso, redacting text by blurring doesn't work well. If it's a screenshot (i.e. an exact representation, not something like a photo), you can usually try various combinations of characters and see what creates the same blurring pattern. If you know (or correctly guess) the exact parameters of the blur, this works far beyond what most people would consider recoverable by looking at it.
- schoen 3y agoI think I've seen both CTF levels and puzzlehunt puzzles based on partially obscuring a QR code, precisely so that it "doesn't decode in the regular scanning apps", and then challenging people to read it anyway.
- luch 3y agoAn example a real life reconstruction of a partially redacted SSH private key : https://blog.cryptohack.org/twitter-secrets https://blog.cryptohack.org/twitter-secrets
- jwilk 3y agoAlso: https://7bits.nl/projects/pamenv-dsakeys/pamenv-dsakeys.html https://7bits.nl/projects/pamenv-dsakeys/pamenv-dsakeys.html
- schoen 3y agoMost examples here and in the comments seem to involve an entire RSA prime coming through unredacted, and dealing with various ASN.1 shenanigans to figure out which bits actually belong to the prime. But the situation is potentially still quite bad even if you have less information than that. See Heninger and Shacham (2008): https://eprint.iacr.org/2008/510.pdf https://eprint.iacr.org/2008/510.pdf
- zokier 3y agoIf you insist on doing partial redaction then reasonably simple approach would be to generate two keys and redact non-matching parts. But tbh it still is unnecessary risk
- wodenokoto 3y agoIf you have already generated a second key, which you are not gonna use as a key, then just use that one instead of any redaction.
- electroly 3y agoThis has the issue stated at the bottom of the article: someone will eventually copy that as their own private key, even if the author had never used it.
- firstlink 3y agoWhile I understand the sentiment, like all attempts at outsmarting stupid people, it is misplaced. If they're not copying your fake private key they're just copying someone else's.
- wodenokoto 3y agoIn that case, just retract _any_ part of the key, such that it won’t work if you copy paste it, but still no used secret is revealed. If a user wants to rebuild the key in order to use it for something, then they must have a very good reason to do so, and it is probably better to just let them do that.
- electroly 3y agoPosting a screenshot instead of actual text is likely to work in this case, too, even if it's the whole key.
- kevincox 3y agoThis probably still isn't a great idea. To simplify let's assume that the secret data is completely random. Let's also assume that "non-matching parts" is bit-by-bit. This would mean that you accidentally reveal 1/2 of your private details because the random values match. With redundancy in the keys as mentioned in the article it seems like solving for the missing data shouldn't be too hard. Of course the bit-by-bit assumption makes you reveal much more data than buye-by-byte or base64 characters but the point still stands.
- kdklol 3y agoThe author released another "follow-up" article today: https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key-redaction-redux.html https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key...
- rollulus 3y agoIf you want to show an illustrative key, why bother to redact something real if you could generate a throwaway key and have zero risk? What am I missing here? That someone could panic because it looks too real?
- remram 3y agoGenerating a new key for documentation seems incredibly easy, or even generating random base64 text. Most of all, searching Google for a random key to use as example seems easiest of all. I find it hard to believe that anyone would take their actual production key and redact it for documentation. Does the author have evidence of this in practice, or did they see example keys and assume they were redacted production keys? edit: It seems they have found one: https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key-redaction-redux.html https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key...