How to ban crypto?

Steven M. Bellovin smb at research.att.com
Sun Sep 16 19:16:45 EDT 2001


In message <4.2.2.20010916164053.00da5520 at surfcity.research.att.com>, John Denk
er writes:

...

>.
>
>The two most common anti-GAK arguments are:
>   1a) It can't be done well.
>   1b) If it can't be done well, it shouldn't be done at all.
>   1c) Specifically, the risk of wholesale key-compromise is too great.
>
>   2a) It won't really detect/deter typical crime, because typical 
>criminals will find ways around it.
>   2b) It won't really detect/deter terrorism, because dedicated terrorists 
>will find ways around it.
>
>
>I'm dubious about argument (1) in all its forms.  I suspect that if we 
>wanted to make it work, we could make it work.
>

John, you've just opened a can of worm.  A giant, economy-sized can of 
worms...

The basic argument is complexity.  Cryptographic software and key 
exchange protocols are very hard to get right even in simple cases.  If 
we now try to add a new feature, we have to add complexity.  Worse yet, 
this new feature is designed to do something that is not only 
brand-new, it's something that more conventional protocols and 
implementations are designed to avoid, at virtually all costs:  export 
a copy of the key.  Why do you think we can get this right?  

That's the essence of why I (and many others) accept (1); for more 
detail, see "The Risks of Key Recovery, Key Escrow, and Trusted Third 
Party Encryption", at http://www.cdt.org/crypto/risks98.  As a 
postscript, I'll note that we've already had a failure associated with 
the key recovery mechanisms in a version of PGP; see CERT Advisory 
CA-2000-18, http://www.cert.org/advisories/CA-2000-18.html.

		--Steve Bellovin, http://www.research.att.com/~smb
				  http://www.wilyhacker.com





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list