[noise] Regarding Static Key Authentication

[Alexey Ermishkin]

A gentle reminder that VirgilSecurity actively works on integrating custom PKI (not certificate based) into NoiseSocket and even has a sample for it. https://github.com/go-noisesocket/noisesocket/tree/master/virgil

I haven’t touched it in a while, could be outdated but If you guys are interested in doing something similar just drop me a message.


Cheers!
Alex

 

From: Noise <noise-bounces at moderncrypto.org> On Behalf Of Trevor Perrin
Sent: Tuesday, May 1, 2018 9:48 PM
To: Nadim Kobeissi <nadim at symbolic.software>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Regarding Static Key Authentication

 

 

The Noise spec has some text about this:

 

"""

Authentication: A Noise protocol with static public keys verifies that the corresponding private keys are possessed by the participant(s), but it's up to the application to determine whether the remote party's static public key is acceptable. Methods for doing so include certificates which sign the public key (and which may be passed in handshake payloads), preconfigured lists of public keys, or "pinning" / "key-continuity" approaches where parties remember public keys they encounter and check whether the same party presents the same public key in the future.

"""

 

Trevor

 

 

On Tue, May 1, 2018 at 1:01 PM, Nadim Kobeissi <nadim at symbolic.software <mailto:nadim at symbolic.software> > wrote:

Thank you, everyone!



Nadim Kobeissi

Symbolic Software • https://symbolic.software

Sent from office

 

 

On Tue, May 1, 2018 at 2:50 PM Marian Beermann <public at enkore.de <mailto:public at enkore.de> > wrote:

Hi Nadim,

yes, if the intention is to have an AKE (authenticated key exchange),
then the peer's static key needs to be authenticated in one way or
another. Noise does not provide an out-of-the-box way to do that.

-Marian

On 01.05.2018 14:31, Nadim Kobeissi wrote:
> Dear David,
> So, the conclusion is that any `s` appearing in either a pre-message or
> message pattern, is assumed to be authenticated out-of-band, as in
> independently of the Noise handshake, by the recipient party?
> 
> Thank you,
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
> 
> 
> On Tue, May 1, 2018 at 2:10 PM David Wong <davidwong.crypto at gmail.com <mailto:davidwong.crypto at gmail.com> 
> <mailto:davidwong.crypto at gmail.com <mailto:davidwong.crypto at gmail.com> >> wrote:
> 
>     > If a token 's' appears in a Noise handshake pattern pre-message
>     flight, it
>     > is reasonable for us to assume that this key represented by 's' was
>     > pre-authenticated by the parties. That is, if the initiator sent
>     's' in a
>     > pre-message, then the responder is assumed to have authenticated
>     's' already
>     > out of band, using for example a QR code as is the current
>     use-case, for
>     > example, in the Signal secure messenger.
> 
>     I don't think this is a good comparison. Signal allows you to
>     post-handshake authenticate the session whereas a pre-message `s`
>     means that you have pinned `s` and thus you trust the session from the
>     start.
> 
>     `s` in a message pattern implies that you have a way to ensure that
>     you know that `s`. This can be done in different ways:
> 
>     * out of band post-handshake (like Signal)
>     * by having the sender also send a signature from some authority that
>     you trust (PKI)
>     * by recognizing the cert from a trust store
>     * ...?
> 
>     Hope that helps,
>     David
> 
> 
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org <mailto:Noise at moderncrypto.org> 
> https://moderncrypto.org/mailman/listinfo/noise
> 


_______________________________________________
Noise mailing list
Noise at moderncrypto.org <mailto:Noise at moderncrypto.org> 
https://moderncrypto.org/mailman/listinfo/noise

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180501/0845dae4/attachment.html>