From owner-freebsd-current@FreeBSD.ORG Sat Mar 8 08:39:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74E6ADEF; Sat, 8 Mar 2014 08:39:05 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43436A9D; Sat, 8 Mar 2014 08:39:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s288cnpO024852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Mar 2014 00:38:49 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s288clZM024851; Sat, 8 Mar 2014 00:38:47 -0800 (PST) (envelope-from jmg) Date: Sat, 8 Mar 2014 00:38:47 -0800 From: John-Mark Gurney To: Warner Losh Subject: Re: Feature Proposal: Transparent upgrade of crypt() algorithms Message-ID: <20140308083847.GF17019@funkthat.com> Mail-Followup-To: Warner Losh , Allan Jude , nanoman@nanoman.ca, freebsd-current@freebsd.org, d@delphij.net, secteam@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <20140307161313.GA49137@nanocomputer.nanoman.ca> <531A2CC1.8080802@allanjude.com> <20140307215223.GB49137@nanocomputer.nanoman.ca> <531A42F3.5020207@delphij.net> <531A4DE1.3070507@allanjude.com> <20140307230715.GA17019@funkthat.com> <531A67B4.1010303@delphij.net> <20140308021536.GB17019@funkthat.com> <531AA900.6090406@allanjude.com> <39EE68A1-E2F5-4373-BFC9-D1C3156B0056@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39EE68A1-E2F5-4373-BFC9-D1C3156B0056@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 08 Mar 2014 00:38:50 -0800 (PST) Cc: d@delphij.net, freebsd-current@freebsd.org, secteam@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , nanoman@nanoman.ca X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 08:39:05 -0000 Warner Losh wrote this message on Fri, Mar 07, 2014 at 22:30 -0700: > On Mar 7, 2014, at 10:22 PM, Allan Jude 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."