Re: [saag] Improving the CHAP protocol

Sent from my mobile device

> On Sep 18, 2019, at 3:31 PM, Black, David <David.Black@dell.com> wrote:
> 
> 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.

That shouldn’t be necessary, I should have looked at the registration policy.

Thank you,
Kathleen 

> 
> Thanks, --David
> ----------------------------------------------------------------
> David L. Black, Senior Distinguished Engineer
> Dell EMC, 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
> David.Black@dell.com
> ----------------------------------------------------------------
> 
>> -----Original Message-----
>> From: saag <saag-bounces@ietf.org> On Behalf Of Mark D. Baushke
>> Sent: Wednesday, September 18, 2019 11:48 AM
>> To: Maurizio Lombardi
>> Cc: saag@ietf.org
>> 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
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag