[messaging] what is the role of wrap-resistance in onion routing?
burdges at gnunet.org
Sun Oct 11 06:05:37 PDT 2015
On Sat, 2015-10-10 at 20:27 +0200, Natanael wrote:
> If the router successfully decrypts it, it may or may not recognize
> the packet and thus respond in a way that's usable as an oracle,
> revealing if this packet did once pass through this node or not.
> If it for example has replay resistance, a timing attack may reveal
> of the router either don't understand the packet or if it knows what
> tunnel it belongs to and knows that's a duplicate.
If I understand, the attack is : If Eve sees Bob received a message,
then Eve can try to wrap that message as if it came from every mix node
that recently contacted Bob. Are all these rewrapped messages from
different nodes identical to Bob? If so, then Bob treats them all as
replays, and Eve learns nothing. If not, then Eve could learn the
previous mixnet hop from Bob's CPU activity.
What about the "naive onion" mixnet where when a node peals off a layer
of the onion it finds merely an address for the next hop and a blob
encrypted for that hop? This does not have wrap-resistance since I can
trivially put it in another blob destined for someone else. It should
have replay protection through key rotation and a Bloom filter, but
nothing fancy like circuits. Yet, it does not appear to be vulnerable
to any wrap-resistance connected attack that I know.
I think what naive onion lacks is any linkage between the previous hop
and the current one. Is that a problem for some reason?
Or maybe wrap-resistance is stated too strongly? It should perhaps say
that an adversary should not gain information based on how rewrapping
packets in different ways.
p.s. There are mixnet schemes based on universal reencryption that
lack wrap-resistance without overly falling victim to this attack
either, similarly to naive onion. I should read the Crowds  and
Hords  papers today, maybe they lack wrap-resistance too.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging