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: Wed, 23 Mar 2016 07:18:43 +0300
From: Solar Designer <>
Subject: Re: [PHC] hash encryption

On Wed, Mar 23, 2016 at 06:41:25AM +0300, Solar Designer wrote:
> Attached is an implementation of a 256-bit block cipher based on
> SHA-256 (which yescrypt has anyway).  I'd appreciate a review.

Oh, I need to clarify: I use "uint64_t block[4]" in the interface to
ensure alignment and be able to do fast XORs without strict aliasing
violations.  Of course, when I pass a half-block to SHA256_Update(), I
rely on a specific byte order of the data.  I do not expect this block
encryption function to work on 4 integers, always producing the same
other 4 integers - what encrypted integers it produces depends on the
host's endianness.  I expect this function to be used internally on data
that is in a host-independent byte order, just properly aligned and
passed in here as four 64-bit integers, and to produce encrypted data in
a host-independent byte order, meaning that the integer values will vary
by the host's byte order, and that's fine (because they're not to be
used as integers).  Perhaps this needs at least a source code comment.

The test program does invoke the function on integers, and it does print
integers.  What I expect from it is that it shows successful decryption
to the original values.  However, the encrypted values will vary by
endianness.  I need to also add a test to ensure the encrypted values
are a host-independent sequence of bytes, as long as the inputs are.


Powered by blists - more mailing lists