Hacker News Reader

Comment by zokier | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com