pgcrypto docs
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.
Using a first-generation Core i5 processor as a baseline, we're looking
roughly at about a 64x increase in processing power, not including any
dedicated crypto processing in hardware like their AES extensions.
The new table, simplistically adjusted by 64x is as follows.
Algorithm Hashes/sec For [a-z] For [A-Za-z0-9]
--------------------------------------------
crypt-bf/8 1792 4 years 3927 years
crypt-bf/7 3648 2 years 1929 years
crypt-bf/6 7168 1 year 982 years
crypt-bf/5 13504 188 days 521 years
crypt-md5 171584 15 days 41 years
crypt-des 23221568 157.5 minutes 108 days
sha1 37774272 90 minutes 68 days
md5 150085504 22.5 minutes 17 days
--------------------------------------------
Perhaps with a more up to date dataset, users would be far less likely to
use far more turns of blowfish and be far more (read: appropriately) averse
to using schemes like md5. After all, who wants to use a hash that can be
cracked on 2-year old mainstream consumer processors in less than half an
hour, let alone dedicated hardware with real money behind it.
Unfortunately I only have laptops, no desktops these days. (A sign of the
times?) So while I could re-run these benchmarks on a mobile i3, I don't
know if that is what is appropriate for this data table.
Anyway, food for thought.
Cheers,
Miles Elam
Miles Elam <mileselam+postgresql@gmail.com> 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
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
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 <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Miles Elam <mileselam+postgresql@gmail.com> 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 pageat
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
On Tue, May 7, 2013 at 03:47:43PM -0700, Miles Elam wrote:
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,000This 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.
I have used your new testing times, plus added these relative
measurements, which shoud give us the best of both worlds. Patch
attached; you can see the results here:
http://momjian.us/tmp/pgsql/pgcrypto.html
What speed was the I5 CPU you used?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
crypto_timing.difftext/x-diff; charset=us-asciiDownload+59-58
On Wed, Dec 4, 2013 at 12:42:08PM -0500, Bruce Momjian wrote:
On Tue, May 7, 2013 at 03:47:43PM -0700, Miles Elam wrote:
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,000This 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.
I have used your new testing times, plus added these relative
measurements, which shoud give us the best of both worlds. Patch
attached; you can see the results here:
Patch applied. Thanks. I updated the patch to say Intel i3..
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs