Re: [saag] Improving the CHAP protocol

["Black, David" <[e-mail]>]

Hi Mark,

Thank you very much for your comments and explanation - it seems that SHA2-512/256 is the better choice of SHA-2 hash (than SHA2-256) on both security and performance grounds.  My 0.02 is that fewer options are better here, so I'd register only SHA2-512/256 for SHA2, in addition to registering SHA3-256.

The registration procedure for the PPP Authentication Algorithms registry (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9) [iSCSI uses this by reference] is Expert Review, so we can submit the registration requests directly to IANA (e.g., don't need an Internet-Draft).  That said, I'd be happy to bring these requests to secdispatch in Singapore if there's a sense that more "eyes" should take a look at the requests (including the choice of algorithms) before the requests are submitted to IANA.

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]
----------------------------------------------------------------

> -----Original Message-----
> From: saag <[e-mail]> On Behalf Of Mark D. Baushke
> Sent: Wednesday, September 18, 2019 11:48 AM
> To: Maurizio Lombardi
> Cc: [e-mail]
> Subject: Re: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
> 
> 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/3a26384b0edc4a218d2d180f0658c1c9
> a05f.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
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag