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

[Trevor Perrin]

On Tue, Jul 7, 2015 at 2:11 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Tue, Jul 7, 2015 at 10:00 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> This is just a different ciphersuite, where you define a BLAKE2b-based
>> KDF and HASH?
>
> Yes. HASH(h) = Blake2b_hash(h) and KDF(k, n, input) =
> Blake2b_keyedhash(GETKEY(k, n), input).

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.


>> The timestamp is just included in the payload, I hope?
>
> I guess. It's the last encrypted thing that's read from the initial
> handshake packet. That function works as:
>
> 1. Read clear e
> 2. Compute dhes and call kdf
> 3. Read encrypted s
> 4. Compute dhss and call kdf
> 5. Read encrypted t
[...]
> So it's in the payload, in so far as you consider the payload to be
> the last encrypted thing in the message.

Yep, that's the payload.  Cool.


>> So how do you handle the prologue?  Did you remove it, or do you just
>> assume its zero-length?
>
> There's not exactly a prologue anymore. Every packet has a header.
> This header is simply this:
>
> struct noise_message_header {
>    u8 type;
> } __attribute__((packed));
>
> And the type is one of these:
>
> enum noise_message_type {
>    NOISE_MESSAGE_INVALID = 0,
>    NOISE_MESSAGE_HANDSHAKE_INITIATION = 1,
>    NOISE_MESSAGE_HANDSHAKE_RESPONSE = 2,
>    NOISE_MESSAGE_DATA = 3,
>    NOISE_MESSAGE_TOTAL = 4
> };

The fact that you're not finding the prologue useful is a concern.
Maybe it needs more work.


> 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.


> Any feedback on the general code and implementation? I'm all ears and
> would love some criticism.

Honestly I'm not going to pore over the code too much, I'm mainly
interested in lessons learned about the spec - what are rough spots,
confusing points, what else is needed, etc.


Trevor