Nick Mathewson nickm@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 myself.

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

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 https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-fixes-n...

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

Cheers!