home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / crypt / 4853 < prev    next >
Encoding:
Text File  |  1992-11-15  |  5.0 KB  |  125 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!usc!cs.utexas.edu!milano!cactus.org!ritter
  3. From: ritter@cactus.org (Terry Ritter)
  4. Subject: Re: Limits on the Use of Cryptography?
  5. Message-ID: <1992Nov16.090434.24712@cactus.org>
  6. Organization: Capital Area Central Texas UNIX Society, Austin, Tx
  7. References: <1992Nov11.061210.9933@cactus.org> <lgdbbbINNrfv@exodus.Eng.Sun.COM>
  8. Date: Mon, 16 Nov 1992 09:04:34 GMT
  9. Lines: 114
  10.  
  11.  
  12.  In <lgdbbbINNrfv@exodus.Eng.Sun.COM>
  13.  jfarrell@cloudbase (Jerry Farrell) writes:
  14.  
  15. >It seems to me there are three
  16. >usable arguments that have come up so far, of varying applicability.
  17.  
  18. >1) Futility.  The means to strong encryption are readily available from
  19. >numerous sources within and without the country.  Pre-registration would
  20. >not prevent the use of secure channels by parties willing to break the
  21. >law; quite possibly, it would only be detectable by an abuse on the part
  22. >of snooping authorities.
  23.  
  24.  If the goal of pre-registration was to prevent the use of non-
  25.  registered keys, that would indeed be futile.
  26.  
  27.  However, if the goal was to offer an alternative penalty for those
  28.  who successfully use cryptography to hide evidence of their crimes,
  29.  pre-registration could be quite effective.
  30.  
  31.  Be sure you have identified the real goal when you evaluate how
  32.  effective such a law would be.
  33.  
  34.  
  35. >Post-facto demands for a key could be met by
  36. >stonewalling or legitimate ignorance of a session key; a simple "I
  37. >don't rmember" sufficed for James R. Hoffa, and would likely reappear
  38. >as needed.
  39.  
  40.  I expect that this is the case now.  Consequently, this can be
  41.  taken as an argument for new legislation similar to financial
  42.  record-keeping requirements.
  43.  
  44.  
  45. >And the penalty for failure to provide a key on (warranted)
  46. >demand would very likely be less than the penalty for the hidden crime;
  47. >we could expect some people to accept jail for contempt (or whatever)
  48. >in lieu of revealing the keys LE would *really* like to see.
  49.  
  50.  Actually, I'm not sure that law-enforcement is as much interested
  51.  in *really* socking it to major criminals (how many life sentences
  52.  is enough, anyway), as they would be in getting access to
  53.  enciphered records.  Unfortunately, *that* is just not in the cards
  54.  no matter what laws are passed.  It is crucial that we make it clear
  55.  that new laws *cannot* solve this particular problem.
  56.  
  57.  On the other hand, cryptography regulations could result in a quick
  58.  and easy prosecution, which, given our current situation, could be
  59.  worth a lot to law enforcement.
  60.  
  61.  
  62. >2) Potential for abuse.
  63.  
  64.  I think we should dig in and fight *very* hard for a system which
  65.  minimizes the potential for abuse.  Frankly, I think it is worth
  66.  considering a pre-emptive industry program (message key archiving
  67.  in all commercial equipment), in an attempt to avoid regulations
  68.  which could support potential abuse.
  69.  
  70.  
  71. >3) Restraint of progress.
  72. > a. Much of the most interesting research in the use of cryptography
  73. >    involves one-time or session keys.
  74.  
  75.  Session keys (a.k.a. message keys) have been around for decades;
  76.  even I used them in my CLOAK cipher several years ago.
  77.  
  78.  
  79. >The user is hardly expected to know,
  80. >    far less retain these keys.
  81.  
  82.  A possible need to retain message keys is one of the things I
  83.  referred to with respect to possible new requirements in
  84.  cryptosystem design.
  85.  
  86.  
  87. A requirement to produce such keys on
  88. >    demand effectively prohibits protocols where that is impractical.
  89. >    This in turn severely restricts the use of electronic media in
  90. >    domains where privacy, authentication, and accountability are critical.
  91.  
  92.  I would like to hear of some cases in which archiving message keys
  93.  would be impractical.  Although I ended up using 992 bit (124 byte)
  94.  message keys in CLOAK, I can think of no real reason for them to be
  95.  over, say, 96 bits (12 bytes).  A little 2.5" drive could store
  96.  millions of them.  Perhaps even a write-once semiconductor device
  97.  could be used and replaced periodically, just like a battery.
  98.  
  99.  
  100. >It seems to me the arguments against pre-registration are quite strong,
  101. >perhaps even strong enough to sway a drug-crazed congress.
  102.  
  103.  I can understand your feeling here, but if we treat these people
  104.  as ignorant enemies, we can hardly expect them to respect our
  105.  wishes, now can we?  Not only do we need to treat them with
  106.  respect, we actually owe them enough real respect to realize that
  107.  they must deal with interests other than our own, which just might,
  108.  in the end, be more important to the country.
  109.  
  110.  
  111. >That is, as long as it is a legitimate response to a warrant for my keys
  112. >to say "I don't know them; I threw them all away as soon as the session
  113. >ended" or "I never knew them", I'm not sure I'd object to such a warrant
  114. >issuing (except as a taxpayer concerned about the waste of my dollars on
  115. >on futile pursuits).
  116.  
  117.  Can you imagine being able to avoid revealing your tax records
  118.  like this?  The government does impose serious record-keeping and
  119.  disclosure requirements right now; this is neither a new function
  120.  of government, nor a new sort of requirement for citizens.
  121.  
  122.  ---
  123.  Terry Ritter   ritter@cactus.org
  124.  
  125.