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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 4 Apr 2014 18:18:46 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Some remarks on Lanarea

I have a question for the author:  Was calling blake2b on the "chain"
while passing matrixSize as it's length intentional?  I'm trying to
figure out why the code is so much slower than I would expect, and I
think this is the main culprit.  I changed the "chain" to just the 16
diagonals, and it sped up by about 100X.

The code is close to good.  I think it needs some work like fixing
this issue, and some of the comments leave me scratching my head (like
"prevent cache read hits").  Overall, I like the code better than I
was expecting, since I have some issues with claims in the paper.

I get the impression this is a project that's close, but not quite
finished.  The hashing functions all seem to be written with
efficiency in mind, and you've got a call to blake2b that seems close
to breaking the long non-cryptographic hashes into more secure short
chains, but instead the chain variable is simply overwritten and
rehashed without feeding it back into the matrix state.  It feels like
you intended to do that, and possibly do all this with modulo 2
arithmetic to eliminate the slow mod operators.

I like the direction the code seems to have been progressing.  Similar
to  Lyra2, rows can be adjusted in size to improve memory access speed
when we bust out of cache into main memory.  The number of rows could
be adjusted to fill more/less memory.  The non-cryptographic hashing
itself doesn't look bad to me, though data-dependent branching seems
to be frowned upon.

Anyway, just some thoughts.  I had some trouble compiling it, and so I
dug into the code, and it looks like a work in progress, but
potentially good work.  I suspect you're more like me, and more
comfortable with code than writing papers.

Bill

Powered by blists - more mailing lists