[noise] [Noise] Go implementation

[Trevor Perrin]

On Sun, Jul 6, 2014 at 1:12 PM, Jonathan Rudenberg
<jonathan at titanous.com> wrote:
> On Jul 6, 2014, at 12:45 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> The KDF logic in your deriveKey() could be clearer.
>
> I refactored it a bit last night:
>
> https://github.com/titanous/noise/blob/84c8891ca786088286cf2461d4237a0de5da2b9e/box/box.go#L172-L175
>
> Is there anything specific that you think would make it clearer? It’s probably a bit more complex than it needs to be because I’m also using this implementation as an excuse to golf memory allocations in Go.

Looks better, but I think the extra and info are reversed.


>> Also, KDFNum is just a uint8
>
> Ah, that makes way more sense. Maybe annotate it as (byte)kdf_num to make that more clear?

Ah, my fault... the type for that got lost, added it back.


> https://github.com/titanous/noise/commit/84c8891ca786088286cf2461d4237a0de5da2b9e
>
>> and I think incrementing it every time won't work if the
>> Crypter is reused, maybe the spec should be clearer on kdf_num in some
>> way...
>
> I’m also saving cv and cc in the Crypter. I’ve started implementing pipes, I’ll see how explicitly passing the state around vs keeping it in the Crypter struct feels. There might also be some middle ground…
>
> BTW, why does kdf_num start at 2 for pipes?

kdf_num is not actually state or a counter, it's just so every
different use of the KDF gives completely different results, even if
passed the same input.  Which helps the security analysis.  I added
more comments last night, see if that helps explain, or if there's
something else we can do to clarify.


Trevor