[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2653 [Tor Client]: Support more stable guards for live CDs
#2653: Support more stable guards for live CDs
-------------------------+--------------------------------------------------
Reporter: nickm | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Tor: unspecified
Component: Tor Client | Version:
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by cypherpunks):
Just to get the comment down, this will be useful in some environments. It
also could make things worse. We introduced guards as a trade-off, but it
can become a different trade-off specifically in environments where
liveCDs matter most. The most obvious one is that the liveCD will now have
something persistent that ties it to a signature of network behavior.
Without guards, someone who uses a livecd at various cybercafes is not as
easily linkable to behavior. With guards if you are grabbed with that
particular liveCD and the adversary (e.g., from running middleman nodes
and hostile or observed destinations) associates that guard set (hence
that liveCD) with specific past behavior of interest. The only point is to
note that having guards at all burned into the liveCD. It should be easy
to think of lots of other threat scenarios, but I'd have to think about
how likely/dangerous they are to say anything reasonable about tradeoffs.
Right now my point is just: adding guards is not necessarily a good thing.
One thing to help at least specifically for the above scenario would be to
add a pin/password to be typed at runtime that, when fed into the 'guard
generator' is reasonably likely to take you to an adequate amount of the
guard space. (Shades of Janus/LPWA/proxymate.) This has the advantage of
making it easy to change gaurds or keep them as needed. It has the
disadvantage of one more thing for users to remember or store and
rubberhose cryptanalysis vulnerability etc. It might also be useful to
glance at "Temporarily hidden bit commitment and lottery applications" to
think about the shape of the guard space and the potential for various
spatial attacks on this idea.
(Hey my first tracticket comment. Wait oh no I can't get sucked in to even
one more thing. -Paul (Nick knew it was me anyway.))
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2653#comment:5>
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