Hi,
> I think unlinkability is stronger than anonymity( " An attacker might get to > know > information on linkability of various messages while not necessarily > reducing anonymity of the particular subject. ") > so anonymity is the basic requirement for privacy protection? I think it is more complicated than that. Some thoughts on the subject: - I believe Iinkability eventually leads to a degradation of anonymity. In fact, if actions / messages / transactions are linkable, I would say there is no anonymity, but rather "pseudonymity" (one can give a name or number to the set of transactions which acts as a pseudonym for the user). - I do not think one can talk of a "basic requirement" for privacy protection in general. Each case must be studied individually in order to see: how do we define a privacy breach in the context of the application, what is the threat model, how do the requirements translate to technical properties, etc. - I also think that one can distinguish (at least) two basic mechanisms for privacy protection (which can also be combined): 1) anonymity: the actions are known (eg, which web page is downloaded) and the identity is concealed. 2) PIR/OT approach: the identity is known but the action is concealed (eg, I know you are accessing a record in my database, but I do not know which record it is). Best, Claudia On 10 Feb 2012, at 02:44:20, [email protected] wrote: > > Hannes Tschofenig <[email protected]> 写于 2012-02-09 16:53:01: > > > > Anyway, I believe that anonymity isn't the right term for that > > document when the privacy threat is focused on the HIP responder > > getting to know the host identities. The HIP responder receives the > > HITs in the exchange. > > > > The only form of protection the document seems to provide is the > > usage of pseudonyms. A HI itself is already a pseudonym (based on > > the definition of a pseudonym in the document) and the main question > > here is about linkability and about the lifetime of these > > pseudonyms. We could, for example, regularly re-compute a new HI and > > use it. This may be computationally more expensive but would provide > > some level of protection. The problem only shows up in relationship > > to other usages of the HI, for example, for access control. In the > > draft this blinded HIT is used that is essentially derived from the > > original HiT (and consequently from the HI). An attacker may not > > able to learn the original HIT (or HI) but may still be able to make > > the individual protocol runs linkable to each other. Note that this > > mechanism has often been provided by other protocols as well (see > > all the network access authentication protocols). > > I think unlinkability is stronger than anonymity( " An attacker might get to > know > information on linkability of various messages while not necessarily > reducing anonymity of the particular subject. ") > so anonymity is the basic requirement for privacy protection? > > > > > Btw, where did you got this anonymity definition from that you cite > > below? I don't think it is particularly good. Imagine that you have > > a VoIP service offering that only has two users, you and me. If an > > adversary eavesdrops on the communication it may not find out > > whether it is you or me (without using further information) but > > that's a pretty bad privacy protection. Instead, it would be much > > better if the anonymity set is much larger. > > I got the definition of anonymity in P10 [in Foundations of Group > Signatures: The Case of Dynamic Groups > http://www-cse.ucsd.edu/~mihir/papers/dgs.html] > > > Ciao > > Hannes > > > > PS: It may turn out to be useful to add another term to the document > > to express the common property of hiding the identity of the > > initiator to eavesdroppers, such as "initiator identity confidentiality". > > or as a special case of anonymity? > > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy -------------------------------------------------------------------------- Prof. Dr. Ir. Claudia Diaz Katholieke Universiteit Leuven Dept. Electrical Engineering-ESAT / COSIC Kasteelpark Arenberg 10, B-3001 Leuven, BELGIUM tel: +32 16 32 18 14 fax: +32 16 32 19 69 email: claudia.diaz (at) esat.kuleuven.be web: http://homes.esat.kuleuven.be/~cdiaz/ -------------------------------------------------------------------------- _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
