Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UZqfl-0003KT-BC for pgsql-docs@arkaria.postgresql.org; Tue, 07 May 2013 22:47:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UZqfk-0002I3-Kr for pgsql-docs@arkaria.postgresql.org; Tue, 07 May 2013 22:47:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UZqfj-0002Hw-Ne for pgsql-docs@postgresql.org; Tue, 07 May 2013 22:47:47 +0000 Received: from mail-oa0-f50.google.com ([209.85.219.50]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UZqfg-000413-O7 for pgsql-docs@postgresql.org; Tue, 07 May 2013 22:47:46 +0000 Received: by mail-oa0-f50.google.com with SMTP id l10so1362931oag.9 for ; Tue, 07 May 2013 15:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5ZuVvp+NHtBPH2dq63ZAv3BRBFBycdiR9y/veacmHok=; b=EABDDkoT6ZnE+d/9BsADL6lYrEPcaEpjrn3TrUCvKoCsTvqq0KX12qp6HBaRvwEcme wh+gnCgTNhRVZz+Gqq0KdSBvgKlYWOx9SlBuzRFbDicTHCDIFNw6YQKPqvnTSObT5fYR c+Dr+2GK4Q0pcSxpWSv4rm38ItT33EJgbRSD+TQCo6BRrJhvIaWmk1j5dSVKLKF/t5du vhk9JgumYcFeGl4c96rJra0nF2QE1pTJzPf7DjiBrRDujhnaizPDwm5MgSQcetf2G0Xy phfNmM4Zcjr2x5WzX868fxHJitSuVirI45SDkcOt+rafAtwHeSFDP+LXPejUjbvECoGv 5TKA== MIME-Version: 1.0 X-Received: by 10.60.134.147 with SMTP id pk19mr1229847oeb.4.1367966863147; Tue, 07 May 2013 15:47:43 -0700 (PDT) Received: by 10.182.102.2 with HTTP; Tue, 7 May 2013 15:47:43 -0700 (PDT) In-Reply-To: <4820.1367964343@sss.pgh.pa.us> References: <4820.1367964343@sss.pgh.pa.us> Date: Tue, 7 May 2013 15:47:43 -0700 X-Google-Sender-Auth: m3PAanBN4eJu9VhBijcnbfEuMUQ Message-ID: Subject: Re: pgcrypto docs From: Miles Elam To: pgsql-docs@postgresql.org Content-Type: multipart/alternative; boundary=047d7b41cc18f1488904dc289ab4 X-Pg-Spam-Score: -1.7 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --047d7b41cc18f1488904dc289ab4 Content-Type: text/plain; charset=ISO-8859-1 Personally I've found the relative times instructive, merely outdated. Perhaps using md5 as a baseline and evaluating estimates relative to that baseline? md5 = 1 sha1 = 4 crypt-des = 7 crypt-md5 = 1,000 crypt-bf/5 = 12,500 crypt-bf/6 = 25,000 crypt-bf/7 = 50,000 crypt-bf/8 = 100,000 This way, with the caveat that performance will vary from machine to machine, there is a sense of the relative costs of using each algorithm, which does not change as wildly with time. It lets people know how bad md5 and sha1 are for protecting passwords et al. It also demonstrates that each turn of blowfish in this module effectively doubles the time needed to crack and halves the number of hashes one can perform. In short, I'd hate for the baby to be thrown out with the bathwater. Cheers, Miles Elam On Tue, May 7, 2013 at 3:05 PM, Tom Lane wrote: > Miles Elam writes: > > Currently the docs show various stats on hashes per second and time > needed > > to find a particular key. Unfortunately since the times are based upon a > > Pentium 4 @1.5GHz, I worry that many would take the advice on that page > at > > face value, e.g., "more than 100/sec is too much while less than 4/sec is > > too few," with a P4 in mind. > > It seems like this table is guaranteed to be obsolete in a few years > no matter what. Can we get rid of it entirely? > > regards, tom lane > --047d7b41cc18f1488904dc289ab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Personally I've found the relative time= s instructive, merely outdated.=A0 Perhaps using md5 as a baseline and eval= uating estimates relative to that baseline?

md5 =3D 1
sha1 =3D 4
crypt-des =3D 7
crypt-md5 =3D 1,000
crypt-bf/5 = =3D 12,500
crypt-bf/6 =3D 25,000
crypt-bf/7 =3D 50,000
crypt-bf/8 = =3D 100,000

This way, with the caveat that performance wi= ll vary from machine to machine, there is a sense of the relative costs of = using each algorithm, which does not change as wildly with time.=A0 It lets= people know how bad md5 and sha1 are for protecting passwords et al.=A0 It= also demonstrates that each turn of blowfish in this module effectively do= ubles the time needed to crack and halves the number of hashes one can perf= orm.

In short, I'd hate for the baby to be thrown out with th= e bathwater.


Cheers,

Miles Elam
=



On Tue, May 7, 2013 at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us>= wrote:
Miles Elam <mileselam+postgresql@gmail.com> writes:
> Currently the docs show various stats on hashes per second and time ne= eded
> to find a particular key. =A0Unfortunately since the times are based u= pon a
> Pentium 4 @1.5GHz, I worry that many would take the advice on that pag= e at
> face value, e.g., "more than 100/sec is too much while less than = 4/sec is
> too few," with a P4 in mind.

It seems like this table is guaranteed to be obsolete in a few years<= br> no matter what. =A0Can we get rid of it entirely?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 regards, tom lane

--047d7b41cc18f1488904dc289ab4--