Quoting isis agora lovecruft <i...@torproject.org>:
After discussion with John Schanck and Trevor Perrin over the last month,
we've decided to make some alterations to the specification for hybrid
handshakes in Tor proposal #269.
It seems that John, Trevor, and I are mostly in agreement about most
of the construction.
First, I'll try to summarise a list of changes and the reasoning/concerns
which provoked them. For what it's worth, these concerns mostly involve
highly theoretical problems surrounding whether we model a hash function with
a random oracle or try to make some stronger claims to its properties, and
aren't due to any real world attacks (assuming that hash functions do what
you'd expect them to do and aren't something crazy like a NULL op or a
pineapple slicing machine).
1. [NTOR] Inputs to HKDF-extract(SALT, SECRET) which are not secret
(e.g. server identity ID, and public keys A, X, Y) are now removed from
SECRET and instead placed in the SALT.
Reasoning: *Only* secret data should be placed into the HKDF extractor,
and public data should not be mixed into whatever entropic material is
used for key generation. This eliminates a theoretical attack in which
the server chooses its public material in such a way as to bias the
entropy extraction. This isn't reasonably assumed to be possible in a
"hash functions aren't probablistically pineapple slicers" world.
Perhaps my question is related to Michaels question, but above removing A, X,
Y and server ID leaves the possibility of a person-in-the-middle who by
manipulating public keys (resend 2A, instead of A, 2X instead of X, 2Y instead
of Y) can force two (non-matching) session share the same value
Does including these public values in the value SALT take care of such
RFC5869 Section 3.3 To Skip or not to Skip addresses that part, but I can't
conciliate your statement that the server can choose its public material in
a way to bias the entropy extractor. Or is this simply the same problem viewed
from a different angle?
tor-dev mailing list