May 1993 - cypherpunks-legacy

Re: Selling Tapes ?
by John (FuzzFace/Fast-Eddie) McMahon 27 May '93

27 May '93

>What does traceroute do? I don't have it on my system... It lists the routers between your point and the destination. Sort of a poor man's mapping tool. It demonstrates that both NCSC and FBI are "openly/obviously" on the Internet. John

1 0

Re: VinCrypt
by smb＠research.att.com 27 May '93

27 May '93

Even as a former 'hacker' myself, the second to last person I would trust not to install a backdoor (next to the NSA) is a hacker. In addition, merely having been a systems hacker hardly qualifies one for writing complex crypto software. Without any assurance as to the authors' qualifications for writing a crypto package, or their integrity. Even if I could trust their integrity, I'm very leery of black-box software. ---- Robert W. Clark Just Say No! to the rclark(a)nyx.cs.du.edu Big Brother Chip Indeed. There were a pair of papers in Cryptologia a few years ago on ``Data Insecurity'' packages. The author cryptanalyzed a number of different PC-based crypto packages, and contrasted that with the glowing advertising copy...

1 0

Re: Steganography and Steganalysis
by wcs＠anchor.ho.att.com 27 May '93

27 May '93

John Gilmore writes: > My favorite scheme was to encode messages in trailing spaces and/or tabs > in netnews messages. You could also put internal tabs in place of spaces. and other fun things... > In fact, you could do this with news messages that flow "through" your > site, (if the messages aren't protected with a crypto checksum), so that > you would not be the message's sender (and it wouldn't be addressed to anyone > either -- recipients get very good privacy). Hmmm... While this certainly does provide some privacy, it also can break things, which is not nice to do to other people's messages. For example, if other people are encoding messages in trailing spaces or tabs in netnews messages, you'll replace their hidden messages with your own :-) I don't know if there's much news out there with Content-Length: headers or other byte-counting headers that would be disrupted; Lines: is obviously not bothered. On the other hand, if the messages that appear to be flowing through your site are really being generated there, either as forgeries of messages from other people, or forgeries of messages from anonymous posting sites, or are forged messages you're really posting through an anonymous posting site, you gain about the same effect (assuming your forgery is good enough to not attract attention.) (Forging messages from other people is best done either with cooperative people, or fake people, or people who don't mind like MAILER-DAEMON%Fidogate(a)BAR.BiTNet.) Bill Stewart

1 0

Digital cash issuess...
by sneal＠muskwa.ucs.ualberta.ca 26 May '93

26 May '93

There's an interesting paper on offline cash systems by Stefan Brands, who I believe is/was a student of David Chaum. The abstract reads: "We present a new off-line electronic cash system based on a problem, called the representation problem, of which little use has been made in the literature thus far. Our system is the first to be entirely based on discrete logarithms. Using the representation problem as a basic concept, some techniques are introduced that enable us to construct protocols for withdrawal and payment that do not use the cut and choose methodology of earlier systems. As a consequence, our cash system is much more efficient in both computation and communication complexity than previously proposed systems." "Another import aspect of our system concerns its provability. Contrary to previously proposed systems, its correctness can be mathematically proven to a very great extent. Specifically, if we make one plausible assumption concerning a single hash-function, the ability to break the systems seems to imply that one can break the Diffie-Hellman problem." "Our system offers a number of extensions that are hard to achieve in previously known systems. In our opinion, the most interesting of these is that the entire cash system (including all the extensions) can be incorporated straightforwardly in a setting based on wallets with observers, which has the important advantage that double-spending can be prevented in the first place, rather than detecting the identity of a double-spender after the fact. In particular, in can be incorporated even under the most stringent requirements conceivable about the privacy of the user, which seems to be impossible to do with previously proposed systems. Another benefit of our system is that framing attempts by a bank have negligible probability of success (independent of conputing power) by a simple mechanism from within the system, which is something that previous solutions lack entirely. Furthermore, the basic cash system can be extended to checks, multi-show cash and divisibility, while retaining its computation efficiency." [...some stuff elided...] "...Using the representation problem, we show in the appendix how to batch the confirmation protoocol of undeniable signatures such that polynomially many undeniable signatures can be verified in four moves." The paper can be found at ftp.cwi.nl /pub/CWIreports/AA/CS-R9323.ps.Z -- Steve

3 2

Selling Tapes ?
by John (FuzzFace/Fast-Eddie) McMahon 26 May '93

26 May '93

> Rick Adams of UUNET confirmed on the com-priv list that his > organization had been selling the FBI a usenet feed on tape. I could > find the exact reference if you want. I don't know for sure that the > NSA has a feed, or from whom, but it wouldn't surprise me. Seems like the low tech way of doing it. Both organizations have machines on the Internet right now. FBI is hooked in via ALTERNet, and the NSA (NCSC) is on the MILnet. % traceroute ard.fbi.gov % traceroute tycho.ncsc.mil (and see what happens) Cheers! Fuzz

2 1

Rivest evaluation of SecurID smart card
by nobody＠eli-remailer 26 May '93

26 May '93

-----BEGIN PGP SIGNED MESSAGE----- I thought this might be of some interest to the CypherPunks list. DEADBEAT <na5877(a)anon.penet.fi> - - - - - - - - - TO: Kenneth P. Weiss, Chairman Security Dynamics, Inc. 2067 Massachusetts Avenue Cambridge, Massachusetts 02140 FROM: Ronald L. Rivest /initials RLR/ DATE: April 7, 1987 RE: Evaluation of SecurID Approach to User Identification This memo provides a brief overall evaluation of your SecurID product, as you have requested, suitable for limited distribution. (It does not contain any of the proprietary information you have disclosed to me.) General Approach The SecurID card generates a pseudorandom sequence of displayed numbers: the displayed number us changed every 60 seconds. The sequence is "pseudorandom" rather than truly "random" in the sense that it is generated by applying a (proprietary) algorithm and secret key to a representation of the current time. Thus, a host computer knowing the algorithm and the secret key in the card can compute the number displayed on the user's card at any moment. Clearly, the numbers produced by such a card can be used in place of a conventional "PIN" or "password" for access control or user authentication, if the host is prepared to compute the number currently displayed on the user's card. That is, the user could enter the displayed number instead of a remembered PIN or password when he is asked to authenticate himself when initiating a login or financial transaction. One can obtain additional security by first combining a user-remembered PIN with the displayed number, so that the user is authenticated both by "what he knows" as well as "what he possesses". For example, if both the displayed number and the user's PIN are decimal numbers, the combining operation could be "add digit-by-digit without carry". The host computer, knowing both the user's PIN and the displayed number, can compute the correct value for comparison. Security Evaluation 1. An End-to-End Approach One major advantage of your approach is that it is an "end-to-end" technique: no intermediate nodes in the communication network are entrusted with any security responsibilities. The only places where secret information needs to be maintained and manipulated are the user's card and his host computer. By contrast, an approach which encrypts PINs and transmits them in encrypted form to the user's host computer may -- in a large, diverse, multiorganization network -- require tremendous complexity in terms of key management overhead and will necessitate a great deal of trust between the participating organizations. In my consulting work I have seen large organizations work very hard to design "end-to-end" authentication protocols because of their intrinsically greater security and simplicity. 2. Pseudo-random number generation As noted above, your card generates a pseudo-random sequence of numbers by applying a proprietary algorithm to a secret key and the current time (measured to the minute). The secret key is known only by the user's card and host computer. The system could be compromised if an "enemy" could predict future numbers to be displayed by the card, from past observed values. (These numbers are transmitted in the clear, and are not encrypted. This makes your approach valuable for logging in from a "dumb" terminal, but makes it possible for a wiretapper to obtain a set of previously values produced by the card.) However, I do not believe this attack can be successfully mounted against your system. I have tried to "break" your system in this manner, without success. The proprietary algorithm (which you have disclosed to me) is based on sound cryptographic principles; it is likely that the best approach to "breaking" this system is a brute-force search for the secret key. Since the secret key you use is longer than that used by DES, I believe that this approach is infeasible in practice. (I should note that while my examination of your algorithm was intensive and covered all aspects of the algorithm, it was of necessity an examination of limited duration. Some of your customers, such as those involved with matters of national security, will certainly want to see your algorithm subjected to additional intensive scutiny [sic] before adopting it for use.) Thus, I believe the sequence of numbers produced by your card will be unpredictable by an "enemy", even if he sees previously produced numbers. Therefore: o The ability to produce the number that is correct for the current time is a sound guarantee that the person logging in actually posesses [sic] the correct SecurID card. o The numbers produced do not need to be encrypted, since knowledge of past values will not allow an enemy to predict future values. Of course, other cryptographic algorithms could be used to produce the pseudo-random number sequence from the secret key and the current time. For example, one could use DES. (Given recent events, the algorithms should perhaps be called "ODES" for the _Old_ Data Encryption Standard".) However, given the shorter key length and greater implementation cost of DES, I don't see any advantage here other than that it is (or was) a standard that withstood at one time a careful review. (This, however, may be significant to some of your customers.) It is also perhaps worth noting that your algorithm, while easier to implement than DES, is more computation-intensive than DES, making a brute-force search substantially more difficult to mount. 3. Combining operations Additional security can be obtained by combining the displayed number with a user-remembered PIN, say by adding them digit-wise with carries omitted. While this combining operation is very simple, it is easy to prove that if the displayed number sequence is unpredictable, then adding a PIN to the sequence won't change this fact. Furthermore, the PIN itself is protected from disclosure, unless the "enemy" can obtain both the current displayed value and the value after the PIN has been added. However, to obtain the first requires access to the card, and to obtain the second requires wiretapping; these are not likely to be simultaneously available. (The risk here seems less than the risk that the keyboard is tapped in a conventional password scheme.) A similar analysis applies to using the displayed number sequence to "encrypt" values other that the PIN; this operation should provide the desired security. Summary The approach used in your SecurID product is novel, and offers security advantages over conventional PIN or password schemes. The cryptographic algorithm employed should provide a high degree of security. Dr. Ronald L. Rivest is a Professor in the Electrical Engineering and Computer Science Department of the Massachusetts Institute of Technology. He is a renowned world class cryptologist. Professor Rivest is one of the co-inventors of the RSA public-key cryptosystem, is a founder of RSA Data Security, Inc., and is on the Board of the International Association for Cryptologic Research. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBFAgUBLAPfX/FZTpBW/B35AQFSFAF/T+Bcc2a7PWGeyn1UN0rGcWj65u+1vdyv O8Vh5sjyr1J5ELZ99fwEuO29OmQJvwCD =QVMm -----END PGP SIGNATURE-----

1 0

private e-mail compromising
by TO1SITTLER＠APSICC.APS.EDU 26 May '93

26 May '93

Where in all of the previous messages about uunet did it say they were selling the NSA anyone's email? If I read it right, all they were doing was selling a netnews feed on tape! Kragen

1 0

Re: Digital cash issues...
by fnerd＠smds.com 26 May '93

26 May '93

> Regarding the issue of what to do under Chaum's scheme when someone double- > spends a piece of digital cash & their identity is revealed... I don't think > it's going to be a serious hindrance in the long term. ... Any credit card > company, phone company, or other corporation that does a lot of billing > already has staff dedicated solely to that function, with collection agencies > providing a second tier of functionality for the tougher cases. > > Dr. Cat / Dragon's Eye / New traditions for the next century Yes, but we would like to steer towards a world where no one you do business with knows or can reconstruct who you are or where you live. "Collection"-- the whole idea of "billing," in fact--is a way of doing business that's rooted in non-privacy. But also it's based on wanting to make transactions easier for people in a world without easy electronic transactions, accounting, budgeting, negotiation, reputations, etc. So maybe with these sorts of things, billing would be unnecessary. Anyway, thinking up variations on offline payment systems is a passtime of mine. Situations where people can't be online with the bank are special cases, so you can make up special-case solutions, like o "Tokens" or gift certificates that you buy in advance, or o Annonymous checks that expire and are refundable if the (specific, annonymous) payees don't cash them in a certain amount of time. Credit as it exists often seems like a trade with the devil of privacy invasion. Jeez, what would the world be like without *credit cards* and *junk mail*!? -fnerd

1 0

DE platform
by meyer 26 May '93

26 May '93

My apologies for not thinking to state what platform Dolphin Encrypt currently runs on. It's vanilla MS-DOS. Other versions are planned. The Dolphin Encryption Library (16 or so functions, containing the core encryption functions from DE) is also for MS-DOS (designed to work with the Microsoft and Borland development systems). This is all standard ANSI C code, so should port to other platforms without much problem. Currently there's a Clipper-oriented (that's the database language) version in preparation. Developers on other platforms (Unix, Amiga, etc.) who are interested in porting the library should send me email. I am most interested in contacting someone who can not only port the library but also market it. Porting of the Dolphin Encrypt program is a Stage II task, and depends on successful porting of the library. -- Peter

2 1

Re: Just the facts, ma'am.
by jthomas＠kolanut.mitre.org 26 May '93

26 May '93

From: composer(a)beyond.dreams.org (Jeff Kellem) > > On the cypherpunks mailing list, Strat wrote... > > Rarely will you find a system administration staff more concerned with > > your privacy that the guys at Digital Express Group. As I recall, the > > set of username->real name mappings isn't even on machine readable media > > on the system. > > Really? That's odd, especially for a unix box, which access.digex.com > seems to be. And, as a matter of fact, it does seem to show "Robert > Stratton" for the username of "strat". So, it seems they do maintain > username to "real name" mappings (even if they allow the user to change > the "real name" listed. Digital Express doesn't require that the GECOS field of /etc/passwd contain real names, although they obviously allow it. (Finger jthomas(a)access.digex.net for my full name, as well as my PGP key :^) I seem to remember that the new user signup script they use explicitly gives you the option of signing up under a pseudonymn, although they'll check up on you by phone if you do (and presumably write your name in the Big Book at that point). I've seen quite a few public access Unix sites advertising "anonymous" accounts lately, especially after Julf's server went down. Joe

1 0