On 30/11/15 01:36, Ethan Heilman wrote: >> In other words, your way of interpreting the question basically ignores the >> hard problem. Of course, if you ignore the hard problem, then it's >> "possible". > > I agree with that, the hard problem is aliasing real world identities > with cryptographic ones. > > I've found, and I expect you'll disagree with me, that decomposing the > problem into "aliasing" (very hard) and encrypting (easier), helps > clarify the security requirements of particular use cases. >
Separating concerns is a good idea, I'm not sure why you think I'd disagree with you :p But then we should be clear about what we're actually achieving with the non-aliasing portion. Using cryptographic keys directly as addresses is nice, because there is less indirection. Once you have an address, you can already use it to *locate* its referent. But it doesn't improve the probability that my belief that ($address is $person) is correct. So we shouldn't use the term "self-authenticating". "Self-locating" is probably more appropriate here. (We could also argue that "it prevents UI designers from using identifiers/addresses that inherently cannot be validated against a real person", but this is different from validation itself, and not exactly a security property.) The systems I mentioned in the (c, d) points from my first post do actually improve the probability, though no-one has quantified by how much (I wish they did). Also, the paper that David Lazar posted in the other branch of this thread improves this probability, and is actually "self-validation" in the common natural-language sense of "self" and "validation", unlike other systems that call themselves "self-authenticating". X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
