[prev in list] [next in list] [prev in thread] [next in thread] 

List:       moderncrypto-noise
Subject:    Re: [noise] earlier IK
From:       Justin Cormack <justin () specialbusservice ! com>
Date:       2021-05-19 13:33:14
Message-ID: CAK4o1WwoKvrQ_vPjyQ+dmpd_wwoSC+iAh6T-qFm8S51teM=fsQ () mail ! gmail ! com
[Download RAW message or body]

Knowing the public key isn't a security issue, other than what it
reveals about identity.

Justin

On Wed, 19 May 2021 at 14:17, Arvid Picciani <aep@exys.org> wrote:
> 
> yes.
> actually, there might be a better option. If i send the _responder_ static key in \
> prelude we get some minimal identity hiding because the responder key changes \
> frequently. 
> however, i'm unsure about the security implications because  noise never sends the \
> responder static anywhere for precedent. Does an attacker gain any advantage by \
> knowing the public key for the responder? Is it easier to break then maybe since \
> they can also observe the 0RTT payload encrypted for that recipient? 
> On Wed, May 19, 2021 at 3:08 PM Filippo Valsorda <filippo@ml.filippo.io> wrote:
> > 
> > Sounds like what you want is KK with the initiator's s in the prologue.
> > 
> > You obviously lose all initiator identity hiding, but otherwise it should have \
> > the same payload properties as regular KK. 
> > 2021-05-19 14:07 GMT+02:00 Arvid Picciani <aep@exys.org>:
> > 
> > In order to not share the responder static key between multiple servers,
> > i am considering creating a responder key per initiator.
> > the responder key is then loaded hot only when needed and can be revoked more \
> > fine grained. 
> > This would require the responder to know which key to load. The current IK \
> > pattern has the initiator static encrypted with the responder static, so i can't \
> > look up the matching receiver keys. 
> > I could just use IX , but i actually want encrypted 0RTT payload,
> > 
> > so something like
> > 
> > XIK:
> > <- s
> > ...
> > -> s, ss, e, es
> > <- e, ee, se
> > 
> > i'm assuming 0RTT payload has the same protection as IK, i.e. Source 1 and \
> > Destination 2, except it looses identity hiding, as that's kind of the point
> > 
> > is this correct?
> > 
> > thanks,
> > Arvid
> > 
> > --
> > +4916093821054
> > _______________________________________________
> > Noise mailing list
> > Noise@moderncrypto.org
> > https://moderncrypto.org/mailman/listinfo/noise
> > 
> > 
> > _______________________________________________
> > Noise mailing list
> > Noise@moderncrypto.org
> > https://moderncrypto.org/mailman/listinfo/noise
> 
> 
> 
> --
> +4916093821054
> _______________________________________________
> Noise mailing list
> Noise@moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
_______________________________________________
Noise mailing list
Noise@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/noise


[prev in list] [next in list] [prev in thread] [next in thread]