Live data from Hacker News

Private key redaction: Ur doin it rong (2020)

hezmatt.org

11–20 of 34 posts

Re: Private key redaction: Ur doin it rong (2020)

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

Re: Private key redaction: Ur doin it rong (2020)

#12
post #2

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

Re: Private key redaction: Ur doin it rong (2020)

#15
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

Re: Private key redaction: Ur doin it rong (2020)

#17
post #7

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

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.

Re: Private key redaction: Ur doin it rong (2020)

#18
post #7

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

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.

Re: Private key redaction: Ur doin it rong (2020)

#19
post #16

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.

Re: Private key redaction: Ur doin it rong (2020)

#20
post #11

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…

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.

Post reply on HN