> > If you think that the text is useful, I'd add it as a later note.
>
> I think it is useful. What would be a "later" note?
Something attached to introductory or explanatory text, rather than a specific point in the discussion. For instance,
Keeping the details of an algorithm secret does not serve any useful purpose. At best, it means that there is another secret that you need to maintain. At worst, it denies you the expertise of other interested individuals with skills that might otherwise be applied to strengthening the algorithm.
> > > And also I would add a new assumption:
> > >
> > > Indistinguishability assumption:
>
> Up to jere it is only a definition: any protocol defines an
> indistinguishability region, there is no way to avoid it.
> (But perhaps, it is not trivial to calculate what is the
> indistinguishability region for a given algorithm). It is close to
> well known notions of indistinguishability, like
> http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
> or, even more, the one used in information flow, see for instance:
> http://www.cse.chalmers.se/~andrei/jsac.pdf
> So this is not solution space.
The indistinguishability property might be generalized as: given a set of N (chosen) plaintexts T[1], ...T[N], then any ciphertext from the set produced by the algorithm E(T[x]) cannot be identified as being produced by any of the set of plaintexts with a probability greater than 1/N.
There's two ways this principle is being applied. The most important is where the plaintext is the location of a target as a function of time. That is T is the location of the Target as it varies over time. Addressing this form of indistinguishability has to be the primary goal.
You are talking about a second case where each discrete location for the same target is treated as a separate plaintext.
The point under debate is not indistinguishability, but whether this property forms part of the attack options we wish to address (the "assumptions"). Indistinguishability is a tool for analyzing an algorithm, but not part of the set of attacks. Thus, neither part of the solution space or the set of goals, but a framework for understanding if we've achieved our goals.
If you are looking for an assumption, then we're still talking about the "frequent destination" or "same location" assumption. That is, the attacker assumes that the known location is the same as the known location that was previously acquired. The question of how much information the attacker gains when making this assumption is a matter for the analysis of the algorithm.
Incidentally, there's another assumption that's important in analyzing the algorithm that I proposed:
Discrete location assumption:
An algorithm SHOULD protect a discrete location that is remote from adjacent known locations. This assumption might be useful to an adversary if the location of the Target is known only at discrete points without known locations in between. For example, a person that disables location tracking in transit between two points might only have known locations at either end of the journey.
> > That's a more verbose version of what I intended with the second
> > paragraph. What you have described is something that is part of the
> > solution space more than the goals. I considered having an
> > additional assumption for indistinguishable locations, but it's not
> > really related to an assumption that an recipient makes, more just a
> > product of the algorithm.
>
> And this last part is the requirement. It is not solution space, it
> just says that the attacker should gain as little as possible
> information from the outputs of the algorithm.
Goal. Let us not place constraints that we cannot provably meet.
> -Jorge
As an aside, in relation to this work, I've been acutely aware of the effect of "Schneier's Law": <http://www.schneier.com/crypto-gram-1104.html#10>.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
