Support more stable guards for live CDs

[nickm]

Since livecd environments don't have persistent storage across sessions, they can't keep guard nodes across, and as such don't get the benefit from them.

This may be fixable. Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed". Or the user could run a small program before burning the cd that sets a random seed on the disk. The Tor client could then be configured to pick its guards based on the seed. This would give the user similar guards across invocations, to avoid guard churn.

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

A better design and a Proposal are probably needed. Posting this here so we don't lose track of it entirely.

(rransom helped develop this idea.)

[rransom]

Replying to nickm:

Since livecd environments don't have persistent storage across sessions, they can't keep guard nodes across, and as such don't get the benefit from them.

This may be fixable. Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed". Or the user could run a small program before burning the cd that sets a random seed on the disk. The Tor client could then be configured to pick its guards based on the seed. This would give the user similar guards across invocations, to avoid guard churn.

We really need the 'guard selection seed' to have enough entropy to be unpredictable to attackers. Otherwise, an attacker can guess a user's seed and choose a relay's identity key so that it will become one of the user's guard nodes at some time in the future.

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

We can do weighting by computing H(GuardID | 0), H(GuardID | 1), ..., H(GuardID | GuardWeight - 1) for each guard, and then choosing the closest guard to H(Seed | 0), the closest not-yet-chosen guard to H(Seed | 1), and so on.

Further improvements are needed to make GuardIDs seed-dependent, make each guard's GuardID change at pseudo-random times, and possibly make each guard-selection value (the H(Seed | i) above) change at pseudo-random times as well.

[nickm]

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed. I'm not sure how to best do that, though.

[rransom]

Replying to nickm:

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed. I'm not sure how to best do that, though.

CPRM? No, they'll never let us use that for anything useful.

I don't think we can use an extra track, either -- most VMs (which need extra persistent entropy the most) won't support it, and live-CD developers would need to ship a customized CD-burning tool for each platform their users might download the CD with in order to create the CDs on bare metal.

It's easiest to create a 'personalized CD' by clobbering a designated 2048-byte sector of the ISO with random bits after downloading it, and interpreting the all-zero value in the original (as-downloaded) ISO as an instruction to extract entropy from the host system's hardware.

[nickm]

That does imply the existence of a cross-platform customized ISO-clobbering tool. Possibly worthwhile, though, and probably much easier to write portably than a plugin for every CD-creation scripting tool.

[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.))

[proper]

Replying to nickm:

Hm. An extra track on the livecd, full of random bits, would be a great way to do a seed.

I guess some people will use it to store encrypted data to have Plausible Deniability [1] [2] [3] An adversary could claim that it contains encrypted data.

Not saying this is bad. Just something to consider.

[1] ​http://www.truecrypt.org/docs/?s=plausible-deniability
[2] ​http://www.cypherpunks.ca/otr/
[3] ​https://en.wikipedia.org/wiki/Plausible_deniability

[proper]

Suppose that the livecd gathers a set of system hardware information (MAC address, PCI stuff, etc), and hashes it into a "Guard Seed".

When they want to keep supporting virtual machines, they need something else for that use case. (Most) virtual machines share system hardware information, except virtual MAC and machine id.

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.

This sounds nice. Adds most flexibility.

It has the disadvantage of one more thing for users to remember

If it gets hashed, couldn't they use the same password they are using for encryption as well?

[rransom]

Replying to rransom:

One (approximate) solution is to pick guard nodes based on the first N nodes sorted by H(Seed|NodeID). This doesn't do weighting correctly, though.

We can do weighting by computing H(GuardID | 0), H(GuardID | 1), ..., H(GuardID | GuardWeight - 1) for each guard, and then choosing the closest guard to H(Seed | 0), the closest not-yet-chosen guard to H(Seed | 1), and so on.

Further improvements are needed to make GuardIDs seed-dependent, make each guard's GuardID change at pseudo-random times, and possibly make each guard-selection value (the H(Seed | i) above) change at pseudo-random times as well.

‘Simultaneous rational approximation’ of the selection-probability distribution might make the performance of this technique somewhat less horrific.

[rransom]

Section 4.2 (‘Encoding a message M as B_M’) of ​https://eprint.iacr.org/2010/446 might be useful.

[nickm]

not currently a design plan; but fallbacks help some here.

It's more and more apparent that a persistent datadirectory is a really good idea.