s2k-count limits

[Matteo Sasso]

Hi everyone,

In a thread a while back (Nov. 30, 2009) David Shaw pointed out that
current default for s2k-count might be a little low for today's CPU
speeds: a brute force attack is more and more feasable against users
who need passphrases they can remember.

However there is something else that's troubling me right now: in that
thread a quick benchmark by Werner Koch showed that about 5 million
iterations is a good challenge for today's hardware, as it kept his PC
busy for 90ms. That number is just 13 times lower that the maximum
number of iterations allowed by gpg.

This is important because:
- As you probably know LUKS uses a similar scheme and a time of 1
second is used for calibration. People who prefer a more conservative
number of iterations (equivalent to 1s) are already hitting the
maximum on gpg.
- Moore's law is still going strong. 90ms today means 1ms in 10 years.
This is not enough against a determined attacker (a rough estimate
gives 7 days to brute force a 40-bit entropy passphrase with 1000
entry-level CPUs in 2020).
- Iteration count is really important to protect a passphrase (and
data) in a symmetric encryption scenario. Think encrypted, remote
backups where the user doesn't want to generate a truly random key for
fear of losing it. The user doesn't mind even a huge initialization
delay (backups take long anyway) if that means more protection.

I hope I made my point clear. Thank you for your attention and for
your comments.