Closed GoogleCodeExporter closed 9 years ago
The overhead of the various python wrappers is negligible (< .001s per call) -
the speed difference is probably due to actual differences between
cryptacular's bcrypt C extension and the C extension of whichever backend
passlib is using (pybcrypt or bcryptor).
I'm not too surprised by this: pybcrypt hasn't been updated in a while, and
uses the stock BSD implementation... whereas it looks like cryptacular has
integrated some of John the Ripper's bcrypt code - which is likely the fastest
implementation out there.
There's not much I can do speed things up at the moment. However, I'm planning
on adding a builtin bcrypt C extension to Passlib 1.7 (per issue 40 -
https://code.google.com/p/passlib/issues/detail?id=40). This was initially
motivated by the fact that pybcrypt *still* doesn't support python 3, but it'll
also give me a chance to make sure passlib's extension is competitive
speed-wise :)
[BTW - a correction in your test script - cryptacular's pbkdf2 hash actually
uses PBKDF2-HMAC-SHA1 underneath - so you should compare it against
passlib.hash.pbkdf2_sha1 or passlib.hash.cta_pbkdf2_sha1 instead - which will
probably be even faster :) ]
Original comment by elic@astllc.org
on 22 Dec 2012 at 5:54
ah i see :D
thank you again, am new in cryptographic world :)
BTW: any implementations about pbkdf-sha3 ? sha3 has been approuved.
Original comment by alabdelo...@gmail.com
on 23 Dec 2012 at 9:39
re: sha3 -
As the situation is now, SHA3 is actually a *worse* choice than SHA2... For
password hashing, you want your underlying cryptographic primitives to be as
expensive (speed- & hardware- wise) as possible; whereas SHA3 was
designed/chosen to require less hardware, and be much faster than SHA2. This
means brute force attacks against PBKDF2-SHA3 would also be cheaper and faster
than PBKDF2-SHA2! Given that SHA2 is still considered secure, I'd recommend
staying with PBKDF2-SHA2 or BCrypt. That said, once SHA3 appears in the stdlib
or pypi, I'll probably add support into passlib anyways, but do it quietly :)
Original comment by elic@astllc.org
on 27 Dec 2012 at 7:33
hi
pysha3 is already in pypi
http://pypi.python.org/pypi/pysha3/0.3
and another wish, what about scrypt (my stomach is big :D ) because it has
problem when installing with windows due to openssl library :(
thank you again :)
Original comment by alabdelo...@gmail.com
on 29 Dec 2012 at 9:40
Re: pysha3 - That's the extension I'll probably end up using that as the SHA3
backend for passlib, but I'm holding off for a bit - the extension has a few
too many architecture-specific bugs cropping up in that project's changelogs -
enough so the documentation warnings off using it for HMAC (and thus I assume
PBKDF2), and finding/fixing incorrect hashes after the fact is a real headache.
Re: scrypt - issue 8 is where I'm tracking the status of that (though I haven't
updated the issue in a while). While I think the idea behind SCrypt is
brilliant on paper, it hasn't had the dedicated years of scrutiny SHA3 just
emerged from - it's only now coming to the attention of the password crackers
(e.g. JohnTheRipper, oclHashCat projects), and they're the ones who (IMHO) have
the proper motivation to truly test the design. So while I'm moving towards
adding it into passlib w/in the year, I'm dragging my feet, because I want to
see how it fairs under fire before offering it as an alternative.
Mind you, as a passlib user, I want to see the shiny new stuff NOW NOW NOW also
:)
Original comment by elic@astllc.org
on 5 Jan 2013 at 4:26
thank you for the reply :)
am sorry for asking for new stuff, am new in crypt world, and it's passlib that
has introduced me to that world :D
BTW, it's only last week that i've discovered Peeper (which you plan to
implement in 1.8? )
so if i'll try to do my best to test it :D
and thank you again ;)
Original comment by alabdelo...@gmail.com
on 5 Jan 2013 at 9:45
Since this issue was last addressed --
Testing still shows py-bcrypt as being slightly slower than cryptacular (on the
order of 11ms over 2**12 rounds). However, Passlib 1.6.2 adds support for the
bcrypt package, a cffi-based (and pypy-compatible) bcrypt backend that debuted
this year. Testing shows it's running neck and neck with cryptacular.
While I like the idea of Passlib having it's own self-contained C extension,
the field has gotten so crowded (py-bcrypt, bcrypt, cryptacular), that I don't
want to duplicate all the effort of these other projects. So I've come around
to the idea of having passlib continue to rely on external C extensions, with
the bcrypt package being the recommended bcrypt backend for now (due both to
speed and it's use of cffi).
- Eli
Original comment by elic@astllc.org
on 27 Dec 2013 at 5:14
Original issue reported on code.google.com by
alabdelo...@gmail.com
on 10 Dec 2012 at 1:43Attachments: