[tor-bugs] #22948 [Core Tor/Tor]: Padding, Keepalive and Drop cells should have random payloads

[Tor Bug Tracker & Wiki]

#22948: Padding, Keepalive and Drop cells should have random payloads
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  isis
     Type:  defect                               |         Status:
                                                 |  accepted
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, 034-triage-20180328,       |  Actual Points:
  034-removed-20180328                           |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by cypherpunks):

 Replying to [comment:4 teor]:
 > Does it make it harder for adversaries to decrypt them?
 > (If so, should we fill every cell with random data rather than zeroes?

 If AES is a perfect PRP, then padding adds no additional protections.

 Theoretically, yes. Tor uses AES in CTR mode, which means that known
 plaintext allows an adversary to discover the keystream. While this alone
 is not an issue, the fact that Tor initializes CTR with a zero nonce
 (something I find a little silly) means that the diffusion from the key is
 reduced. This could, in theory, make a hypothetical future key-recovery
 attack against AES a little easier to mount against Tor connections.

 Assuming the padding is generated with the same CSPRNG as the keystream
 for link encryption, there will not be a huge benefit. The padding would
 be something along the lines of:

 {{{
 C_i = E_k(i + 1) ⊕ E_k(i)
 }}}

 Whereas padding with zeros is equivalent to:

 {{{
 C_i = E_k(i)
 }}}

 And regular encryption of plaintext ''P'' is:

 {{{
 C_i = P_i ⊕ E_k(i)
 }}}

 For ciphertext ''C'', plaintext ''P'', block cipher ''E'', key ''k'', and
 counter ''i''.

 > On the other hand, are we worried that implementations with low quality
 PRNGs will leak state by doing this?

 You would need a ''really'' bad PRNG for that to be an issue. As in, one
 that is so bad that statistical analysis of the ciphertext could lead to
 key recovery (after all, CTR mode is nothing more than PRNG output being
 XORed with the plaintext). If we are using something that bad, we have far
 worse problems.

 My ''personal'' opinion is that the cells should use random padding, as
 long as it's cheap.

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