Re: [Tails-dev] Static Tor guards across restarts of Tails

Hi,

sajolida wrote (13 Jan 2016 11:38:11 GMT) :
> Jesse V:
> Hi Jesse, thanks for brainstorming on this.

Yay, thanks a lot!

>> However, what if Tails prompted the user for a passphase or a series of
>> words that was then used to select the Tor guards? If the user types in
>> a string X, then we can seed a PRNG with the hash of X, then use the
>> PRNG to select a set of Tor guard nodes. It's probably possible to
>> define the guards by communicating with Tor's control port, or you could
>> also write them directly into Tor's state file before starting Tor.
>>
>> For example, if the user types in "correct horse battery staple",
>> then we can run this through SHA-256, producing
>> 73fe04e5a7a16dbe16492a8773036db1646d87e22337b1c64aae0afab788b626
>> This hash then initializes the Mersenne Twister PRNG, which then
>> scrambles the list of Tor relays with the Guard flag. The first three
>> nodes are then written for Tor to use. I'm sure there's a way to weigh
>> the selection by consensus weight in the normal Tor fashion, but this
>> should basically work.
>>
>> I think it's important that a hash is used in order to mask any
>> identifiable words that are in the initial seed. It also has the
>> advantage of avoiding some of the (potential) problems with certain
>> seeds of Mersenne Twister, so I think this is a good idea in general.
>>
>> What do you guys think? Has this been proposed before?

> This looks like what has been considered in the second bullet point of
> "Discarded ideas" on this blueprint. Note that if I understand the
> blueprint correctly, it has been "discarded" as a good option for the
> entropy pool but not for the persistent Tor state.

Well, no, this is not what we meant on the blueprint. Let me explain.

What has been discarded is "requesting user input once, both to
parameterize Entry Guard selection, and for seeding the entropy pool".
The key word here is "both", as explained later in this bullet point.

However, we did not reject the idea of making Entry Guard selction
a function of some user input, quite the contrary: the "Third
iteration (low-priority)" section has provision to do so, "for people
who don't use persistence".

As stated on the blueprint, this idea is an early draft. It may be
flawed or suboptimal, and Jesse V's idea might be very useful to
improve this 3rd iteration of our plan. I'm very happy if people work
on refining this 3rd iteration. Personally, I'll try to focus on
getting the 1st and 2nd iterations implemented before I dive too
deeply into the 3rd one.

Jesse: you might be interested in reading the criticism that Patrick
Schleizer posted on this list, about our proposal for the 1st
iteration, though. I would love to get some help on this!
The corresponding thread is "Persistent Tor start in Tails vs location
aware Tor entry guards (LATEG)". I haven't had time to put much
thought into it lately, and it seems that Patrick has
a) one major concern about us OS integrators tweaking the Entry Guard
selection _at all_, that I happen to disagree with; b) at least one
possible attack scenario that is worth analyzing to see if/how it
affects our proposed design. I won't elaborate more here, since we
have an ongoing dedicated thread on this topic :)

> So, maybe you're option would be good as a fallback for when there is no
> persistent storage.

This looks like what I'm pointing to above :)

Cheers,
--
intrigeri