[tor-dev] Comments on proposal 224 updates

George Kadianakis desnacked at riseup.net
Thu Apr 14 10:39:07 UTC 2016

Nick Mathewson <nickm at torproject.org> writes:

> [ text/plain ]
> I'm behind on this!  But let me comment on the stuff that got merged recently.

Thanks for the comments!

Please see my branch `prop224-fixes-nickm` for the corresponding fixes.

Feel free to merge it in torspec.git if you feel like it, otherwise I can do it

>     "prop224: Remove the MAINT_INTRO feature."
>     "prop224: Clarify backwards compatibility sections slightly."
>     "prop224: Clarify use of shared random values."
>     "prop224: Fix undefined variables in the ntor section."
> Looks ok.
>     "prop224: Add missing key expansion section for rendezvous crypto."
> KDF-Tor is a legacy algorithm, and we want to get away from SHA1. We
> don't use KDF-Tor with NTOR. Let's kill it for new use. I'd suggest
> HKDF-SHA256 or SHAKE, both of which we have implemented already.

Fixed in
  https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-fixes-nickm&id=f2cfab04187e593b9ec28a7ebd95e674510ccbab .

I'm now using our KDF (i.e. SHAKE256) for the key expansion there.

We don't have a salt value to use for that key expansion, but I think that's OK
because NTOR_KEY_SEED is the result of ntor so it should be unique.

I also changed the interface of our KDF to KDF(m,d) to match the interface of SHAKE256(m,d).

>    "prop224: In cells, replace TYPE/LEN/KEY with just TYPE/KEY."
> I'm not sure about this change.  If we ever add a third key type, all
> of the cells will be unparseable.

Fixed in

>    "prop224: Various improvements."
> There's no point in using HKDF with SHAKE; we should just use SHAKE as the KDF.

Fixed in the crypto commit as well.

Let me know if something is not right and I will fix it up.


More information about the tor-dev mailing list