On Mon, Sep 01, 2008 at 12:56:29PM -0700, SJS wrote:
Fob encrypts hash with private key -- that's your digital signature --
and then you hash *that* to get the short string to send to the server.
That's what you suggested, yes?
How does the server determine if that short string is the correct one
or not?
Veryifying short strings seems to be a persistently difficult problem.
RSA's solution (having the secret on both sides) also requires rather
draconian account lockout policies to prevent automated guessing of
the small space.
There are some neat algorithms for validating short passwords (such as
SRP), but as far as I know, all involve the communication of much
larger amounts of data than the short password, which requires the
short password be typed into something trusted that communicates with
the server.
There are really two problems:
- Communicating a short value allows an attacker to guess and
possible current values. RSA solves this by preventing very many
attempts.
- Does having a short password reveal the secret. For shared
secret, the short password can be a portion of a secret, where the
shorter password reveals less, rather than more of the password.
But, when we try public-key, a shorter password would means that
the numbers involved in the public key would have to be shorter as
well, meaning that it would be much easier to determine by brute
force. Brute-forcing a 20-30 bit RSA key would be a trivial
search.
There are a few algorithms that probabilistically can verify a secret
without revealing it to the attacker, but the ones I know about are
interactive, and usually involve transferring more data than we wish
to.
It is an interesting problem.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
