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>] [day] [month] [year] [list]
Date: Sun, 16 Mar 2014 14:36:33 -0400
From: Bill Cox <>
Subject: Large memory block hash primitives?

I am considering splitting out the large block hashing algorithm in
TwoCats as a primitive function on it's own, which could be passed to
the higher level password hashing frameowrk.  I think Scrypt and
related memory hashing schemes could be implemented with such a
pluggable large block hashing function.

A large block hash function in my world looks like:

    Block hash2Blocks(SecureHash H, uint8 key[], Block block1, Block
block2, uint32 blocklen,
        uint32 subBlocklen, uint8 lanes, uint32 repetitions)

where Block is large block of memory, typically 1KiB to 16KiB in my
tests, and H is a cryptographic hash function such as SHA256 or
Blake2s.  Key is matched in block-length of the hash function H, so 32
for SHA256 and Blake2s, and 64 for SHA512 and Blake2b.  This function
takes two large blocks, hashes them together, updates the key, and
returns the new large block.  Blocklen is just the block length in
bytes, and subBlocklen is the length of pseudo-random sub-block memory
accesses, which should be equal to blocklen if password dependent
memory addressing is avoided.  Lanes is a parallelism parameter meant
to match the SIMD units on modern processors, and should be 1 for code
that does not support SIMD units.  Repetitions unfortunately needs to
be passed into the large block hash function to increase hammering L1
cache in a world where write-through caches are common.  The block is
only written on the last repetition of block hashing.

A key feature of hash2Blocks is that it may implement a custom fast
non-cryptographic hash function for hashing memory, and only call H at
the end.

Another large block hash that is common takes just one block and
returns a new hashed block:

    Block hash1Block(SecureHash H, uint8 key[], Block block, uint32
blocklen, uint32 subBlocklen, uint8 lanes)

Given these two large block primitives, I think I could implement
Scrypt, Catena, Escrypt, and TwoCats - all the memory hard frameworks
I've looked at.  I'm tempted to label them the way we do in our C APIs
with PBKDF2.  Something like:


Hash2Blocks_Catena and Hash2Blocks_TwoCats would take any hash
function primitive, while Script uses Salsa20/8.

One reason to consider large block hashing primitives is there may be
some good ones embedded in hashing frameworks such as Escript that
could be useful on their own.  Catena, in particular, could benefit
from a richer set of large block hashing primitives rather than
settling for 64-byte primitives that suffer from substantial
cache-miss penalties for large memory sizes.


Powered by blists - more mailing lists