4 ms·
The main reason I was thinking of is that it's very difficult to do public-key encryption correctly. The normal advice is to just use GPG (or a similarly battl
by amalcon 15y ago
The main reason I was thinking of is that it's very difficult to do public-key encryption correctly. The normal advice is to just use GPG (or a similarly battle-tested library). The way these work makes ciphertext comparison meaningless. That's a good thing for almost all applications, but not for this one. The alternative is to use code that has not been so thoroughly battle-tested.
Your application is a much more straightforward application of PKI. You don't need to compare ciphertext, so you could just use GPG. (Please consult someone more expert than me, though. I am not responsible if there's a security problem, etc, etc).
As a secondary reason, public-key encryption is "fast by design", while password hashing techniques are hopefully not. This makes brute-force attacks easier. This actually applies more strongly to SSN's (only a billion possible combinations? Simple!). This can be worked around by adding a properly secured password hash of sufficient length to the plaintext, essentially adding the additional computation of the password hash.
- tptacek 15y agoRead this survey paper, particularly the very basic RSA attacks: http://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf http://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf and ask yourself how comfortable you feel about directly using RSA in any context other than encrypting a randomly generated (semantically void) binary encrypting key under secure padding.
- amalcon 15y agoVery interesting skim; I'll have to make a few passes and digest it fully when I get the chance. Is there a particular attack you're looking at here? I assume it's one based on Coppersmith's theorem, as that section was complicated enough that I'll need a few passes to digest it. Of course, the plaintext could be voided of any semantics by using still more encryption. The simplest way would be to apply a "public" one-time pad to the plaintext. (edit: Different for each plaintext, of course; otherwise, it's not one-time) The answer to the question I'm asking myself, of course, is "Not at all." I would use a dual-stacked hash/vault system built on high-level libraries if I were implementing something with these requirements. This involves the least new code, limiting both the time and number of mistakes involved. I treat that as a different question than the purely-theoretical question of whether such a system could be secure.