[noise] out of curve points

[Michael Hamburg]

> On Sep 19, 2015, at 8:45 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> On Sat, Sep 19, 2015 at 12:49 AM, Mike Hamburg <mike at shiftleft.org> wrote:
>> You're going to need to be very careful in the security proof if you make it easy for an attacker to set your key to mostly zeros. It looks to me like it's *probably* secure, but I get the feeling that eg the original tripleDH might not have been secure in this context since it doesn't hash the session and relies on scalar multiplication being 1:1.
> 
> 
> I don't follow - how is a DH output being zero, or k being zero,
> different than any other value?
> 
> Noise *is* careful to bind all static public keys into subsequent
> encryptions, so it doesn't need any additional assumptions (e.g.
> scalar multiplication being 1:1) to deal with identity binding.
> 
> Trevor

Maybe it’s the same as any other value, or at least the same as the identity / small-torsion points.

I’m not going to think about this too hard since I’m on vacation.  But can an attacker set their long-term public key and ephemeral to the identity / invalid, thereby causing the session keys of everyone who talks to them to collide?  Is that even an attack?  It might not be an attack, but is there a way to make it stronger?

I’d just think about it carefully, is all.

— Mike


>> 
>> -- Mike
>> 
>> Sent from my phone.  Please excuse brevity and typos.
>> 
>>>> On Sep 17, 2015, at 02:41, Trevor Perrin <trevp at trevp.net> wrote:
>>>> 
>>>> On Wed, Sep 9, 2015 at 12:10 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>>>> Hi folks,
>>>> 
>>>> The curve25519 implementation I'm using (agl's) returns all zeros if its
>>>> given points that are outside of the twist. How should noise handle peers
>>>> sending each other bogus points?
>>> 
>>> A party could always use some published value for their "private" key,
>>> so that the DH output is known.
>>> 
>>> Choosing a bogus keypair that also causes a known or all-zeros DH
>>> isn't that different.  But a good party should never do this.
>>> 
>>> So as long as computing with a bogus input doesn't reveal information
>>> about the private key (which it doesn't, since 25519 is
>>> "twist-secure"), I think we can let this be implementation defined.
>>> In the case of 25519: the DH could error, or return zeros, or just do
>>> the scalar multiply.
>>> 
>>> In an anonymity context you might want to mandate behavior, so that
>>> different parties can't be "fingerprinted" based on this.  But I don't
>>> see a security concern besides that.
>>> 
>>> Anyways, I'll add something about that in next rev.
>>> 
>>> 
>>> Trevor
>>> _______________________________________________
>>> Noise mailing list
>>> Noise at moderncrypto.org
>>> https://moderncrypto.org/mailman/listinfo/noise