Warner Losh wrote this message on Fri, Mar 07, 2014 at 22:30 -0700:
> On Mar 7, 2014, at 10:22 PM, Allan Jude <free...@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

Notice the might...


> > 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

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."
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to