speed up BCrypt

[GoogleCodeExporter]

hi, it seems that passlib uses external BCrypt is slower than the embeeded one 
used by cryptacular:

i got 0.40 for passlib Bcrypt, and 0.37 for cryptacular, the difference is not 
big, it's alway in order of 1/10 secondes.
i attached the working file.

NB: but in the other hand, pbkdf2 is faster! (0.14 VS 0.27, a double!)
and i used the same round values, is it because cryptacular uses a directly the 
C extension?

Original issue reported on code.google.com by alabdelo...@gmail.com on 10 Dec 2012 at 1:43

• Blocked on: #40

Attachments:

• bcryptt.py

[GoogleCodeExporter]

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

• Changed state: Accepted
• Added labels: Milestone-Release1.7, Performance, Priority-Medium, Type-Enhancement
• Now blocked on: #40

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Done
• Added labels: Milestone-Release1.6.2
• Removed labels: Milestone-Release1.7