Re: [saag] Improving the CHAP protocol

Maurizio,

This is the right place to start the discussion.  If you pull together a
draft before the deadline and want a slot to present at SecDispatch, send a
message there as well.  SecDispatch will help find a home for the draft,
even if that is an AD sponsored draft (if there's not WG that is a fit).

Best regards,
Kathleen

On Wed, Sep 18, 2019 at 11:48 AM Mark D. Baushke <mdb=
40juniper.net@dmarc.ietf.org> wrote:

> 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
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

Best regards,
Kathleen