excessive SHA1 calls

[tridge at samba.org]

Love,

I noticed this on IRC

 > lha: its the point of it, it uses PKCS7-PDF2, and its tuneable-slow
 > to stop password guessing

would tuning the number of passes break interoperability with other
implementations? If not, then I'd suggest we add a tuning option.

 > Yes, its possible to cache the result of the s2k(password,enctype) on
 > success, and invalidate it on password change.

What are the security implications of this cache data? Do we have to
protect the cache like a password? Sorry for the obvious questions,
I'm just not familiar with the PKCS7 algorithms.

If we don't have to protect the data then we should hook this into a
general cache system. Otherwise we'd need a separate cache mechanism.

This doesn't just affect valgrind testing btw. Imagine you have a lab
of 500 machines and there is a power failure/reboot. At 0.4s per
connection thats 200 seconds of CPU time just to answer negprot
requests. Even with some skew in startup times, it's highly likely
that some of the machines will timeout and fail to mount drives.

That's whats happening with the BASE-NTDENY1 under valgrind. That
opens 4 connections, whereas the other tests tend to open 1
connection. Under valgrind the 4 connections is enough to make it slow
enough that some of the clients timeout during the negprot. With 1
connection we get away with it (and this is on a 2.4GHz dual Xeon
server).

Scale this up to hundreds/thousands of clients and you will get a
really bad problem even with fast cpus.

Cheers, Tridge