- cypherpunks-legacy@lists.ogf.org

Interim patch for ytalk
by miron＠extropia.wimsey.com 27 May '93

27 May '93

I also intend to change the name of the program to PGTalk. If anybody has better ideas, please let me know. This patch is important for the security of the encryption. The idea was to have cipher feedback (pun intended!). Somehow I reversed a couple of lines. *** ytalk/idea.c Thu May 27 13:40:36 1993 --- pgtalk/idea.c Thu May 27 13:40:52 1993 *************** *** 504,510 **** { idea_ecb(iv,temp, Z); /* encrypt iv_idea, making temp. */ ! if (!decrypt) /* buf is ciphertext */ /* shift in ciphertext to IV... */ cfbshift((byte *)iv,buf,chunksize,IDEABLOCKSIZE); --- 504,510 ---- { idea_ecb(iv,temp, Z); /* encrypt iv_idea, making temp. */ ! if (decrypt) /* buf is ciphertext */ /* shift in ciphertext to IV... */ cfbshift((byte *)iv,buf,chunksize,IDEABLOCKSIZE); *************** *** 511,517 **** /* convert buf via xor */ xorbuf(buf,(byte *)temp,chunksize); /* buf now has enciphered output */ ! if (decrypt) /* buf was plaintext, is now ciphertext */ /* shift in ciphertext to IV... */ cfbshift((byte *)iv,buf,chunksize,IDEABLOCKSIZE); --- 511,517 ---- /* convert buf via xor */ xorbuf(buf,(byte *)temp,chunksize); /* buf now has enciphered output */ ! if (!decrypt) /* buf was plaintext, is now ciphertext */ /* shift in ciphertext to IV... */ cfbshift((byte *)iv,buf,chunksize,IDEABLOCKSIZE);

1 0

Questionable instances?
by fergp＠sytex.com 27 May '93

27 May '93

On Wed, 26 May 93 2:18:52 CDT, Peter Meyer <uunet!cactus.org!wixer!wixer.bga.com!meyer> wrote - > My previous message to cypherpunks, the one which had > subject heading "AT&T" and which began: > "I recently switched my long distance carrier from AT&T to another, > since they bribed me to do so with an offer of $35." > seemed to be posted OK (it apparently came back to me as expected) > but I also got this funny bounce message: >From attmail.com!uucp(a)cactus.org Tue May 25 23:37:59 1993 [ remainder of header deleted ] > This seems odd. What's going on? Do all messages with "AT&T" in the > subject line get siphoned off somewhere for review? Did this one > generate a bounce message because the account of Bryan Petty, AT&T spy, > wasn't receiving tonight? OK, I'm just paranoid. (Paranoia - that's > your state of mind when you finally realize what's really going on.) At least I'm not the only one who has recently noticed this. I had to do a double take when I received not only my original post on UUNet questions from cypherpunks-request(a)taod.com, but I received a second copy with this header:

3 3

Re: VinCrypt
by greg＠ideath.goldenbear.com 27 May '93

27 May '93

-----BEGIN PGP SIGNED MESSAGE----- J. Michael Diehl <uunet!triton.unm.edu!mdiehl> writes: > > 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. > > Are you meaning to imply that there is a backdoor in this package? If so, how > do you justify this claim? It seems safer to assume that the software is insecure, until proven otherwise. This is the approach that's been taken with the Clipper chip, and seemed reasonable in that case - I suggest that it is in this case, as well. > > 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. > > You seem to know something about them that I do not. Care to share your > knowledge? Thanx in advance. Rather, the original poster (Clark Reynard) seems to *not* have information - e.g., information about how or why the author(s) of this crypto package are trustable, or why we should consider their software secure if we can't look at the source. If they are so naive as to think that the NSA can't afford a copy of Sourcer and a few person-hours to disassemble VinCrypt, what other (absurd) assumptions have they made? If a machine can execute it, a machine (or a machine and a person) can disassemble it. I can't believe that anyone's willing to take this VinCrypt crap even a little bit seriously. Any dork with a laser printer can print up a press release and mail it out - looks like maybe this was a slow week for the computer press. As far as I can tell, we're supposed to assume that VinCrypt is useful software because of the political/social perspective of its authors. While I share their suspicion of the powers that be, I do not trust them to write software that is free of intentional and/or nonintentional weaknesses. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLARuSX3YhjZY3fMNAQESdQP+LP7jdBJLzvzDItehb4Lwwwch9Wi1LfS6 5pvPd/+NeXYNb2RDYSbf7RNvQ6nQTgLYvD9cs8Xw5kXAJzhA/6PVULgMj66OsC63 3SMeVzQuu3Ui0Ki0nF+RslKNDL/gffurPSzJ9Pwn4uCiAFiXObjkriYE5M02bJOw Ax7pVUq7ueQ= =Mj7Z -----END PGP SIGNATURE----- -- Greg Broiles greg(a)goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764

1 0

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