<div dir="auto">If you need the signature keys to match, then one option might be to use a one way Noise message of type K (or X) from the the guarantor to the recipient which contains the initiators public key. The recipient can then decrypt this, check or validate it is from the right party and that it decrypts to the right public key. It is a bit longer than a signature but uses the same keys.</div><br><div class="gmail_quote"><div dir="ltr">On Sat, 30 Jun 2018, 23:41 Arvid Picciani, <<a href="mailto:aep@exys.org">aep@exys.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nice, Thanks.<br>
<br>
unfortunately i can't figure out how to use XK, because Noise of<br>
course uses x25519 not ed25519 so the public identities for DH dont<br>
match the identities used for signing,<br>
I found this thread from Trevor on signing using x25519<br>
<a href="https://moderncrypto.org/mail-archive/curves/2014/000205.html" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mail-archive/curves/2014/000205.html</a>  but<br>
there's no conclusion.<br>
<br>
So short of any way of doing that i either have to use static keys<br>
that are actually not static but generated on the fly and signed, or<br>
use NN and not auth at all.<br>
or am i missing something?<br>
<br>
<br>
<br>
<br>
On Sat, Jun 30, 2018 at 8:11 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank" rel="noreferrer">trevp@trevp.net</a>> wrote:<br>
> Hi Arvid,<br>
><br>
> You could also look at the "NLS" draft in the wiki:<br>
><br>
> <a href="https://github.com/noiseprotocol/nls_spec/blob/rev2/output/nls.pdf" rel="noreferrer noreferrer" target="_blank">https://github.com/noiseprotocol/nls_spec/blob/rev2/output/nls.pdf</a><br>
><br>
> This defines some protobuf structures for use in handshake payloads.<br>
> These protobufs can negotiate "evidence blob" types and then send<br>
> "evidence blobs".<br>
><br>
> The evidence blobs could contain certificates.  We're naming them so<br>
> generically because they might contain different types of certificates<br>
> or signatures, or things like Certificate Transparency proofs -<br>
> basically they should contain "evidence" for the static public key...<br>
><br>
> Trevor<br>
><br>
><br>
><br>
> On Sat, Jun 30, 2018 at 2:53 PM, Arvid Picciani <<a href="mailto:aep@exys.org" target="_blank" rel="noreferrer">aep@exys.org</a>> wrote:<br>
>> Thanks to you both, got it working by using the payload in -> s, se<br>
>> with XK as suggested.<br>
>> The rest was actually nicely documented and easy to understand. Noise<br>
>> is incredible!<br>
>><br>
>> On Sat, Jun 30, 2018 at 4:16 PM, Justin Cormack<br>
>> <<a href="mailto:justin@specialbusservice.com" target="_blank" rel="noreferrer">justin@specialbusservice.com</a>> wrote:<br>
>>> You may want to include both the peer and recipient public keys in the cert,<br>
>>> and potentially do an XK handshake. Otherwise your cert is rather broadly<br>
>>> applicable.<br>
>>><br>
>>> On Sat, 30 Jun 2018, 14:10 Marian Beermann, <<a href="mailto:public@enkore.de" target="_blank" rel="noreferrer">public@enkore.de</a>> wrote:<br>
>>>><br>
>>>> For something like Noise_XX you'd do it like this:<br>
>>>><br>
>>>> Have certificates for each peer signed by your authority. They include a<br>
>>>> X25519/X448 public key, which is the static key used for the exchange(s).<br>
>>>><br>
>>>> Do the ephemeral exchange. No extra messages here (empty payloads).<br>
>>>><br>
>>>> Then, when each peer sends her public static key, the payload is her<br>
>>>> certificate.<br>
>>>><br>
>>>> Each peer verifies that (a) the public key received matches the public<br>
>>>> key in the certificate (=a weak form of binding) (b) the certificate was<br>
>>>> signed by the authority.<br>
>>>><br>
>>>> -Marian<br>
>>>><br>
>>>> On 30.06.2018 14:38, Arvid Picciani wrote:<br>
>>>> > Could you point me at the specific things i should be careful about?<br>
>>>> > Simply putting something like an x509 in the first message would mean<br>
>>>> > i separate authentication from encryption.<br>
>>>> > Leaving the safe guidance of noise by disabling part of it feels a<br>
>>>> > little scary.<br>
>>>> ><br>
>>>> > On Sat, Jun 30, 2018 at 2:25 PM, Justin Cormack<br>
>>>> > <<a href="mailto:justin@specialbusservice.com" target="_blank" rel="noreferrer">justin@specialbusservice.com</a>> wrote:<br>
>>>> >> There is nothing officially defined yet, although there are mentions<br>
>>>> >> that it may be in a future release,<br>
>>>> >> to replace some of the DH by certs.<br>
>>>> >><br>
>>>> >> However you can implement it yourself by using the extra messages in<br>
>>>> >> the handshake to include a<br>
>>>> >> certificate that signs the key that has been passed (in an X or I<br>
>>>> >> handshake), and using that to validate<br>
>>>> >> the key. You need to be a little careful about the security properties<br>
>>>> >> of the additional messages at<br>
>>>> >> the point where it is sent.<br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >> On 30 June 2018 at 13:05, Arvid Picciani <<a href="mailto:aep@exys.org" target="_blank" rel="noreferrer">aep@exys.org</a>> wrote:<br>
>>>> >>> Hi,<br>
>>>> >>><br>
>>>> >>> i'm super confused if cert chains are actually possible with noise.<br>
>>>> >>> The initial AKE seems to assume that the static keys are ALWAYS used<br>
>>>> >>> for auth and crypto at the same time.<br>
>>>> >>><br>
>>>> >>> Am i looking at this from the wrong angle here? I'm trying to figure<br>
>>>> >>> out a way to have:<br>
>>>> >>><br>
>>>> >>> - an encrypted connection from A to B<br>
>>>> >>> - where B only knows about C<br>
>>>> >>> - but A has obtained prior proof that C authorized A (ed25519 for<br>
>>>> >>> example)<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> /b/<br>
>>>> >>> Arvid<br>
>>>> >>> _______________________________________________<br>
>>>> >>> Noise mailing list<br>
>>>> >>> <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a><br>
>>>> >>> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
>>>> > _______________________________________________<br>
>>>> > Noise mailing list<br>
>>>> > <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a><br>
>>>> > <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
>>>> ><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Noise mailing list<br>
>>>> <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a><br>
>>>> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
>> _______________________________________________<br>
>> Noise mailing list<br>
>> <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a><br>
>> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div>