Re: [Cfrg] KangarooTwelve draft has been updated to 01

[Benoît Viguier <[e-mail]>]

Hi John, Hi CFRG readers,

On 12/18/2017 03:34 PM, John Mattsson wrote:
>
> Hi,
>
> I am positive to standardization of this draft. High speed algorithms 
> are always welcome as long as they offer sufficient security margins, 
> and as far as I can tell, this proposal does just that.
>
>
> I read through the draft and have some high-level comments:
>
> - I think the draft should consider using the same notation as NIST. 
> While I kind of like the M,C notation in draft-viguier-kangarootwelve 
> better than the X,S notation by NIST, I think having a common notation 
> for all standardized algorithms in the Keccac-family avoids a lot of 
> misunderstanding.
>
While the notation X, S by NIST SP - 800-185, I find *M*essage and 
*C*ustomization string easier to remember:
variable names should be able to give the reader an idea of what they 
are about. Also NIST FIPS 180-4 and NIST FIPS 202 uses *M* for message. 
However if a majority of people are in favor of (X,S), I don't mind 
switching for this notation.

Worth to be remarked, the order of the parameters in KangarooTwelve are 
not the same as the one used in NIST SP - 800-185 :
KangarooTwelve uses (M,C,L) while NIST uses (X,L,S). I personally prefer 
the current notation (string, ?string, int) rather than the NIST one:  
(string, int, ?string) due to the alternation of the parameters' types.

> - “The SHA-3 functions process data in a serial manner and are unable 
> to optimally exploit parallelism available in modern CPU architectures”
>
> I think the draft should refer to ParallelHash [NIST SP 800-185] and 
> explain what benefits KangarooTwelve has compared to ParallelHash128.
>
> I think it would be good to discuss the Keccak family (SHA-3, SHAKE, 
> cSHAKE, ParallelHash, KangarooTwelwe) with a few more sentences (e.g. 
> pointing out that SHA-3 is not a XOF while the others are, 
> customization, parallelism, number of rounds, etc. ).
>
I will work on that.
>
> - “aims at higher speed than SHAKE and SHA-3.”
>
> Does it succeed? I think some numbers like the one presented in 
> https://keccak.team/2017/is_sha3_slow.html would be good.
>
The problem I see with proposing numbers for comparison is that they 
will be depreciated in a few years. I may be wrong but I don't think 
such would have their place in a RFC. In a paper definitively, but I'm 
doubtful about the interest in a RFC as they usually don't mention any 
speed comparison. Also even a single thread KangarooTwelve is faster 
than SHA-3 due to the halved number of rounds of Keccak[1600,12] with 
respect to Keccak[1600,24].

> - "It makes no assertion to its security"
>
> I think this document at least needs to tell the reader that 
> KangorooTwelve provides a 128-bit security strength.
>
> I think the document also need to give requirements for the parameter 
> outputByteLen. Doing so, it might need to discuss preimage and 
> collision attacks.
>
I don't think adding a requirements for the parameter outputByteLen is 
necessary but giving an information about the security strength related 
to that output can be added (e.g. at least 256 bit outputByteLen is 
required for 128 bit strength).

> - If CFRG decides to standardize this (which I think it should), there 
> should be discussion on whether MarsupilamiFourteen should also be 
> standardized, whether CFRG agrees with the decision to fix the 
> parameter B (NIST leaves it as a user-chosen parameter), and whether 
> CFRG agrees that B=8192 is the best choice.
>
I don't think B should be an option available to the user:
- this implies more test vectors
- it makes implementation more complex and reduces interoperability

But if a majority is in favor of making it a parameter, then why not.
>
> Cheers,
>
> John
>
> *From: *Cfrg <[e-mail]> on behalf of Benoît Viguier 
> <[e-mail]>
> *Date: *Thursday, 14 December 2017 at 17:33
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[Cfrg] KangarooTwelve draft has been updated to 01
>
> Dear CFRG participants
> I updated the RFC draft for KangarooTwelve with respect to the remarks of
> David Wong, Quynh Dang and the participants of IETF meeting in Prague.
> You can find the new version of the draft here:
> https://tools.ietf.org/html/draft-viguier-kangarootwelve-01
> KangarooTwelve provides an efficient and secure hashing primitive, which is
> able to exploit the parallelism of the implementation in a scalable way. It
> uses tree hashing over a round-reduced version of SHAKE128 as underlying
> primitive.
> The reference code is also at available at:<https://github.com/KeccakTeam/KeccakCodePackage>
> https://github.com/KeccakTeam/KeccakCodePackage
> (Standalone/KangarooTwelve-reference/K12.py)
> I intend to present the draft in London at the next CFRG meeting.
> -- 
> Kind regards,
> Benoît Viguier
> Software Engineer - PhD Student | Cryptography & Formal Methods
> Radboud University | Mercator 1, room 03.17, Toernooiveld 212
> 6525 EC Nijmegen, the Netherlands |www.viguier.nl <http://www.viguier.nl>

-- 
Kind regards,

Benoît Viguier
Software Engineer - PhD Student | Cryptography & Formal Methods
Radboud University | Mercator 1, room 03.17, Toernooiveld 212
6525 EC Nijmegen, the Netherlands |www.viguier.nl