Re: [saag] Improving the CHAP protocol

["Mark D. Baushke" <[e-mail]>]

Hi Maurizio,

Summary: SHA2-512/256 looks good to me. You may also wish to consider
         SHAKE128(M,256) or SHAKE256(M,256) generating 256 bits.

Long reply:

See "Comparing Hardware Performance of Round 3 SHA-3 Candidates using
Multiple Hardware Architectures in Xilinx and Altera FPGAs" 
https://pdfs.semanticscholar.org/20e2/3a26384b0edc4a218d2d180f0658c1c9a05f.pdf
and look for Keecak vs SHA-2 results.

Doing SHA3 in hardware is going to be faster than doing SHA2 in
hardware.

Doing SHA3 in software is going to be much slower than doing SHA2 in
software.

Comparing SHA2-256 to SHA2-512/256 in software depends on the native
size of a CPU word.

On a 64bit CPU, I beleve that doing a SHA2-256 will be slower than
doing a SHA2-512/256 on the order of 30% (best to run your own
benchmarks using something like 'openssl speed').

Per FIPS Publication 202, for SHA3, to get 256-bits of hash, there are
alternatives: SHA3-256, and the two Extendable-Output Functions (XOF):
SHAKE128 and SHAKE256. (There is no definition for SHA3-512/256.)

I have not done any software performance analysis of SHA3 functionality,
however, the https://keccak.team/2017/is_sha3_slow.html shows that using
the XOF functions are on performance part with SHA-2 on common
processors.

Considering longer term safety of the 256-bit hashes...

The SHA2-512/256 keeps an internal state of 1024 bits and displays only
256 bits of the finished hash. While SHA2-256 keeps an internal state of
512 bits and displays half of it (256 bits), so from a data hiding point
of view is should be more secure to use SH2-512/256.

As the intention is cryptographic agility, I think that adding
SHA2-512/256 is a good idea.

It may also be desirable to consult with your FIPS experts to determine
if SHAKE{128,256} is acceptable to generate the 256-bits needed and be
FIPS 140-2 compliant.

	-- Mark