prop289: randomize the unused part of relay payloads

arma says: I think this logic argues for another subticket on #26288 (moved): "randomize the unused part of relay payloads".

https://trac.torproject.org/projects/tor/ticket/26846#comment:4

changed milestone to %Tor: 0.4.1.x-final

added 035-roadmap-master 035-triaged-in-20180711 041-proposed-on-roadmap component::core tor/tor milestone::Tor: 0.4.1.x-final owner::dgoulet parent::26288 priority::medium prop289 prop289-assigned-sponsor-v resolution::fixed severity::normal sponsor::V status::closed type::enhancement labels

Trac:
Status: new to assigned
Owner: N/A to dgoulet
Type: defect to enhancement

My task26871 branch shows where we would make this change. If we like it, it still needs unit tests, changes entry, etc.

I thought about breaking out the memcpy and the crypto_rand into their own function, called something like relay_payload_pack(), but all the extra lines didn't seem worth it.

I hope our PRNG is cheap.

Here's an attack on exits with expensive PRNGs:

• make a client you control connect to a site you control
• feed the exit one byte at a time

The exit then creates ~500 bytes of random padding per byte sent by the remote site. (This would be a devastating attack if we used /dev/random directly, on an OS that thinks entropy is subtractive, like Linux.)

Replying to teor:

Here's an attack on exits with expensive PRNGs:

(a) don't just worry about exits; clients also will fill relay payloads.

(b) if this is actually a practical issue, I could get behind a design where we randomize only the first byte of the unused part of the relay payload. That would serve my purposes. But I bet we'd be forever explaining to people why we cut that corner.

(c) For added efficiency, let's only sometimes randomize that first byte. We can flip a coin to figure out whether we will, thus saving the prng that extra call to -- oh. :)

Replying to arma:

Replying to teor:

Here's an attack on exits with expensive PRNGs:

FWIW, OpenSSL's old PRNG is exceptionally slow, but the newer one isn't too bad. LibreSSL is reasonably fast, and so is NSS IIRC.

If we need to get a faster PRNG, we have a couple of designs ready to go, with code.

Replying to arma:

(c) For added efficiency, let's only sometimes randomize that first byte. We can flip a coin to figure out whether we will, thus saving the prng that extra call to -- oh. :)

At this point, you might as well use a cheap sponge construction.

I patched tor-spec to randomise relay cell padding, see:

https://trac.torproject.org/projects/tor/ticket/26228#comment:15

Replying to teor:

I patched tor-spec to randomise relay cell padding, see:

https://trac.torproject.org/projects/tor/ticket/26228#comment:15

Now tracking all of #26228 (moved), #26870 (moved), #26871 (moved) in this pull request: https://github.com/torproject/torspec/pull/28

EDIT: only the tor-spec part of #26871 (moved) is tracked here.

Replying to arma:

My task26871 branch shows where we would make this change. If we like it, it still needs unit tests, changes entry, etc.

I thought about breaking out the memcpy and the crypto_rand into their own function, called something like relay_payload_pack(), but all the extra lines didn't seem worth it.

Trac:
Status: assigned to needs_revision

I think all prop#289 tickets are Sponsor V.

Trac:
Sponsor: N/A to SponsorV
Keywords: N/A deleted, prop289-assigned-sponsor-v added

I've squashed and merged the spec branch.

Deferring prop289 work to 036

Trac:
Milestone: Tor: 0.3.5.x-final to Tor: 0.3.6.x-final

What is the needed revision here? Randomize some bytes? Use faster RNG? ...

Here are the revisions that are needed:

Replying to teor:

Replying to arma:

My task26871 branch shows where we would make this change. If we like it, it still needs unit tests, changes entry, etc.

Here are the revisions we probably don't need:

I thought about breaking out the memcpy and the crypto_rand into their own function, called something like relay_payload_pack(), but all the extra lines didn't seem worth it.

Tor 0.3.6.x has been renamed to 0.4.0.x.

Trac:
Milestone: Tor: 0.3.6.x-final to Tor: 0.4.0.x-final

prop289 won't make it in 040. Feature freeze is in 7 days.

Trac:
Milestone: Tor: 0.4.0.x-final to Tor: 0.4.1.x-final

Let's review these tickets at the next meeting using our 041-proposed process. They're on the roadmap, so the review should focus on ticket size and team capacity (and sponsor expectations).

Trac:
Keywords: N/A deleted, 041-proposed-on-roadmap added

With the fast prng, this is done in the parent ticket.

Trac:
Status: needs_revision to closed
Resolution: N/A to fixed