Re: [tor-dev] [prop269] Further changes to the hybrid handshake proposal (and NTor)

[bustaoglu@xxxxxxxxxxxxxxxx]

Quoting isis agora lovecruft <isis@xxxxxxxxxxxxxx>:

> Hello,
>
> 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).
>
> Changes:
>
>  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.

Hi Isis,

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  
denoted SECRET,
Does including these public values in the value SALT take care of such  
"attacks".
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?

Best

BU

--
http://cryptolounge.net

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev