id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
303	mutable-file retrieval: choose highest available version, not first-seen; read k+epsilon	warner	warner	"It is time to implement the ""epsilon"" part of mutable-file Retrieval's
k+epsilon design.

The current Retrieval code keeps asking servers in succession until it gets
enough shares (of any version) to download a complete+verified ciphertext. It
stops as soon as it gets a complete set of 'k' shares for the same version.

We're currently vulnerable to rollback attacks: both intentional (a malicious
storage server replaces the new shares with an older version, to cause the
reader to see an older version of their directory, perhaps to delete a file
that was just added), or accidental (a storage server was offline when a new
version was published, and now it's back online again). The problem is worse
with lower values of 'k'. I'd like to lower 'k' to 1 to speed up directory
lookups, but I'm concerned about the rollback problem.

To avoid this, we need three things. The first is that we must talk to more
servers than are strictly necessary: the minimum 'k' servers plus some number
'epsilon' for verification purposes. The second is that we should choose
these extra servers somewhat at random (the attacker's job is harder if they
don't know which servers they need to compromise). The third is that we
should try to return the highest version found, rather than the first version
which becomes available.

Zooko and I sketched out a refactoring of the mutable.Retrieve class that
would make this easier to implement.

(note, of course, that the dirnode lookup speed is directly related to
k+epsilon rather than just 'k', but I expect 1+epsilon to be smaller than
3+epsilon).
"	enhancement	closed	major	1.1.0	code-encoding	0.7.0	fixed	mutable