[tor-bugs] #7202 [Tor]: Implement ntor handshake or its successor

[Tor Bug Tracker & Wiki]

#7202: Implement ntor handshake or its successor
--------------------------------+-------------------------------------------
 Reporter:  karsten             |          Owner:                    
     Type:  project             |         Status:  needs_review      
 Priority:  normal              |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                 |        Version:                    
 Keywords:  SponsorZ tor-relay  |         Parent:                    
   Points:                      |   Actualpoints:                    
--------------------------------+-------------------------------------------

Comment(by andrea):

 Replying to [comment:28 nickm]:
 > I expect it to have typical size of 1 or 2. In the future I could
 conceive of 3 or 4, but if we ever needed it for something big, we'd want
 to reimplement.

 Okay, no problem then. :)

 > Yup.  It's currently synchronized with Adam's code; I expect to keep it
 that way.

 Okay.

 > A router's onion key is a one-per-router value as far as any client
 knows, but it servers want to rotate them sometimes.  When they do this,
 they need the old key to keep working for a while.

 Okay.

 > I believe I'm just being paranoid there, for values of paranoia less
 like "everything is trying to get me" and more like "let's engineer this a
 little better than we think we need to, in case there's some circumstance
 I'm not thinking of that makes this less safe than it appears."

 Right :)

 > I think rransom's answer here is right; I think that most of the stuff
 in the secret_input/auth_input parts of the ntor protocol are there on the
 theory that you're not going to regret having more part of the protocol
 get checked.

 Okay, thanks.  I'll find the paper and read it, I think.

 > See rransom's answer here.  As discussed above, I don't believe that
 checking for all zeros output or other checks is necessary for curve25519
 either.

 Okay.

 > So, crypto_rand() just uses the OpenSSL RNG; crypto_strongest_rand()
 uses the OpenSSL RNG *and* the platform RNG.  It's only used to generate
 the medium-term onion keys, not the ephemeral keys.  So even if "consuming
 OS entropy" were something we worried about, we'd only be using it for the
 onion keys, which aren't made once-per-handshake unless I seriously
 screwed up.

 Right, okay.

 > The traditional rationale behind tracking how much entropy is "in" a
 cryptographic PRNG is to distinguish whether you're getting an
 information-theoretic kind of security (i.o.w, "short of a defect in the
 entropy source, you'd need sorcery to break this") or "merely"
 cryptographic security (i.o.w., "you could also break this if there's a
 defect in the PRNG algorithm.")  But rransom is correct that the right
 answer to a suspect PRNG is pretty much always "Get a better PRNG", unless
 you're trying to use /dev/random to make a one-time-pad or something,
 which we aren't.

 Mmm.

 > Also, it *would be* a bit rude to read huge amounts of data from the OS
 RNG, since even if we don't believe in blocking on entropy, some other
 programs do, and it's a bit rude to punish users who want to use programs
 like that.

 Yeah.

 > > This CREATE2-inside-CREATE business in
 89e3dd8c3029e2319466fb47f33d31b76c870008 isn't in the proposal.  Is it
 going to get into the spec properly?
 >
 > It's in the last paragraph of "Integrating with the rest of Tor" in
 proposal 216.

 Okay, sorry.

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