From: Justin Mason (jm at domain netnoteinc.com)
Date: Mon 18 Jun 2001 - 17:03:05 IST
Fergal Daly said:
> It is more important for the 1-way. Assuming people only use about 64
> different characters for passwords that's 48 bits whereas a 10 digit PIN is
> about 32 bits so whatever 1-way algo I pick would ideally be at least 65536
> times more expensive to compute than UNIX crypt... Any idea of the relative
> speeds of these algos?
Hmm... not sure... but DES (ie. crypt()) is widely believed to be total
crap nowadays ;)
You could always break the user-supplied PIN up into 2 separate keys, and
use a cascading cipher; in other words, stack IDEA or Blowfish etc. on top
of triple-DES (triple-DES is a good bit stronger than plain DES). That
should be quite slow. In other words
cryptpwd = IDEAcrypt (key1, 3DEScrypt (key2, "realpassword"))
Also, *don't forget the salts*. Store a large block of random data for
each password, and use that as part of the key. It'll mean an attacker
will have to get hold of the salt as well as the encrypted password, and
it will mean that a brute-force attack can only be run on one password at
a time.
I'm sure with a sufficiently long key, even if most of it comes from a
salt, you can get the algo to run quite slowly -- which is what you're
after ;)
There's some good stuff in chapter 15 of Applied Cryptography about
combining block ciphers like this.
--j.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:10:43 GMT