- cypherpunks-legacy - lists.cpunks.org

Re: lists of U.S. cypherpunks and Tentacles.
by nobody＠pmantis.berkeley.edu 17 Dec '03

17 Dec '03

> From: Tentacle(a)medusa.conspiracy.org > > Fellow Tentacles, > Does there exist lists of Tentacles and CypherPunks who > are U.S. citizens with U.S. email addresses? > > Such a list would be useful to code creating cypherpunks > who wish to distribute code widely in the U.S., but who > do not wish to become involved in the Crypto Exportation > hassles. > Yeah, right. And let's get the names and addresses of all the gun owners in the US too...

2 1

not a repost
by Carl Ellison 17 Dec '03

17 Dec '03

On sci.crypt on Feb 23, I posted (from world.std.com) a description of a variant on my favorite des|tran|des|tran|des with the inner DES rotating through N different keys, one block each. (This is no sweat, if you have S/W DES.) The result is a *huge* amount of key material to be derived by cryptanalysis. I also posted the keyless tran. I won't pad this list with a re-post. - Carl Ellison cme(a)sw.stratus.com RIPEM MD5OfPublicKey: 39D9860686A9F075A9A83D49589C677A PGP 2.4 Key fingerprint = E0 41 4C 79 B5 AF 36 75 02 17 BC 1A 57 38 64 78

1 0

Information
by w.sloan＠genie.geis.com 17 Dec '03

17 Dec '03

I was wondering if I could get on your E-Mailing list. I have an interest in data encryption, especially if this clipper chip stuff really happens. If you could let me know if you all send newsletters on a regular basis, if I could be included if it is not to much of a problem. Thanks. My address is W.SLOAN(a)GENIE.GEIS.COM.

1 0

Intelligent agents
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

I just wanted to know if Intelligent agents(telescript from General Magic) will pertain at all to crypto. Any feeling on the subject? Reuben Halper

1 0

Re: An Australian Clipper!
by Peter Murphy 17 Dec '03

17 Dec '03

Thanks for your quick reply. I will try and interrogate the lecturer involved for any further info on the subject. I will get back to you on Wednesday (Australian time), as the said lecture occurs on Tuesday. Thanks, CCVARGA(a)delphi.com . Peter Murphy.

1 0

Tacky Tokens
by drzaphod＠brewmeister.xstablu.com 17 Dec '03

17 Dec '03

Welp. I am now the proud new owner of 0 tacky tokens. I guess I wasn't in the first ten to reply. So I know there are more of you out there. Here's the deal: SALE SALE SALE. Everything must go! CLEARANCE CLEARANCE. For anybody with 5 extra Tacky Tokens in their pocket, you can own this wonderful, custom GIF by DrZaphod. It's a 320x200x256 picture that will jump out at you: HIGH QUALITY ART. Remember.. that's only FIVE Tacky Tokens for this CLASSIC GIF! Use it as your X background, your Windows backround.. or even print and wallpaper your room with it! Please PGP me a msg including: Your email address or remailer info. Your 5 Tacky Tokens eSASE if required Your PGP Public Key Mail all requests to: DrZaphod <drzaphod(a)brewmeister.xstablu.com> once again, that's: drzaphod(a)brewmeister.xstablu.com Be sure an encrypt your msg with the following key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAirPdYEAAAEEAMoyYy8lL84DlFK4IRmYBwfSFY8IwWia0J3cKPHKyQVligPK gUnfh+Ky6wN6eXAeZsbEjM6VMXY21mMaRec3IbzXok2UKQHyFNUnL74J4iH1+hGw 0hO89bcDwFeFXvaFqcNTQRF0GJOSSIEiz970fqUOo+esZzKeazP+2tnMgvmhAAUR tCFEclphcGhvZCA8ZHJ6YXBob2RAbmNzZWx4c2kudXVjcD4= =NLcb -----END PGP PUBLIC KEY BLOCK----- don't forget: drzaphod(a)brewmeister.xstablu.com All merchandise sent via armored PGP msg! Write NOW! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - DrZaphod #Don't Come Any Closer Or I'll Encrypt! - - [AC/DC] / [DnA][HP] #Xcitement thru Technology and Creativity - - [drzaphod(a)brewmeister.xstablu.com] [MindPolice Censored This Bit] - - 50 19 1C F3 5F 34 53 B7 B9 BB 7A 40 37 67 09 5B - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Magic Money Comments
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Pr0duct Cypher at remailer(a)merde.dis.org wrote: >> There is no prototype for pgp_randombyte. > There is a prototype for it in pgptools.h Yes, but it needs to say "byte pgp_randombyte(void);" instead of just "byte pgp_randombyte();". >> Complete prototypes for (*output) and (*lookup) need to be >> provided in the function header of pgp_check_sigs and also for a >> different function pointer (*output) used in PGPKGEN. > Is this bad? I thought a function pointer didn't really > care, as long as you called it correctly. No - it is fine. This is simply a list of what it takes to eliminate all warnings from Borland. It is certainly ok not to do this. Even PGP generates quite a few warnings while compiling. > MPILIB has not been altered. It is the same as in PGP. > PLATFORM appears to set the appropriate modmult, but I > usually define UPTON because SMITH has given me some > problems in the past. Yes - I didn't notice all the various knobs and dials in PLATFORM.H until after I wrote that message. I needed to define a few more things. > What are you running, a Cray? My machine takes quite a few > seconds to run the server. I am running on a 33 mhz 486. While MPILIB does indeed take seconds to perform the required arithmetic, it builds its operations from an O(N^2) multiply algorithm. A "fast" algorithm would speed things up considerably. > I hate error checking. If I put in safe read and write > calls, what do I do if they fail? Just exiting with an error message would be fine. > Thanks for pointing out that bug, and especially for > setting up a Magic Money server. You are welcome. I'm not sure I have actually set up a server aside from the purpose of exercising the code for a few days. Hopefully others will grab the executables and do something a bit more permanent. -- Mike Duvos $ PGP 2.3a Public Key available $ mpd(a)netcom.com $ via Finger. $

1 0

re: inept spy
by Mark Hittinger 17 Dec '03

17 Dec '03

TC May writes: >The moral: If you're planning to pass secrets to the Russians, learn >some tradecraft! (I was amazed at the ineptness of Ames, a senior CIA >guy, in leaving such a trail. And amazed at the ineptness of his >superior at the Agency for not checking up on him (they flutter > .. >Don't _any_ of them read Ludlum? I think we all need to pay close attention to this. Perhaps he wanted to get caught - perhaps the russians wanted us to find out - perhaps we are not getting the whole story. I know something funny is up with regards to the "timing" of this thing coming out.

3 3

