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 <>
Subject: Re: [PHC] A review per day - Battcrypt

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.

Version: GnuPG v1


Powered by blists - more mailing lists