Re: [tor-bugs] #17694 [Tor]: Hash PRNG output before use, so that it's not revealed to the network

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17694: Hash PRNG output before use, so that it's not revealed to the network
-------------------------+------------------------------------
 Reporter:  teor         |          Owner:
     Type:  enhancement  |         Status:  needs_information
 Priority:  Medium       |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor          |        Version:  Tor: unspecified
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
  Sponsor:               |
-------------------------+------------------------------------

Comment (by ioerror):

 Replying to [comment:6 nickm]:
 > Replying to [comment:5 ioerror]:
 > > I asked a cryptographer sitting next to me and they suggested that my
 suggested approach is reasonable. Hash the PRNG output. Or more directly:
 "Never reveal pure randomness outputs."
 >
 > Could you ask the cryptographer to jabber or IRC or email me quickly or
 something? I don't think the reasoning makes sense in this case, for a few
 of reasons:
 >
 >   1) We know what the PRNG is.

 I guess "never" was the operative word.

 >   2) OpenSSL already exposes the PRNG outputs (in ClientHello and
 ServerHello, at least), and we can't stop it from doing that without
 replacing the PRNG.

 Yes, though the question is - do we want our protocol to have the same
 mistake? I think no.

 >   3) The PRNG is under our control. The answer to a questionable PRNG
 would seem to be replacing it with a non-broken PRNG.

 We hope.

 > > For example, what happens when someone uses RDRAND internally?
 >
 > We detect attempts to replace the OpenSSL PRNG with the RDRAND engine,
 or any other engine; see #10402.
 >

 If that fails, do we fail closed or open?

 > > In theory, nothing in our stack does that; in practice, I guess that
 is incorrect. Something in the kernel, for example? Some weird OpenSSL
 builds or something?
 > >
 > > Not to say that RDRAND is backdoored but that if it was, I think a
 hash would prevent what we currently understand to be a way to exploit a
 Dual-EC like backdoor.
 >
 > It would only prevent it if openssl itself stopped exposing direct
 outputs, right?
 >

 If openssl did things correctly, I'd still suggest our protocol should not
 reveal things. An extra hash shouldn't hurt and it may mitigate issues,
 especially if our analysis were incorrect. Even if we properly prevent
 RDRAND's use with OpenSSL, if we ever get random data from the kernel, I'm
 really unsure that we can prevent *that* from using RDRAND. I guess I'd
 rather be safe than sorry and I'm not convinced I understand every aspect
 enough.

 Additionally, alternative implementations of Tor will be more fragile than
 Tor.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17694#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs