Private key redaction: Ur doin it rong (2020) | Hacker News Reader

Private key redaction: Ur doin it rong (2020)

hezmatt.org

83 pointswomble33 comments

> 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.

Instead 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.

IMO, 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.

PEM 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.

Someone 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.

The 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.

Or, just set the expiration date to 1970-01-01.

Let'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...

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

Most 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

Pet 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.

Also, 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.

I 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.

Redacting 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).

> 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.

An example a real life reconstruction of a partially redacted SSH private key : https://blog.cryptohack.org/twitter-secrets

Also: https://7bits.nl/projects/pamenv-dsakeys/pamenv-dsakeys.html

The author released another "follow-up" article today: https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key...

If 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?

Generating 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...

If 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

This 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.

If 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.

This 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.

While 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.

In 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.

Posting a screenshot instead of actual text is likely to work in this case, too, even if it's the whole key.

That'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?

I agree. I'd expect something like this after reaching out to both Sven and Hilton Hotels with no cooperation from either of them.

Definitely. 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.

Thanks. 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... now.

The original article is also shaming someone, although from 3 years ago maybe it's less an issue now (?)

Ah - I didn't realize. I hope you're right about the latter.

I 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.

Reply on news.ycombinator.com