phc-discussions - Re: [PHC] A review per day

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 14 Sep 2014 06:42:21 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A review per day - Battcrypt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 09/14/2014 04:54 AM, Solar Designer wrote:
> On Sat, Sep 13, 2014 at 02:41:24PM -0400, Bill Cox wrote:
>> However, in it's current form, it's too slow.
> 
> If we expect typical defensive implementations of battcrypt to be
> from scripting languages (yet using their native Blowfish), this
> isn't necessarily bad.  It provides some defense against attacks
> with native code implementations on CPU.  Ideally, both scripting
> and native would run fast, but if we can't have the scripting
> language implementations to run faster, maybe we also don't want
> fully native ones to run faster.
> 
> A drawback is that it makes battcrypt rather short-lived (a few
> years?) - it's only useful until bcrypt or some PHC winner (other
> than battcrypt) becomes universally available in currently relevant
> versions of PHP, etc. Frankly, this is probably already the case
> for bcrypt, as web apps are about to proceed to drop support for
> older versions of PHP anyway.
> 
>> These numbers are *way* too high for competing with Scrypt in
>> large memory hashing.  However, for strong GPU defense in small
>> memory, Battcrypt is great, just like PufferFish and bcrypt.  I
>> tried to see if I could tweak the code to get it to be speed
>> competitive with the 3 potential Scrypt replacements, but I
>> failed.  I reduced the encryption rounds from 16 to 1, and that
>> helped a lot, and I got rid of the early garlic rounds and only
>> computed the last one, but it was still too slow.
> 
> I think reducing the number of Blowfish rounds defeats the point
> of using battcrypt anyway.  battcrypt is primarily to be
> implemented using a scripting language's calls to a native
> implementation of Blowfish, so it usually won't be able to tweak
> the Blowfish rounds count.
> 
> Alexander
> 

Ah, I see.  That is a blow against PufferFish then, isn't it?
PufferFish upgraded the hashing to 64-bit, which will be incompatible
with PHP's BlowFish.

I've been tracking a "bcrypt" set of algorithms that all seem to
primarily focus on GPU defense in small memory.  I think Battcrypt is
the only one that is compatible with Blowfish.

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUFXEJAAoJEAcQZQdOpZUZhtQP/0x5gtfLjdrCA9ZGblpyHg1b
itxnxLHUFZRhzx7L/lU0H4T8D87vyAm35wyxBC2am4hTxi5zHSfb6XAaUt10cxtB
qPUExw4BEnBZRhu3Nh346KHR6okeCXbl+dZuoPQj527uXUlNWEcIahiO0VzofenE
L0vOdEALq1IqLLW0+TB2yh6XC4fqc3yTX1MxnIzuIRs4CL1kNMyjXJ6bgYoNZM36
fRFqGBvp5TFcQM0PNe3bFKVRXU6QS91VOM4/CcZSOnlcbw3DLjWmP6upY2GJhn7t
kHg6gQIpYz0otukwdGxSgaWq4S8L5xzcsACwv6cfHX1OiBD2wHlqz85Pf2dEAjQZ
GxCQs9igbdOmJHZU5pd7W39J7LLrm5yj4jmrO5vaexu9B/BnIAH56uQGIDcfZHYn
mhSgm9sdijjPWs/R4wKWABkk/oIF0W0hVlQJmtm5uj3FIf6cZUvgMZOEg9tLAgE/
H7aUZ7xosSjcNdULLQxglUR2vxAjSqcoYJs1wylmQAaG7rQrsuDyYX73Ko2tslEA
Pdzd2DELeh5RO7ampnrWwN2fTUg+P85kM6Q2jPNfXLWXmnElc0LaFSy9K3FRZGy5
Do914u+247vEZwdHAJd94sKdBg98NzZfvgiNV9XKrlA3QIWslWa2Gleyf7LDkJAh
wfz91xI90Dung0dSt1/N
=cwF0
-----END PGP SIGNATURE-----