At 4:56 PM -0500 1/28/10, Garance A Drosihn wrote:
>At 1:09 PM -0800 1/28/10, Xin LI wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>On 2010/01/28 12:18, Chris Palmer wrote:
>>> For backwards compatibility, which do people prefer: Creating a new $N$
>>> prefix every time we re-tune the algorithm, or using a new notation to say
>>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>>> et c.?
>>I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
>>administrators who want to fine tune the round number as need.
>Might want to make it something like $1.nnn.bbb$, so the admin can specify
>the number of bits as well as the number of rounds. And then pick some
>algorithm where those two values make sense. :-)
>By going for something tunable, users don't HAVE to change their password
>the moment the sysadmin decides that it's time for better protection. The
>sysadmin can change the numbers used when the user changes their password,
>and then gradually transition everyone to the stronger encryption.
>It also means that users could decide to use stronger encryption if they
>are willing to wait for it, without the sysadmin needing to do anything.
Also note that we might not want the "nnn" number to be an exact count
of the number of times it was hashed. For instance, it might be that
the algorithm works best if the number is always hashed a prime-number
of times, or that it's always a power-of-2 increase. So a value of 3
for "nnn" just means "more times than 2 would do", and not necessarily
"exactly one more time than would be done for 2".
This is just meant as something we might want to consider.
Garance Alistair Drosehn = email@example.com
Senior Systems Programmer or firstname.lastname@example.org
Rensselaer Polytechnic Institute or email@example.com