[noise] Kernel-land C implementation of latest noise specification

[Trevor Perrin]

On Tue, Jul 7, 2015 at 5:18 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Wed, Jul 8, 2015 at 1:16 AM, Trevor Perrin <trevp at trevp.net> wrote:
>> OK.  I've edited the spec so the GETKEY call is done external to the
>> KDF, so you just have to define KDF to be keyed BLAKE2b.
>>
>> I don't think that loses any important generality, and it makes the
>> ciphersuite definitions simpler and less error-prone.
>
> I just looked at the commit you made. I'm pretty sure there's a
> misunderstanding.
>
> Blake2b offers a replacement for SHA2-256 in the form of:
>
> Blake2b(m) = hash
>
> Blake2b ALSO offers a replacement for HMAC-SHA2-256 in the form of:
>
> Blake2b(key, m) = hash
>
> So, I'm NOT modifying your GETKEY function -- I still use chacha20(k,
> n) for this, as you specify.

I know.


> What I'm doing, instead is replacing your usage of HMAC-SHA2-256(key,
> m) with Blake2b(key, m), and replacing your usage of SHA2-256(m) with
> Blake2b(m).
>
> Does this make sense?

Sure, I understood that.  I just edited it so that instead of asking
the KDF to call GETKEY() internally, the spec states that the input to
the KDF is GETKEY().

I.e. I removed this responsibility from the ciphersuite, since I think
allowing ciphersuites flexibility to do something different here is
more risky than helpful (they might omit GETKEY, and mistakenly use k
directly).

Seems cleaner and safer, no?


>> The fact that you're not finding the prologue useful is a concern.
>> Maybe it needs more work.
>
> What use could I have for the payload? For sending data in my VPN, I
> generally need to send two things unencrypted:
>
> - message type
> - key index parameter
>
> Then I send one big chunk encrypted:
>
> - VPN data
>
> The VPN data authenticates the two unencrypted parameters before it.
> If everything checks out, I'm set. I'm not sure what use I'd have for
> something different beyond that. I generally don't like variable
> length messages when I don't need them.

Let me think about the prologue more.


>>> At handshake initiation, I set peer.handshake.key.h to its initial
>>> value, peer.handshake.key.nonce to zero, and
>>> peer.handshake.static_public/private and peer.handshake.remote_static
>>> to the right pre-known values.
>>
>> Do you create and consume pre-messages for the pre-known static value?
>>  You want it to be hashed into h, so you shouldn't set it directly.
>
> Woooooah nelly. Good catch. So in other words, the initial value of h
> is actually HASH(HASH("Noise255-blablah") || s).
>
> But actually, this isn't possible -- we've got a catch 22 here.
> HandshakeIK's first step is "e, dhes, s, dhss", which means that when
> the responder processes it, it hashes "dhes" into "h" before it can
> even get to decrypting "s" to learn who's talking to it.

The pre-message only contains the server's static public key.  The
server knows its keypair or it couldn't process the client's first
message.  It learns the client's public key in the first message, but
that's different.

So I'm not seeing the problem?

Trevor