home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / privacy / p01_003.txt < prev    next >
Text File  |  1996-09-03  |  14KB  |  278 lines

  1. PRIVACY Forum Digest        Sunday 7 June 1992        Volume 01 : Issue 03
  2.  
  3.     Moderated by Lauren Weinstein, Vortex Technology, Topanga, CA, U.S.A.
  4.  
  5.                       ===== PRIVACY FORUM =====
  6.  
  7. CONTENTS
  8.     FBI Wiretap Issues (Moderator--Lauren Weinstein)
  9.     Wells Fargo Bank Offers Security Codes (Moderator--Lauren Weinstein)
  10.         Re: e-mail privacy; a cheap solution? (Steve Bellovin)
  11.         Digital one time pads (A. Padgett Peterson)
  12.         E-mail privacy; a cheap solution? (Bob Leone)
  13.  
  14. *** Please include a MEANINGFUL "Subject:" line on all submissions! ***
  15.  
  16. -----------------------------------------------------------------------------
  17. The PRIVACY Forum is a moderated digest for the discussion and analysis of
  18. issues relating to the general topic of privacy (both personal and
  19. collective) in the "information age" of the 1990's and beyond.  The
  20. moderator will choose submissions for inclusion based on their relevance and
  21. content.  Submissions will not be routinely acknowledged.
  22.  
  23. ALL submissions should be addressed to "privacy@cv.vortex.com" and must have
  24. MEANINGFUL "Subject:" lines.  Subscriptions are by an automatic "listserv"
  25. system; for subscription information, please send a message consisting of
  26. the word "help" (quotes not included) in the BODY of a message to:
  27. "privacy-request@cv.vortex.com".  Mailing list problems should be reported
  28. to "list-maint@cv.vortex.com".  Mechanisms for obtaining back issues will be
  29. announced when available.  All submissions included in this digest represent
  30. the views of the individual authors and all submissions will be considered
  31. to be distributable without limitations. 
  32.  
  33. For information regarding the availability of this digest via FAX, please
  34. send an inquiry to privacy-fax@cv.vortex.com, call (310) 455-9300, or FAX
  35. to (310) 455-2364.
  36. -----------------------------------------------------------------------------
  37.  
  38. VOLUME 01, ISSUE 03
  39.  
  40.     Quote for the day:
  41.  
  42.        Russian Spy:  "Are you trying to tell me that every phone
  43.               in the country is tapped?"
  44.  
  45.        American Spy: "That's what's in my head..."
  46.  
  47.        Russian Spy:  "But Don!  This is AMERICA... not RUSSIA!"
  48.  
  49.            --- "The President's Analyst" (1967)
  50.  
  51. ----------------------------------------------------------------------
  52.  
  53. Date:    Sun, 07 Jun 92 13:12:00 PDT
  54. From:    lauren@cv.vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
  55. Subject: FBI Wiretap Issues
  56.  
  57. Greetings.  As most of you are probably aware, a considerable amount of
  58. interest and debate has recently been triggered by Justice Department/FBI
  59. regulations which have been proposed regarding wiretapping, and the
  60. provision of related call information (e.g. call forwarding and speed dial
  61. codes, etc.), in the age of digital telecommunications networks.  
  62.  
  63. In brief, the rules propose that telephone companies, long distance
  64. carriers, and most other telecommunications entities (including,
  65. apparently, local PBX operations) be required to provide mechanisms
  66. for authorized law enforcement to monitor communications, without being
  67. impeded by the technological changes being wrought on communications
  68. by rapidly evolving digital technologies and networks.  I've called
  69. these proposals "Dial-A-Wiretap" in some recent interviews.
  70.  
  71. The argument is that the "old" techniques of wiretapping and monitoring
  72. are rapidly being made impotent by digital technologies that multiplex
  73. many conversations into high speed digital channels, and which in 
  74. other ways make "low-tech" tapping difficult or impossible.  It is 
  75. futher argued that authorized taps are critical to law enforcement
  76. activities and can play an invaluable role in protecting lives and
  77. property.
  78.  
  79. There are those (myself included) who, while agreeming that properly
  80. authorized wiretaps can have important roles in law enforcement, are
  81. nonetheless concerned that the sorts of access being proposed might amount
  82. to the ability to set up "instant" and "perfect" wiretaps to almost any
  83. phone at any time, simply by changing the routing of the digital data
  84. flowing through the switches and networks.  
  85.  
  86. The question comes up as to whether law enforcement wants to make sure
  87. it is *possible* to do taps or whether what is really desired is
  88. a mechanism to make it *trivial* to do taps, especially from distant,
  89. centralized locations.
  90.  
  91. It is argued by the proponents of the new regulations that adequate
  92. controls would be in place to prevent abuse of such facilities, and
  93. that only "properly authorized" taps would take place.  Unfortunately,
  94. the history of wiretaps shows that where it is possible for a system
  95. to be abused, the odds are that it will be, either by people inside
  96. or outside of the system.
  97.  
  98. A topic of possible discussion for this digest would be how the conflicts
  99. presented by these issues can be resolved.  My personal view is that
  100. authorized wiretaps can be important, and that if any sort of direct access
  101. to the network is granted, it must be via some *independent* (not telco, not
  102. government) third party who would technologically control the access.
  103. Simply relying on the self-restraint of the parties with vested interests
  104. would not seem like the best possible procedure.  If there is some way
  105. to avoid granting direct access at all, so much the better.
  106.  
  107. Or is there another solution?  Should unrestricted access be granted,
  108. subject only to procedural controls?  Should no access at all be granted?
  109. If no access is granted, how can authorized wiretaps be accomplished?  Given
  110. that authorized wiretaps play an important and necessary role, how can a
  111. balance be struck?  Or would you argue that no wiretaps at all should be
  112. permissible?  What would be the ramifications of such a decision to
  113. important law enforcement and security efforts?  Finally, how does the
  114. availability of efficient telephone encryption systems enter into the mix?
  115.  
  116. Plenty to think about.
  117.  
  118. --Lauren--
  119.  
  120. ------------------------------
  121.  
  122. Date:    Sun, 07 Jun 92 13:33:00 PDT
  123. From:    lauren@cv.vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
  124. Subject: Wells Fargo Bank Offers Security Codes
  125.  
  126. In a refreshing change from the usual attitude regarding customer security
  127. and privacy, Wells Fargo (a very large California bank) is willing to put
  128. arbitrary security codes, which can be essentially any number or word
  129. combination, on customer accounts.  The codes are then needed, in addition
  130. to the usual social security number and related information, to conduct
  131. transactions regarding those accounts by phone.  
  132.  
  133. There are some limitations and side-effects to specifying these codes, so if
  134. you're interested you should contact a Wells Fargo representative for
  135. details.  Tellers may not know anything about this, but the telephone
  136. support folks should be fairly well informed about its availability.  Note
  137. that Wells has *not* been promoting the fact that this service is available,
  138. probably since they don't want to deal with large numbers of customers
  139. who will end up calling and complaining that they forget their codes
  140. (a typical reason why such security systems are often resisted by
  141. financial institutions).
  142.  
  143. Anyway, it's an all too rare, but very positive step.
  144.  
  145. --Lauren--
  146.  
  147. ------------------------------
  148.  
  149. Date:    Sat, 30 May 92 21:45:05 PDT
  150. From:    smb@ulysses.att.com
  151. Subject: Re: e-mail privacy; a cheap solution?
  152.  
  153. The encryption scheme Charlie Stross describes is a variant on the
  154. ``book cipher'', which has been known for quite some time.
  155. Unfortunately, it's also been solved -- by Friedman, in the 1920's, as
  156. I recall.  The basic solution algorithm involves guessing at some
  157. probable plaintext.  From that, one can derive the encryption key.
  158. Now, if the encryption key is taken from something with considerable
  159. redundancy -- a book, or a piece of music -- a recognizable pattern
  160. will show up if the guess at the plaintext was correct.  From that, one
  161. can predict, if not the actual next key value, at least a set of likely
  162. or legal values.  These can be used to produce candidate plaintexts,
  163. which must also be recognizable.  One thus proceeds in parallel to
  164. reconstruct both the plaintext and the key.  Further information can be
  165. found in David Kahn's ``The Codebreakers'' (*the* starting point for
  166. any discussion of cryptography) and in Leighton and Matyas's ``The
  167. History of Book Ciphers'', from the Proceedings of Crypto '84.
  168.  
  169. There are variations on the scheme proposed that could, most likely, be
  170. made secure.  Unfortunately, the scheme fails for more fundamental
  171. reasons.  The issue is not simply choice of an encryption algorithm --
  172. as has been noted, one-time pads are provably secure -- but
  173. distribution of keys.  I send and receive dozens of email messages a
  174. day, often to individuals with whom I have never communicated before.
  175. There is no practical way to distribute all of the needed one-time
  176. pads.  And one must *never* reuse a one-time pad, or there is a
  177. considerable risk of compromise.  This is the reason one-time pads are
  178. not universally used -- because shipping relatively short keys around,
  179. and generating them on the fly at some key distribution center *is*
  180. feasible.
  181.  
  182. I'm also not puzzled by the lack of more public-key cryptosystems.  Put
  183. simply, why should there be more of them?  Devising such schemes is
  184. hard.  Many have been proposed; generally, they're either determined to
  185. be insecure, or they're impractical for some reason.  There's one where
  186. the public keys are tens of thousands of bytes long.  Think what that
  187. would do do the average privacy-enhanced email message, which includes
  188. the sender's public key in the header.  Besides, there is a scheme
  189. which is considered to be both secure and practical:  RSA.  The
  190. objections to its use within the U.S. lie in its patent status.  But
  191. that's a financial problem, and far from an insurmountable one.
  192.  
  193. One more point is worth adding.  Cryptographically speaking, until very
  194. recently the civilian community hasn't had a clue.  Take DES, for
  195. example, which was a product of IBM (*not* NSA, though they reviewed
  196. its design).  Until Biham and Shamir's work over the last two or
  197. three years, no one else in the outside community had any idea why
  198. the S-boxes were built they way they were.  Suspicions arose that
  199. NSA had tampered with the design.  Had they?  Shamir himself says that
  200. he thinks that DES is about as strong as it could possibly be, given
  201. its basic structure.  Even the decision to shorten the key length to
  202. 56 bits, often trumpted as an example of NSA's meddling, may have
  203. served to strengthen DES against any attack short of exhaustive search.
  204. (That's my own interpretation of assorted results; I'll be glad to
  205. discuss my reasoning further if anyone wishes.)
  206.  
  207. The net result is this:  most people don't know how to design secure
  208. cryptosystems.  More precisely, since they don't know what makes a
  209. system insecure, they have no way of avoiding the problem.  (I'm
  210. certainly not excluding myself; I'm neither a mathematician nor
  211. a cryptographer.)  But the issue is much simpler than conspiracy
  212. theorists would have us believe; it's just that the civilian community
  213. lacks the decades of continuous experience in the field.
  214.  
  215.  
  216.         --Steve Bellovin
  217.  
  218. ------------------------------
  219.  
  220. Date:    Sun, 31 May 92 12:11:11 PDT
  221. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  222. Subject: digital one time pads
  223.  
  224. >From:    Charlie Stross <charless@sco.COM>
  225. >Subject: e-mail privacy; a cheap solution?
  226.  
  227. >Take a CD-ROM drive with a device driver for playing audio CD's
  228. >and randomly accessing audio tracks. Most multi-media kit should
  229. >already be capable of doing this. Take a random music CD off your
  230. >shelf and start playing it at a random offset; redirect the bit
  231. >stream to a file. 
  232.  
  233. Actually a pretty good idea Harold Highland & I discussed a while
  234. back except that the dictionary from any good wordprocessor was going
  235. to be used. Big & already digital. Make a marvelous book code.
  236.  
  237. Of course the entire question is academic since generating masses of random
  238. digits is one thing that computers are *really*good*at* so why bother with
  239. CDs (or dictionary) at all ? Of course both sides of the conversation have 
  240. to have the same key or you get garbage but for two people this is not a 
  241. problem, for a network though...
  242.  
  243. One point I would like to make, many people are hung up on "massively
  244. parallel" computers running through all the possible permutations of
  245. keys being able to break DES (or whatever) in a month/week/day/nanosecond.
  246. Sure, but the real kwestion is: how do you *know* when you broke it ?
  247.  
  248.                     Warmly,
  249.                         Padgett
  250.  
  251. ------------------------------
  252.  
  253. Date:    Sat, 30 May 92 22:30:27 PDT
  254. From:    Bob Leone <leone@gandalf.ssw.com>
  255. Subject: e-mail privacy; a cheap solution?
  256.  
  257. While I agree with the moderator's observation regarding the ease to which
  258. the "CD" encryption scheme can be broken, there's a lot to be said in
  259. favor of widespread use of even easily-broken encryption schemes: it
  260. would make it infeasible for govt to routinely monitor communications.
  261.  
  262. Currently, it is feasible for the govt to monitor Internet e-mail traffic
  263. and select out messages containing certain keywords. Also, if only a
  264. tiny number of messages on the net are encrypted, then the encrypted
  265. messages practically scream "Look at me! Look at me! This message discusses
  266. something that you'll probably be interested in!".
  267.  
  268. But if the majority of e-mail traffic is routinely encrypted, and by various
  269. encryption schemes, then it becomes much more expensive for the govt to
  270. engage in random snooping. Also, if most traffic is routinely encrypted, 
  271. and you send a confidential message that you encrypt using a particularly
  272. secure scheme, your message won't stand out so much.
  273.  
  274. ------------------------------
  275.  
  276. End of PRIVACY Forum Digest 01.03
  277. ************************
  278.