[PATCH] Add support for Salsa20/12 - 12 round version of Salsa20

[Jeffrey Johnson]

The design/naming issue is that newer hashes refer to a family with parameter(s).

Retrofitting a given parameter choice into existing implementations is necessary because there is no easy/obvious means to associate the parameter with signature/hash metadata except by assigning a name to the algorithm+parameter choices.

73 de Jeff

Sent from my iPhone

On Aug 11, 2013, at 5:45 PM, Simon Josefsson <simon at josefsson.org> wrote:

> Werner Koch <wk at gnupg.org> writes:
> 
>> On Fri, 26 Jul 2013 21:12, simon at josefsson.org said:
>> 
>>> eSTREAM picked 12-rounds Salsa, and not the 20-round version, so it
>> 
>> I see.
>> 
>>> I would recommend against implementing 12-rounds without also
>>> implementing 20-rounds -- DJB specified 20-rounds and I would personally
>> 
>> Well, we implemented 20 rounds and not yet 12 rounds.
> 
> Ah.
> 
>> In how far is eSTREAM relevant; why do we need to care about it?
> 
> People has a tendency to defer to authorities, so I guess there will be
> a set of projects that will look for a non-cracked stream cipher and
> ends up chosing Salsa20, and then goes with the variant of Salsa20 that
> eSTREAM recommends because they don't know better.
> 
>> Is there any project already using Salsa20r12 or is there still time to
>> ignore this variant?  In other words, would you mind to change your I-D
>> to “Standard” 20 rounds Salsa?
> 
> Yes, this is still an open question and under discussion.  The only
> thing I am strongly against is to only standardize on 12-rounds, so the
> remaining options would then be 1) both 12 and 20 or, 2) only 20 rounds.
> I'm not sure how strong the 12-rounds crowd is; if it is big enough to
> warrant including both or if we can swing them over to 20 rounds.
> 
>> It is not that I am against adding this variant, but I try to keep the
>> number of implemented algorithms low.  We already had to add a couple of
>> algorithms simply for political reasons.  I would appreciate if we could
>> avoid that (and thus make IanG happy).
> 
> Yes, I fully sympathise with this concern.
> 
> /Simon
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel