The author released another "follow-up" article today: https://www.hezmatt.org/~mpalmer/blog/2023/06/12/private-key...
Private key redaction: Ur doin it rong (2020)
21–30 of 34 posts
Re: Private key redaction: Ur doin it rong (2020)
#22> 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…
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.
Re: Private key redaction: Ur doin it rong (2020)
#23If 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
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.
Re: Private key redaction: Ur doin it rong (2020)
#24If 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?
Re: Private key redaction: Ur doin it rong (2020)
#25> 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…
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.
Re: Private key redaction: Ur doin it rong (2020)
#26> 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.
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.
Re: Private key redaction: Ur doin it rong (2020)
#27If 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...
Re: Private key redaction: Ur doin it rong (2020)
#28If 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
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.
Re: Private key redaction: Ur doin it rong (2020)
#29Earlier quoted context omitted.
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.
Re: Private key redaction: Ur doin it rong (2020)
#30Earlier quoted context omitted.
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.