[noise] Regarding Static Key Authentication

[Trevor Perrin]

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>
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> 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>> 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
>> > https://moderncrypto.org/mailman/listinfo/noise
>> >
>>
>>
> _______________________________________________
> Noise mailing list
> 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/21d4f417/attachment.html>