4 ms·
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 unnece
by zokier 3y ago
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
- 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.