[tor-bugs] #10893 [Pluggable transport]: ScrambleSuit spec improvements

[Tor Bug Tracker & Wiki]

#10893: ScrambleSuit spec improvements
-------------------------------------+-------------------------------
     Reporter:  yawning              |      Owner:  phw
         Type:  defect               |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  scramblesuit spec
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-------------------------------

Comment (by phw):

 I created the branch `10893` to work on the issues:
 https://gitweb.torproject.org/user/phw/scramblesuit.git/shortlog/refs/heads/bug_10893.

 Replying to [ticket:10893 yawning]:
 >  * The spec lies about the contents of MAC for the UniformDH handshake.
 >    Instead of "MAC(X | P_C | E)"/"MAC(X | P_S | E)" this should be
 "MAC(X | P_C | M_C | E)"/"MAC(Y | P_S | M_S | E)".  The mark is part of
 the HMAC verifier, and for the server's MAC, the server's UniformDH key is
 used when computing the digest.

 Thanks, fixed.

 >  * Should the server echo the epoch received from the client?  The
 server should attempt to verify the client's identifier with E - 1 or E +
 1 and E, and it implicitly knows the E value the client sent, so it should
 echo it.  Or the client could also verify more than 1 MAC.

 The main purpose of E is to keep the server's replay cache small.  Since
 the client does not maintain a replay cache, E could simply be echoed by
 the server.  In fact, it might even be discarded altogether but that would
 break compatibility with old protocol versions.

 And yes, the server should also check E-1 or E+1 to prevent the occasional
 authentication failure when an hour wraps.

 >  * What happens when the random padding contains the mark?  Should the
 client/server continue to scan for the MAC, or just fail the connection
 (The odds of this happening are *extremely unlikely* so failing it is
 probably fine).

 I agree that that failing is OK.  Everything else would just add
 complexity.

 > Things that are totally missing:
 >  * The Protocol Polymorphism PRNG needs to be documented.

 Yes.  I'm somewhat limited by PyCrypto's CSPRNG API (or lack thereof) but
 I will come up with something.  So far, I'm using a Mersenne Twister but a
 CSPRNG is certainly a better choice.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10893#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online