Warner Losh wrote this message on Fri, Mar 07, 2014 at 22:30 -0700: > On Mar 7, 2014, at 10:22 PM, Allan Jude <freebsd_at_allanjude.com> wrote: > >> Performance for default, sha512 w/ 5k rounds: > >> AMD A10-5700 3.4GHz 3.8ms > >> AMD Opteron 4228 HE 2.8Ghz 5.4ms > >> Intel(R) Xeon(R) X5650 2.67GHz 4.0ms > >> > >> these times are aprox as the timing varies quite a bit, ~+/-10%? > > And what would that be on a RPi or other embedded device? Ok, here you go, IXP425 533MHz is ~1465ms.. This is a fast AVILA board, I have a slower 266MHz AVILA board next to me... Yes, that is 1.5 seconds at the default number of rounds for sha512 which is now the default for passwords... For comparision, md5 is 44.5ms and sha256 is 405ms on the AVILA... So, by making sha512, we just killed the performance of embedded systems... This is also with the default of 5000 rounds... So, the autoscaling could either help on embedded because we let the number of rounds drop below the default of 5k, or it stays the same, so, no hit on embedded... > And do the extra route have a peer-reviewed paper showing the increased strength? Well, if it doesn't increase the strength, then we might as well drop the rounds down to 1000 (the min per spec)... since clearly if increasing rounds pass 5k doesn't increase strength, then the same can be said for 1k... As for papers, I don't think anyone wrote a peer-reviewed paper saying that crypt-sha{256,512} is secure... Plus, they clearly thought that changing the rounds would be helpful, so, they added it as an option, well, actually, Drepper just copied Sun for making rounds an option... Per Drepper: The more rounds are performed the higher the CPU requirements are. This is a safety mechanism which might help countering brute-force attacks in the face of increasing computing power. Notice the might... http://www.akkadia.org/drepper/SHA-crypt.txt > > One possible solution would be just setting the default login.conf > > number of rounds, based on a test in the installer. Although this won't > > help for systems that are deployed by imaging, or VM images (like EC2 > > images) etc. Does CPU time measuring work properly on VM's? i.e. if I do a cpu intesive task and measure it with getrusage, do I get how much I really ran for? By my understanding, you can't, since often the VM isn't aware of the parent, so doesn't know when to stop the clock when it isn't running... Unless I'm missing something, you really can't do any cpu or profiling on a VM and trust the results... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Sat Mar 08 2014 - 07:39:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:47 UTC