On Sep 7, 2013, at 11:06 PM, Christian Huitema wrote:

>> Pairwise shared secrets are just about the only thing that scales worse than 
>> public key distribution by way of PGP key fingerprints on business cards.  > 
>> The equivalent of CAs in an all-symmetric world is KDCs....  If we want 
>> secure crypto that can be used by everyone, with minimal trust, public key 
>> is the only way to do it.  
> 
> I am certainly not going to advocate Internet-scale KDC. But what if the 
> application does not need to scale more than a "network of friends?"
Indeed, that was exactly what I had in mind when I suggested we might want to 
do without private key cryptography on another stream.

Not every problem needs to be solved on Internet scale.  In designing and 
building cryptographic systems simplicity of design, limitation to purpose, and 
humility are usually more important the universality.  Most of the email 
conversations I have are with people I've corresponded with in the past, or 
somehow related to people I've corresponded with in the past.  In the first 
case, I already have their keys - the only really meaningful notion of "the 
right key" is key continuity (combined with implied verification if we also 
have other channels of communication - if someone manages to slip me a bogus 
key for someone who I talk to every day, I'm going to figure that out very 
quickly.)  In the second case - e.g., an email address from a From field in a 
message on this list - the best I can possibly hope for initially is that I can 
be certain I'm corresponding with whoever sent that message to the list.  
There's no way I can bind that to a particular person in the real world wit
 hout something more.

Universal schemes, when (not if - there's no a single widely fielded system 
that hasn't been found to have serious bugs over its operation lifetime, and I 
don't expect to see one in *my* lifetime) they fail, lead to universal attacks. 
 I need some kind of universal scheme for setting up secure connections to buy 
something from a vendor I never used before, but frankly the NSA doesn't need 
to break into anything to get that information - the vendor, my bank, my CC 
company, credit agencies are call collecting and selling it anyway.

The other thing to keep in mind - and I've come back to this point repeatedly - 
is that the world we are now designing for is very different from the world of 
the mid- to late-1990's when the current schemes were designed.  Disk is so 
large and so cheap that any constraint in the old designs that was based on a 
statement like "doing this would require the user to keep n^2 keys pairs, which 
is too much" just doesn't make any sense any more - certainly not for 
individuals, not even for small organizations:  If n is determined by the 
number of correspondents you have, then squaring it still gives you a small 
number relative to current disk sizes.  Beyond that, everyone today (or in the 
near future) can be assumed to carry with them computing power that rivals or 
exceeds the fastest machines available back in the day - and to have an 
always-on network connection whose speed rivals that of *backbone* links back 
then.

Yes, there are real issues about how much you can trust that computer you carry 
around with you - but after the recent revelations, is the situation all that 
different for the servers you talk to, the routers in the network between you, 
the crypto accelerators many of the services use - hell, every piece of 
hardware and software.  For most people, that will always be the situation:  
They will not be in a position to check their hardware, much less build their 
own stuff from the ground up.  In this situation, about all you can do is try 
to present attackers with as many *different* targets as possible, so that they 
need to split their efforts.  It's guerrilla warfare instead of a massed army.

                                                        -- Jerry

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Reply via email to