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  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: Thu, 5 Dec 2013 11:55:22 -0800
From: Andy Lutomirski <>
To: discussions <>
Subject: Re: [PHC] blakerypt sequential memory-hard function

On Wed, Dec 4, 2013 at 11:16 PM, Stephen Touset <> wrote:
> On Dec 4, 2013, at 5:26 PM, Andy Lutomirski <> wrote:
>> I like it.  Will this be integrated into the blakecrypt algorithm or
>> will it be something that users are supposed to do?
> Yes! I have some code for this written, but it’s not yet finished, and I wanted to put the memory-hard function out to get feedback since I’m happy with its current construction.
>> A couple comments on blakecrypt:
>> Using 2^f_time as the iteration count seems unnecessarily restrictive
>> -- is there any reason not to just use f_time?
> I wanted the “cost factors” to all work on the same scale. Having CPU scale exponentially may be overkill, but at the same time, it doesn’t seem to be all that useful in practice to ever increase a cost factor by less than double. If you can tolerate some CPU cost `x`, but not `2x` is being able to fine-tune it to a cost of `1.3x` really a big deal?
>> For password hashing on multicore client machines, using available
>> parallelism seems valuable.  Would it make sense to have an extra
>> parameter for parallelism?
> Actually, I had code for this in an earlier revision. The multiple threads all read from the same ROM in an order randomized from the session key and a thread ID. My code was dependent upon libdispatch and GCD, which limited its portability. I considered OpenMP and C11 threads, but neither are currently supported by the version of clang I have.
> In the end, I removed it on the suggestion of some colleagues, but I’m definitely open to suggestions for putting that code back in.

The simplest (and most compatible) way to do it may be to leave the
actual threading part to callers.  For example:

blakecrypt_begin(&context, password, salt, etc);

parallel_for(int i = 0; i < nthreads; i++)
    blakecrypt_thread(&context, i);

blakecrypt_finish(&context, ...);

blakecrypt_finish could have an appropriate assertion to make sure
that the correct calls to blakecrypt_thread happened.


Powered by blists - more mailing lists