[noise] certificate chains

Arvid Picciani aep at exys.org
Sat Jun 30 15:41:56 PDT 2018


Nice, Thanks.

unfortunately i can't figure out how to use XK, because Noise of
course uses x25519 not ed25519 so the public identities for DH dont
match the identities used for signing,
I found this thread from Trevor on signing using x25519
https://moderncrypto.org/mail-archive/curves/2014/000205.html  but
there's no conclusion.

So short of any way of doing that i either have to use static keys
that are actually not static but generated on the fly and signed, or
use NN and not auth at all.
or am i missing something?




On Sat, Jun 30, 2018 at 8:11 PM, Trevor Perrin <trevp at trevp.net> wrote:
> Hi Arvid,
>
> You could also look at the "NLS" draft in the wiki:
>
> https://github.com/noiseprotocol/nls_spec/blob/rev2/output/nls.pdf
>
> This defines some protobuf structures for use in handshake payloads.
> These protobufs can negotiate "evidence blob" types and then send
> "evidence blobs".
>
> The evidence blobs could contain certificates.  We're naming them so
> generically because they might contain different types of certificates
> or signatures, or things like Certificate Transparency proofs -
> basically they should contain "evidence" for the static public key...
>
> Trevor
>
>
>
> On Sat, Jun 30, 2018 at 2:53 PM, Arvid Picciani <aep at exys.org> wrote:
>> Thanks to you both, got it working by using the payload in -> s, se
>> with XK as suggested.
>> The rest was actually nicely documented and easy to understand. Noise
>> is incredible!
>>
>> On Sat, Jun 30, 2018 at 4:16 PM, Justin Cormack
>> <justin at specialbusservice.com> wrote:
>>> You may want to include both the peer and recipient public keys in the cert,
>>> and potentially do an XK handshake. Otherwise your cert is rather broadly
>>> applicable.
>>>
>>> On Sat, 30 Jun 2018, 14:10 Marian Beermann, <public at enkore.de> wrote:
>>>>
>>>> For something like Noise_XX you'd do it like this:
>>>>
>>>> Have certificates for each peer signed by your authority. They include a
>>>> X25519/X448 public key, which is the static key used for the exchange(s).
>>>>
>>>> Do the ephemeral exchange. No extra messages here (empty payloads).
>>>>
>>>> Then, when each peer sends her public static key, the payload is her
>>>> certificate.
>>>>
>>>> Each peer verifies that (a) the public key received matches the public
>>>> key in the certificate (=a weak form of binding) (b) the certificate was
>>>> signed by the authority.
>>>>
>>>> -Marian
>>>>
>>>> On 30.06.2018 14:38, Arvid Picciani wrote:
>>>> > Could you point me at the specific things i should be careful about?
>>>> > Simply putting something like an x509 in the first message would mean
>>>> > i separate authentication from encryption.
>>>> > Leaving the safe guidance of noise by disabling part of it feels a
>>>> > little scary.
>>>> >
>>>> > On Sat, Jun 30, 2018 at 2:25 PM, Justin Cormack
>>>> > <justin at specialbusservice.com> wrote:
>>>> >> There is nothing officially defined yet, although there are mentions
>>>> >> that it may be in a future release,
>>>> >> to replace some of the DH by certs.
>>>> >>
>>>> >> However you can implement it yourself by using the extra messages in
>>>> >> the handshake to include a
>>>> >> certificate that signs the key that has been passed (in an X or I
>>>> >> handshake), and using that to validate
>>>> >> the key. You need to be a little careful about the security properties
>>>> >> of the additional messages at
>>>> >> the point where it is sent.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 30 June 2018 at 13:05, Arvid Picciani <aep at exys.org> wrote:
>>>> >>> Hi,
>>>> >>>
>>>> >>> i'm super confused if cert chains are actually possible with noise.
>>>> >>> The initial AKE seems to assume that the static keys are ALWAYS used
>>>> >>> for auth and crypto at the same time.
>>>> >>>
>>>> >>> Am i looking at this from the wrong angle here? I'm trying to figure
>>>> >>> out a way to have:
>>>> >>>
>>>> >>> - an encrypted connection from A to B
>>>> >>> - where B only knows about C
>>>> >>> - but A has obtained prior proof that C authorized A (ed25519 for
>>>> >>> example)
>>>> >>>
>>>> >>>
>>>> >>> /b/
>>>> >>> Arvid
>>>> >>> _______________________________________________
>>>> >>> 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
>>>> >
>>>>
>>>> _______________________________________________
>>>> 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


More information about the Noise mailing list