No, I think he means Ed448 and Ed25519. 

Adding context to Ed25519 (so using Ed25519ctx) requires using a different 
function than the one available in several implementations such as libsodium.

If we choose the no context option it doesn’t matter: Ed25519ctx with empty 
context == Ed25519ctx

Yoav

> On 16 Nov 2016, at 13:58, Yaron Sheffer <[email protected]> wrote:
> 
> If you mean the same policy for IPsec and TLS, I fully agree.
> 
> Context prevents cross-protocol attacks, and I wouldn't worry about 
> "encouraging bad behavior". Users will behave badly whether we encourage them 
> or not :-)
> 
> Thanks,
>       Yaron
> 
> On 16/11/16 13:47, Daniel Migault wrote:
>> i would like the same policy - context or no context - applied to both
>> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
>> practice.
>> 
>> Yours,
>> Daniel
>> 
>> 
>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <[email protected]
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>>    On 16/11/16 12:41, Paul Wouters wrote:
>> 
>> 
>> 
>>            On Nov 16, 2016, at 10:49, Yoav Nir <[email protected]
>>            <mailto:[email protected]>> wrote:
>> 
>>            So I suggest to add the following paragraph at the end of
>>            section 2 of the eddsa draft:
>> 
>>              The context parameter for Ed448 MUST be set to the empty
>>            string.
>> 
>> 
>>        I agree. Context seems useful for generic crypto but not for
>>        something that is already strongly bound by an IETF transport
>>        protocol.
>> 
>>        Additionally, we have a similar problem too when allowing the
>>        same key in IKEv1 and IKEv2 where the key has different security
>>        properties.
>> 
>>        Paul
>> 
>> 
>>    I don't think there's any cost to having a non-empty context string,
>>    e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>>    attacks show that signatures can be abused even when embedded in a
>>    transport protocol.
>> 
>>    The fact that we have the same problem elsewhere is no reason to
>>    propagate it further.
>> 
>>    Thanks,
>>            Yaron
>> 
>> 
>>    _______________________________________________
>>    IPsec mailing list
>>    [email protected] <mailto:[email protected]>
>>    https://www.ietf.org/mailman/listinfo/ipsec
>>    <https://www.ietf.org/mailman/listinfo/ipsec>
>> 
>> 

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to