Note also that I do have a stake here, as this is what we do for Juju. Its perfectly fine to wait 1s for a user-initiated login to get a response. But when you have 1000 agents that are restarting at the same time because you bounced the controller machine, it takes a *long* time for them all to get reconnected if you're spinning CPU cycles in a 1M iterated SHA hash loop. And it seems far more efficient to get 1M more time spent in brute force attacks by adding 20 bits (~5 more hex digits), to the key.
John =:-> On Fri, Jun 2, 2017 at 12:05 PM, John Meinel <[email protected]> wrote: > I'll note that if you're generating a password, there really isn't a > reason to then pbkdf2 it, is there? I thought the reason to use pbkdf2 was > because it is too easy to generate SHA hashes for common *human* passwords. > But as the brute-force search spaces increases exponentially with more > bits, just generate longer passwords. > > So if you are generating a random password, just make it 50 /dev/random > bytes long, and then you can use just simple 'sha' as the mapping back to a > password hash. > > At least, my understanding is that scrypt/et al exist because Humans > cannot remember good passwords, so they get massaged into slightly better > passwords by lots of rounds. But if you just started with more entropy in > the password, you don't have to worry about that. > > John > =:-> > > > On Fri, Jun 2, 2017 at 6:59 AM, Seth Arnold <[email protected]> > wrote: > >> On Thu, Jun 01, 2017 at 05:46:52PM -0700, Mike Pontillo wrote: >> > In doing so, I'm looking at deriving an shared key that can be used >> to >> > encrypt network traffic between peer rack and region controllers, and >> > eventually commissioned machines. The industry standard for key >> derivation >> > is the PBKDF2 algorithm, which makes brute force attacks to derive the >> > password from the key harder (by repeatedly running a hash function). >> >> PBKDF2 is also fairly old; I believe most cryptographers would prefer >> argon2, scrypt, or bcrypt to PBKDF2, with a grudging acceptance that if >> you have to sell into the FIPS marketplace you may not have a choice. >> Do we have a choice? >> >> We should also worry about the asymmetry of attackers vs defenders. >> Hashcat on gtx1080 GPUs can crack roughly a thousand of these >> million-iteration PBKDF2 per second. >> >> (I'm extrapolating a bit from the data easily available. This forum post >> says the benchmark uses 1000 iterations: >> https://hashcat.net/forum/thread-5799.html >> And these results say that it can run over a million per second: >> https://gist.github.com/epixoip/6ee29d5d626bd8dfe671a2d8f188b77b >> https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 >> So my assumption is one thousand times the work means a one thousand time >> slowdown. I haven't tested these speeds myself.) >> >> This points out that no matter how expensive the KDF being used, >> passwords such as '123456' 'monkey' etc are always terrible. It might >> take the controllers one second or so to generate the key, but given a >> password in the usual top-1000 list of passwords, hashcat can break it >> in about the same time it took to generate it. >> >> Thanks >> >> -- >> Maas-devel mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/maas-devel >> >> >
-- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