DH Exchange Code / Magic Money comments
by remailer＠merde.dis.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- DH Exchange announcement follows these comments on mpd's message. Pr0duct Cypher mpd(a)netcom.com wrote: >Earlier this morning I grabbed the latest version of Magic Money >from csn.org and compiled it under the Borland C++ 3.1 IDE. Since >the Borland C compiler is one of the more paranoid ones around, I >thought I would briefly list the things I had to do in order to >get zero warnings and zero errors. >The sources I started with were MGMNY10E.ZIP and PGPTL10C.ZIP. >After #defining MSDOS you will find that it is a good idea to >#include <stdlib.h> in almost every module. This prototypes >quite a few of the commonly used functions which would otherwise >cause the compiler to complain. A few modules will require ><mem.h>, <string.h>, and <time.h> since they call functions in >these modules which are not in <stdio.h> or <stdlib.h>. Have they changed the .h files? My compiler isn't missing any functions when I compile it. >The C library function "randomize" is defined in <stdlib.h>. This >conflicts with the Magic Money function of the same name which >initializes the MD5 based RNG used to generate coin ids. I >changed the name of the Magic Money one to "random_init". Blaaah. I didn't have stdlib compiled into that module, so I didn't notice this one. >There is no prototype for pgp_randombyte. Since this function >returns "byte", not "int", this could be painful on any compiler >which treats these types of function returns differently. There is a prototype for it in pgptools.h >Complete prototypes for (*output) and (*lookup) need to be >provided in the function header of pgp_check_sigs and also for a >different function pointer (*output) used in PGPKGEN. Is this bad? I thought a function pointer didn't really care, as long as you called it correctly. >The Borland compiler always warns on "if (a=b)" because it >assumes the user mistyped "if (a==b)". To get rid of the >warning, you have to say "if (0!=(a=b)) which is optomized out by >the compiler. This occurs in a number of places, including the >macro for multiplication mod 65537 in idea.c. I know, mine complains about that too, but it's a common programming technique and there is nothing wrong with it. I've been ignoring that particular warning. >There is a reference to an undefined pgp_pubkey in fifo.c which >goes away if you #include "pgptools.h". You then also have to >toss in "mpilib.h" and "md5.h" to make "pgptools.h" happy. Yes, when fifo.c includes pgpmem.h, it notices that in one of the prototypes in that function. But the only function fifo calls within pgpmem is safemalloc, so it doesn't matter. I didn't want every file to include every other file, although it has been hard to avoid. >It appears that mpilib.c has been persuaded to compile the UPTON >modmult instead of the SMITH modmult. Unfortunately, there are a >few modules which fail to #include the definition of UPTON and >still call stage_smith_modulus and smith_modmult. Sticking in a >#define to UPTON at the top of "mpilib.h" fixes this. MPILIB has not been altered. It is the same as in PGP. PLATFORM appears to set the appropriate modmult, but I usually define UPTON because SMITH has given me some problems in the past. >The conditional code which allows prior definition of external >versions of mp_setp, mp_addc, mp_subb, mp_smul, and mp_rotl >written in assembly language for some strange reason causes the >compiler to generate externals to _P_SETP, _P_ADDC, _P_SUBB, >_P_SMUL, and _P_ROTL instead of _mp_setp, _mp_addc, _mp_subb, >_mp_smul, and _mp_rotl in modules which reference these routines. >It does not seem to have this effect in mpilib.c where these >routines are defined. Deleting the corresponding #ifdefs cures >this. This I hadn't noticed. You have to define NO_ASM or compile in 8086.asm. Also define MSDOS and SMALL_MEM and DYN_ALLOC for an MSDOS machine. Take a look at the PGP 2.3a project file. >The compiler correctly points out that pgp_extract_rsa never uses >the variable "pk" passed to it. At the cost of a few machine >cycles, you can silence the compiler by putting "pk=pk" as the >first executable statement in this function. True. I noticed this after writing the prototype. The public key might be useful in the future if the modexp is changed, so I left it in. >The function pgp_randombyte hashes a variable "time" without >first initializing its value. It might be nice to change "time" >to "timestamp" and do a "time(&timestamp) unless it was the >authors intention to utilize uninitialized memory. I screwed up here. I meant to include the time in the hash and forgot to put in the call to time. I just sent an update to csn.org to fix this one, because it could reduce the entropy of the randomizer. Time was already factored into the initialize, so it wasn't a killer, but it badly needed fixing. Thanks for finding it. >If the server is executed more than one time within a second, it >can generate indentical random values. This could be a problem when >batch-processing mail. Including a fast timer register in the MD5 >hash in addition to the time of day in seconds would likely >eliminate this risk. What are you running, a Cray? My machine takes quite a few seconds to run the server. How do you include this fast timer register? Not all machines have it, so doing so would be very machine dependent. You could put in ifdefs for the PC. I think PGP has this. >The program uses "safemalloc" and "mm_safeopen" to access memory >and files, but does a very large number of "fread" and "fwrite" >calls without checking to see if they completed successfully. A >"safefread" and "safefwrite" might be a good idea so the server >does not continue happily on as the hash file fills up the disk. Yeah, I know, and so does fifo.c in PGP Tools. I hate error checking. If I put in safe read and write calls, what do I do if they fail? You could do this easily with some defines, if you have the error recovery code in mind. Thanks for pointing out that bug, and especially for setting up a Magic Money server. - ----------------------------------------------------------------------- Diffie-Hellman Exchange addition to PGP Tools Should appear on csn.org as dhex10a.zip There has been quite a bit of interest in online crypto applications, such as secure phones, BBSes, and TELNET connections. For these applications, Diffie-Hellman exchange has a major advantage over RSA: there is no private key to steal. If RSA is used for key exchange, an attacker could record the encrypted sessions, and then acquire your private key after the fact and decrypt them. With Diffie-Hellman, the secret information is gone as soon as the session is over. Using DH is equivalent to using a disposable one-time RSA key for each session, but much faster. This is a DH add-on for PGP Tools. There is a new PGPKGEN which exports the prime-finding functions, the main files DHEX.C and DHEX.H, and a demo. To use DH, we need a modulus n and a generator g. Unlike an RSA modulus, which is a product of two primes, a DH modulus must be prime. (n-1)/2 must also be prime. This makes the moduli slightly painful to find, but they can be reused indefinitely. DHEX tests a modulus by first testing both n and (n-1)/2 with fastsieve. Only if both pass is slowtest used. It still took me a whole day to find the 1024-bit modulus in the demo. There is also a 512-bit modulus there. To find the generator, we need the factors of n-1. They are 2 and (n-1)/2. For each factor f, we compute ((g^((n-1)/f)) mod n). If this is 1 for either factor, the number is NOT a generator. Generators are easy to find, usually in one to three tries. The modulus and generator can be saved and reused. Now Alice and Bob each call precomp. This generates a private piece x and computes X=g^x mod n. Big-X is the public piece. Alice and Bob exchange public pieces, then each compute k=Y^x mod n where Y is the other person's public piece and x is your own private piece. K will be the shared secret. We take the MD5 of this number to get an IDEA key, which will be the same on both sides. No eavesdropper can get this number. The public and private pieces are disposed of - they are only used once. This is vulnerable to a man-in-the-middle attack, where an attacker carries out a separate DH exchange with each party and then sits in the middle, decrypting with one session key and encrypting with the other. A digital signature will prevent this, if Alice and Bob have each others' public keys. One approach is for both parties to sign their public pieces before exchanging them. Another is to do the DH, go secure, and then each party signs the session key and sends the signature to the other. If there is a man in the middle, the session keys will be different. I prefer the second method because a passive eavesdropper does not find out who is communicating with whom. You can do this with the pgp signature functions in PGP Tools. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLW7drcGoFIWXVYodAQHKRwQAj4zOGBqNeT6w6VeHRn6QMk5sAmYAep9M MpiVYTEdcSTzW7C2TP9RF/f1cqIpPy4pBK5ATRmGCnaDe12FxM4iIZVMVcprS7Ao XaL52RR/0d0Tctt6YhQBMaODaosPm0Nbd+R3ztRRpugCU37lAFTWLHTuDAVlNqzl yX/8iTSbyGo= =gZ8U -----END PGP SIGNATURE-----

2 1

Re: 1984 Shirt Ordering Info
by markh＠wimsey.com 17 Dec '03

17 Dec '03

> > 1984 NSA T-shirt ordering information: > A reminder: The shirt is available for viewing at > http://phoenix.aps.muohio.edu/users/jdblair/t-shirt.html >... > It will be available soon via anonymous ftp. I will post the address > when that is confirmed. available from ftp.wimsey.bc.ca:/pub/crypto/shirt

1 0