December 2003 - cypherpunks-legacy

Clipper in the Commics
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Well, I guess this is about as mainstream as the issue can get. In today's paper, the comic strip "On the Fast Track" is about the clipper chip. It suggests that we need a way to spy on government in return (other than by bribery). To say that I was surprised to see a clipper statement in the 'toons would be an understatement. Looks like our campaign to inform the public is paying off. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkKPYVVkk3dax7hlAQEg9AP5AXe5mr++9Af3QCcyozIKqKqp5FXadKqG Eaj+2An+loxXafaqNVwuKoZJMemA68yRYKguIZKjk6kQPhw3zp5D1h6Ynj3OoUvI AhPHHnDBiA+ehz5FSZfQESdRJtjM+6qQ/vcbgnSBeFvEEYi4531Q9t36pQJcWB8X n2Jlr6U3jjE= =BVHe -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

email packet length size
by hughes＠ah.com 17 Dec '03

17 Dec '03

Message length quantization is necessary for security in a remailer network. Right now there's not enough traffic through the remailers to warrant more than one such quantized length. What length should that be? This information can be readily calculated from the length distribution of the current messages passing through the remailers. If only one or two remailers would instrument their devices in order to record just lengths, that would provide the necessary data. Any volunteers? My complete guess is that it's going to be around 4-5 KB. Eric

1 0

Problem in draft FIPS `CRYPTOGRAPHIC SERVICE CALLS'
by M.Gream＠uts.EDU.AU 17 Dec '03

17 Dec '03

Anyone producing cryptographic software elements should take notice of the recent FIPS draft standard on `cryptographic service calls' dated 23 May 1994. It attempts to define data structures and "function" calls towards the goal of making better interoperability between applications and crypto "libraries". However, you'll notice that both DSA and RSA modulus sizes are constrained to a `MODULUS_SIZE ' of 64 `BYTE's (unsigned char). This permissible maximum of 512 bits is too small, and a violation of FIPS-186 s.4.1. amongst others. I like this FIPS, but it would be pretty useless if it contained the above restriction. If you're also a software developer, make a comment to NIST on the issue, so they do change it. Matthew. -- Matthew Gream <M.Gream(a)uts.edu.au> -- Consent Technologies, (02) 821-2043 Disclaimer: From? \nem speaking_for(Organization?)

1 0

Re: RemailerNet
by Jonathan Rochkind 17 Dec '03

17 Dec '03

Part of our disagreement/misunderstanding might be in differing conceptions of the form the remailer net should take. > There should be two anonymous IDs, one for sending, one for > receiving. You seem to be talking about a Julf-style anon system, where the system knows who you really are. If the system is corrupt, if Julf were an NSA agent, then the entire system is compromised and useless. I like the cypherpunks remailer concept better, where each link in the chain only knows the next link in the chain, and security is achieved by multiple links. If several of the links are actually NSA agents, your security is reduced, but not compromised completely. If you've got a chain of, say 10 links, even if 7 of them are evil NSA agents, you still can probably retain your anonymity. Return addresses are accomplished by encrypted "resend-to:" blocks. It seems much preferable to have a system where it isn't neccesary to trust any one net entity completely, as it is in a Julf-style anon-ID system. [Of course one could use a combination of both in communications too, but I wouldn't feel safe unless my anonimity was safe even if the Finish FBI raided Julf's site.] When looked at with this goal in mind, I think maybe the newsgroup as a method of passing remailer net information makes a bit more sense. I don't think the possibility of the newsgroup being spoofed is actually fatal to the system. Let's examine ways in which it could be attacked: 1) The Enemy could introduce completely made-up "i'm here" messages, pointing to non-existent remailers. This doesn't harm anything at all when combined with a "ping"ing of remailer sites, as I've suggested. (One idea would be just to periodically mail all your remailers with the resend-to: being yourself, to make sure they exist, and are forwarding mail at least some of the time). 2) The Enemy could announce his own Evil-remailers to the net. These remailers would in fact exist, but would do evil things designed to compromise the net. What could they do? They could publicize all messages they get. Again, as long as you have 3 or 4 non-evil remailers in your chain, this doesn't really compromise your anonymity. You can decrease the risk further by only using remailers whose announced keys were signed by a trusted source. The evil-remailer could also just drop all communications in the bit bucket. This doesn't compromise security, but does make the remailer net unusable. By periodically pinging the remailer sites as I've suggested above, this risk can be minimized. If you've pinged the site 25 times, and all 25 times the remailer has forwarded your ping back to you, then odds are that it isn't dropping any messages in the bitbucket. (remember, the evil-remailer can't tell the difference between your ping a a normal remailer message, if done correctly.) 3) The Enemy could intercept announcement messages from good remailers, and replace their public key with his own. He could then intercept all mail to this good remailer, and read it, and forward it on, or drop it in the bitbucket. Using web-of-trust for signed remailer keys should help minimize this risk. 4) Denial of service: The enemy could intercept the announcement messages, and keep them from getting to the newsgroup. This doesn't compromise the security of the net at all, but is annoying. I can't think of any way to avoid this risk, but I think it might be acceptable, because it doesn't actually compromise any security, and would be fairly dificult for the enemy to do for long without being detected. 5) The enemy could intercept announcement messages from good remailers, and replace both the public key and address with his own. This is really just a combination of several of the previous attacks, nothing new.

2 1

Encryption (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Received this in the mail today. --Mike Forwarded message:

1 0

Re: Voluntary Governments?
by dance＠cicero.spc.uchicago.edu 17 Dec '03

17 Dec '03

[JWS writes:] >Well, yeah. And this is a service. When individuals exercise their >freedoms, they frequently interfere with other people's freedoms. To >resolve this conflict, it is necessary to "control the actions or the >behavior of" individuals such that they don't interfere with each >other's freedoms. So they enter into a contract with each other >under which this is accomplished, but a contract isn't worth the paper >its written on unless somebody enforces it, so they hire a policing agency, >the government. That agency is providing a useful service. Well, as a tribalist, I don't agree that this "useful service" is ultimately necessary. I *do* agree, however, that government is necessary *at the moment.* As a species we have not evolved enough to learn to take personal responsibility for our actions, therefore an external restraint system is necessary. My particular slant on anarchy calls for personal responsibility, which I believe renders an external system of superintendence unnecessary. But as I said before, this species isn't ready. >> It would be great if government could be a service provider, or simply feel >> responsible for those it governs--but then it would not be a government any >> longer. > >I don't agree with that last clause. I would rather have Customer Service than government, but I don't believe I can have both. Write me some more and hear my other stupid ideas. ;) _/_/_/ _/_/_/ _/_/_/ _/ _/ The ancients who wished to _/ _/ _/ _/ _/_/ _/ illustrate illustrious virtue _/_/_/ _/ _/ _/_/_/ _/ _/ _/ throughout the world first _/ _/ _/ _/ _/_/_/_/ _/ ordered well their states. _/_/_/ _/_/_/ _/_/_/ _/ _/ _/_/_/ Wishing to order well their states, they _/ first regulated their families. Wishing to regulate their families, they first cultivated their persons. Wishing to cultivate their persons, they first rectified their minds.... --THE GREAT LEARNING (Text & Commentary, IX)

1 0

RemailerNet
by Jim Dixon 17 Dec '03

17 Dec '03

In message <199408042200.SAA07928(a)cs.oberlin.edu> Jonathan Rochkind writes: > > * Rochkind's stability-from-being-paid and web-of-trust notions > > I'm not sure I like being credited with the "stability from being paid" > notion. I think there _is_ stability from being paid, but I think > if the infrastructure depends on it, it's not a good infrastructure. If you look at the history of the Internet, there have been some free Internet services, but the ones that have thrived have been paid. (If the government or your school subsidizes your Internet access, it may appear free to you, but the staff all get their paychecks every month. > The system should be able to create a stable top-level infrastructure > on top of an inherently instable environment, with remailers > going up and down, and popping into existence, and dying. It should > route around dead remailers, like the internet itself. If it is built like the Internet, it will do just that. > > The use of alt.x groups to exchange gateway information does not seem > > to add anything to this system; in fact it would seem to make it easier > > to spoof the system. > > It _would_ make it easier to spoof the system, but I think it does add > several very important things: > 1) New remailers can easily announce themselves to the remailernet. > [Whether they are to be trusted or not should depend on pgp-signed keys > and web of trust, but the newsgroup provides an way to announce yourself > to the system, and have that announcment by automatically dealt with > by all participating parties] There are two things being blurred together here which should be kept distinct. The first is gateway-to-gateway announcements. The second is advertising of the RemailerNet gateways to the wider world. Generally I would expect gateways to introduce themselves to one another privately and negotiate an understanding. Part of this will normally take place off the Net. This is an infrequent event, and so can be time-consuming and expensive. The basic web of trust is that between gateways. Once gateways had entered into a relationship, there would be frequent encrypted private traffic between them which would maintain the trust. Gateways can also announce their presence to the wider world, and publish their public keys. This could be done in alt.RemailerNet or it could be done in alt.internet.services, or any of several other places, or all of these. Any information published in alt.RemailerNet would be suspect, because it could be a complete fabrication or it could be a modified version of the correct posting. Gateways could be started up by anyone and some postings to alt.RemailerNet would be spurious. The "gateway" could be a sink, just tossing traffic sent to it, or it could copy all messages to a TLA before forwarding them. The user-gateway web of trust would therefore be far more problematical. I think that this would function as a market, and unreliable and untrustworthy gateways would be driven out over time. At the same time, there would be a constant bubbling up of new remailer networks, because the software would be freely available and the protocols well defined. The longer lasting gateways that proved trustworthy would in time join established networks. > 2) Users (not people operating remailers, people using them) could make > use of the newsgroup, to compile a database of remailers, and make long > remailer chains. Users could have automated software doing this. Compiling a list of remailers, sure. But if you let the user control how messages are chained, you are inviting real traffic analysis. The user should only be able to specify his destination and the level of security desired. > [snip] > These are really two facets of the one problem, of allowing a user > or remailer who has just arrived on the seen to quickly get a list > of remailers, and make use of them, all automatically. That's sort of the > super-set problem which encompasses the other two, and whose solution solves > the other two. > > I don't think it's a coincidence that the newsgroup system solves these > two problems at the expense of security (the newsgroup makes it easier > to spoof). If the newsgroup is used as described above, RemailerNet itself is not threatened; it is only the users that can be spoofed. This level of risk is unavoidable. But gateways would never use the newsgroup for inter-gateway communications, because (a) it would be redundant (they can talk directly once they know each other and (b) you would have to assume that anything posted to a newsgroup had been compromised. > The fact is, that even remailers exchanging mail _can_ be spoofed, if not > quite as easily as the newsgroup idea. It seems to be a premise of cryptographic > protocols and schemes, that you've got to assume a worst case and get a system > working where even under the worst case, everything works. Well ... if you follow this line of reasoning too far, you are just saying 'nothing can be trusted, so don't bother being careful'. If I were running a remailer and someone posted his address in a public newsgroup and said "hey, here I am, and I run a really good remailer" I wouldn't trust him just because he signed it. I would get in touch with him, ask around about him, maybe run some low-security traffic through his remailer for a while. Then after some time I would raise my estimate of his trustworthyness. If he dropped traffic, if someone reported that something that they had sent privately had been compromised, I would drop him. > I agree that it seems a good idea for the SMTP RFCs to be used to exchnage > info, ... etc You already use the SMTP RFCs to exchange information -- this message comes to you courtesy of those RFCs. Email can have very complex headers and they can be in pretty much any order. This makes it difficult to write email software. I am simply suggesting that we allow only the minimal few headers, with possibly a few added to support RemailerNet protocols. ASSIGNMENT OF ANONYMOUS IDs These types of traffic are possible, where 'known' means your ordinary email address: known --> known known --> anon anon --> known anon --> anon There should be two anonymous IDs, one for sending, one for receiving. I assume that anonymous IDs are never assigned automatically. If you want an anonymous ID pair, you ask the gateway for one, possibly enclosing your public key encrypted with the gateway's public key. The gateway returns your new IDs, encrypted if you you gave it a key. The 'send' anonymous ID is used for sending messages from someone else's account. The gateway converts it into a 'receive' ID before forwarding your message. The 'receive' ID appears on your email after it goes through the gateway and can also be passed to other parties who want to send you remailed messages. Additional security can be added by using a digital signature. The gateway could be instructed ignore messages lacking such a signature or to take some specified action. ELECTRONIC CASH Ecash is easily added to such a system. 'Emints' would generate a message containing a bank identifier and an encrypted value. This would be the ecash. It could be given to anyone or anything. Messages containing ecash would be encrypted. The emint would credit the account of the first person to present it, and would bounce any copies presented subsequently. Giving change would be trivial. -- Jim Dixon

2 1

Mea Culpa; email blunder
by corpuz＠internex.net 17 Dec '03

17 Dec '03

I accidentally hit the send again function instead of the delete function on an email file that I was processing. No need to respond -- I am apolitical, didn't even read it, and don't care what it said -- and I will try not to bother you in the future. Again, sorry for any inconvenience.

1 0

Improved remailer reordering
by Hal 17 Dec '03

17 Dec '03

Here is an interesting result I came up with while lying in bed last night. It has to do with the latency/reordering issue. As Eric and others have pointed out, what you want with a remailer is to mix up the messages so you can't link incoming to outgoing one. This implies that you have more than one message to work with, otherwise you don't have anything to mix. And this implies some necessary latency; you have to wait until you have more than one message on hand before sending things out. However, note that latency in itself is generally bad. You shouldn't wait longer than you need to to attain the desired degree of mixing. One simple way this can work is by batching messages up. This could be done by running the remailer at regular intervals, choosing the intervals so that you tend to have enough messages on hand based on average arrival times. But a simpler way is to simply wait until you have N messages on hand, then to promptly mix them up and send them out. This way you have a predictable number of messages to mix each time. Note that in a system like this you might as well send them all out as soon as the Nth message comes in; there is no point in holding on to them for any extra time as it adds latency without improving mixing. The interesting thing I came up with is that there is a simple modification to this batching scheme which gives better mixing with less average latency. To describe it I need some mathematics. One way to measure the benefit of a given degree of message-mixing is by looking at the uncertainty of position of a given message coming in and going out. If we had batches of 4, for example, a given message coming in has its position known with certainty. Going out, it may be any one of four messages, and the probability of it being any one of them is 1/4. A measure that is used for situations like this is entropy. It is defined as the negative of the sum of the product of each probability times its log. (I will use log to the base 2 for the calculations for simplicity.) That is, E = - sum pi * log pi. For the incoming message, we have just {1} as the probability distribution. We know exactly where it is and the probability is 1 that it is there. For the outgoing we have {1/4,1/4,1/4,1/4} as the distribution. It may be any of these four messages with equal probability. Applying the entropy formula to these we get E=0 for the incoming, and E=2 for the outgoing. If we had batches of 8 instead the distribution would have been {1/8,1/8, 1/8,1/8,1/8,1/8,1/8,1/8}, for E=3. Note that entropy is a log measure like the Richter scale. An increase from 2 to 3 is just as big as an increase from 1 to 2. To consider different batching strategies, consider a remailer where the messages come in one per hour, at 1:00, 2:00, 3:00, etc. A four-fold batching strategy would save up messages until there were four, then randomly reshuffle them and send them out. For this case we'd wait until the 4:00 message, then shuffle numbers 1,2,3,4 and send them out, say, at 4:01, in some random order, maybe 2,1,4,3. Then we'd save up more until 8:01 at which time we might send out 7,5,8,6. Note first that there is no point in waiting till after 4:01; once we have the four messages we might as well go. Note too that the average latency for messages in this system is 1.5 hours (the four messages have latencies of 0,1,2 and 3 hours). Four-fold batching produces entropy E of 2 and average latency L of 1.5 hours. Three-fold batching has E=1.58 and L=1; two-fold batching has E=1 and L=.5. Generally, N-fold batching has E=log base 2 of N, L=(N-1)/2. Okay, with this background, we can consider the alternative which gives improvement. It is to have some "rollover" of messages. Instead of sending all of the messages in a batch out, you retain some of them and use them to start the next batch. I call an (M,N) rollover system one which uses batches of M messages but retains N as rollover, sending M-N out each time. By this definition the four-fold latency system above could be called a (4,0) rollover where the 0 means we don't roll any over and send them all out. The simplest rollover case is (2,1). This uses batches of 2 messages, where you choose one at random to send out and keep one. Then when the next message arrives you again choose at random between the new one and the old one, send that out, and keep the other. In the timing example above, suppose we have the message from 1:00. Then at 2:00 when that message arrives, we pick one of the two messages at random and send it out. Suppose it is number 2. We retain number 1 until 3:00. Then we choose at random between 1 and 3. Maybe we pick 1 this time. We keep 3 until 4:00, then choose at random between 3 and 4, and so on. Each message has a 1/2 chance of being sent out immediately, a 1/4 chance of being sent out after 1 hour, a 1/8 chance of going out after 2 hours, a 1/16 chance of going out after 3 hours, and so on. This means that the outgoing probability distribution is {1/2,1/4,1/8,1/16,...}. The entropy of this probability distribution is 1/2+2/4+3/8+4/16+5/32+6/64+... from the formula above, which works out to be 2. The average latency is 0+1/4+2/8+3/16+4/32+5/64+..., which works out to be 1. So, (2,1) rollover batching produces E=2 and L=1. This is the same entropy as (4,0) batching with less average latency. Alternatively, it is more entropy than (3,0) batching with the same average latency. It also has the advantage that you never have to hold more than two messages, compared with three or four for the alternatives. So this scheme has several ad- vantages over simple batching. Now, it does have one disadvantage, which is that there is no upper bound on the latency of a message. With the (4,0) batching you may have had more latency, but you at least know that nothing would have more than 3 message-times. With (2,1) there is a small chance of having very large latencies. In fairness, though, it should be pointed out that in a real system messages arrive at irregular intervals rather than the clockwork model I used above, so even (4,0) would have random latency ceilings. Also, it might be possible to modify (2,1) so that messages never waited more than some maximum number of hours without seriously hurting the entropy. I haven't tried working out the details of other rollover methods, but I suspect that this will be a general method of improving entropy at little cost in latency. In real life we would want large entropies but starting with a (10,0) I'll bet many rollover systems would be superior. Hal

2 1

(none)
by Jeff Gostin 17 Dec '03

17 Dec '03

Blanc Weber <blancw(a)microsoft.com> writes: > who cypherpunks Good question, although it isn't the greatest english... :-) A wise man said cypherpunks assume privacy is a good thing. They are devoted to cryptography. They love to practice playing with public key cryptography and anonymous mailers. They write code. They don't care if you like the software they write. So, that's "who cypherpunks". :-) --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

fast 386 DES code figures
by Phil Karn 17 Dec '03

17 Dec '03

To see if software DES could really be made acceptable in a IP security protocol, I've been bumming cycles out of my old DES code. I've completely translated the encrypt and decrypt routines to assembler, with no calls or jumps inside either routine. I picked up Richard Outerbridge's seriously clever initial and final permutation algorithm from Schneier, along with a few of his other tricks. The bottom line: about 38,373 encryptions/sec (2.456 megabits/sec) on a 50 Mhz Intel 486 running in 16-bit real mode. This includes the overhead of the C loop that calls the encrypt function and prints a status line every 10,000 loops. The code would probably run faster if assembled and run in 32-bit native mode, as this would eliminate a lot of 1-clock operand size prefixes (I do many 32-bit operations). Oh, by the way, if I eliminate the permutations the speed goes up to about 42,986 encryptions/sec (2.751 megabits/sec), an increase of about 12%. That says I should be able to do triple-DES at about 13,777 blocks/sec (881.7 kbit/sec) although I haven't tried it yet. What still bugs me is that Schneier lists the speed of one commercial DES implementation as 40,600 encryptions/sec on a 33 Mhz 486. I just don't see how that's possible without using a lot more memory for lookup table space (I use only 2K, which is nice in a DOS environment). In any event, this should be enough for a T1 link (half duplex) as long as too many cycles aren't needed for things like routing packets. :-) Phil

3 3

latency
by merriman＠metronet.com 17 Dec '03

17 Dec '03

Looks like we had a little latency of our own on the list the last couple of days. Anyone know what happened? Dave Merriman -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi3uZ2MAAAEEALWQtxX77SZSaFls6cVbPp+fZS4MNyKK3ZFYQo0qWyj+0tMq YgRTPRJRaCQixo63RttknogfPp514qdVMZw5iPeOXmD+RxrmTTwlbGqA7QUiG1x5 LG2Zims5zk4U6/rt8hwLh0/8E4lIb9r5d31qc8L1A9Twk/cmN8VrTvyYOzAZAAUR tClEYXZpZCBLLiBNZXJyaW1hbiA8bWVycmltYW5AbWV0cm9uZXQuY29tPokAlQIF EC3uaE3Fa078mDswGQEBbI8D/0FiwDcbfeNyDVJ+7EIWHjIxVkIGu+ArYUEllR3G SBHVZ9Vh7n8bNXeNHMnG5cZ23TLMVvweyhxFS+cDi+I7omeDNr6x65z500LxfUvL K5bSuSiBVkTp2z+/iojY/662JwKHzEEunuJ4CO8Yhxy11CdeszEX7DpXzRxLL92r EmO2 =4ZfP -----END PGP PUBLIC KEY BLOCK----- Finger merriman(a)metronet.com for PGP2.6ui/RIPEM public keys/fingerprints.

1 0

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408051528.LAA18523(a)cs.oberlin.edu> Jonathan Rochkind writes: > You seem to be talking about a Julf-style anon system, where the system > knows who you really are. If the system is corrupt, if Julf were an > NSA agent, then the entire system is compromised and useless. If you are using unmodified Internet hardware and TCP/IP as the underlying transport system, then your point of entry into a remailer network definitely knows which machine is originating a message and the point of exit definitely knows where it is going. If your transport system is the email system, the same holds true because email runs on top of TCP/IP. While fiddling with email headers may make you feel secure, it gives you no protection. It is a large project (say 30,000 lines of code, some of it at the kernel level) to build a remailer network which does not use SMTP and TCP/IP. >From the scale of efforts that you are talking about, I assume that you do not intend to do this. So the remailer gateways know the source and destination addresses, they know your electronic identity. This may or may not lead them to your physical identity. That can be concealed fairly easily, especially in large institutions with poor control over their network resources. But this has nothing to do with our discussion now. > I like the cypherpunks remailer concept better, where each link in the chain > only knows the next link in the chain, and security is achieved by > multiple links. If several of the links are actually NSA agents, your security > is reduced, but not compromised completely. If you've got a chain of, say > 10 links, even if 7 of them are evil NSA agents, you still can probably retain > your anonymity. Return addresses are accomplished by encrypted > "resend-to:" blocks. It seems much preferable to have a system where it > isn't neccesary to trust any one net entity completely, as it is in a > Julf-style anon-ID system. [Of course one could use a combination of both > in communications too, but I wouldn't feel safe unless my anonimity was > safe even if the Finish FBI raided Julf's site.] Promiscuity leads to infection. Each contact with a new RemailerNet gateway increases the probability of your being compromised. If you modify the proposed RemailerNet to allow reposting at gateways, you have all of the benefits of the system described above, without the risks. Reposted messages would be encrypted with the far gateway's public key. The near gateway would then have no idea of the ultimate destination of the message. In a well designed system, the far gateway would also not know the identity of the sender. > When looked at with this goal in mind, I think maybe the newsgroup as a method > of passing remailer net information makes a bit more sense. > > I don't think the possibility of the newsgroup being spoofed is actually > fatal to the system. Let's examine ways in which it could be attacked: > > 1) The Enemy could introduce completely made-up "i'm here" messages, pointing > to non-existent remailers. ... > 2) The Enemy could announce his own Evil-remailers to the net. These remailers > would in fact exist, but would do evil things designed to compromise the net... > 3) The Enemy could intercept announcement messages from good remailers, and > replace their public key with his own. ...He could then intercept all mail to this > good remailer, and read it, and forward it on, or drop it in the bitbucket. > 4) Denial of service: The enemy could intercept the announcement messages, and > keep them from getting to the newsgroup. ... > 5) The enemy could intercept announcement messages from good remailers, and > replace both the public key and address with his own. This is really just a > combination of several of the previous attacks, nothing new. In the early to mid 1950s the FBI set out to penetrate Communist Party USA cells. At some point, when the fear of the Red Menace began to recede, people began to talk. The communists said, "you could always tell who were the FBI agents. They were the ones who paid their dues." The FBI was actually providing most of the funds for CPUSA. If anyone cared enough, what they would do is (a) put up enough remailers so that they were, say, a steady 80% of those announcing in the alt.x group; (b) provide a good, reliable service nearly all of the time; and (c) drive the other 20% out of business with a steady disinformation campaign (rumors, complaints, etc) and other more aggressive tactics. The FBI types running (a) and (b) would be well funded and they would be the sort of steady, unimaginative people who run small businesses well. The CIA field agents masterminding (c) would be very well funded network freaks, some of them ex-hackers. They could operate outside the USA and pay little or no attention to US laws. Pity the poor 20% in the face of such attacks. Any traffic sent through this remailer network would have only a tiny chance of getting through without being compromised. If you picked 5 remailers, the chances of all being non-FBI would be about .2^5, 3 in 10,000. The other 9,997 messages would be copied immediately to Langley. The proposed RemailerNet could be attacked in much the same way. But if the network were widely distributed so that gateways were in different legal jurisdictions and different countries, and if most of the people involved knew one another, it would be more difficult to compromise it. -- Jim Dixon

3 2

Re: Remailer ideas
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408051709.AA14763(a)ah.com> Eric Hughes writes: > Jim Dixon analogizes between the Internet and remailer networks. The > analogy has some merit, but yet breaks down badly with the very first > point: > > * all packets should be acknowledged > > This is not the way the Internet works. There are some problems with vocabulary here and some conceptual problems. The objective is a system which is highly reliable and resistant to traffic analysis. If you have three messages in, one 10 bytes long, one 1000 bytes long, and one 1,000,000 bytes long, and you send them out to three different destinations, it does not take genius to see which is which, no matter what order they are dispatched in. But if you send them out as packets, each say 4096 bytes long, with all packets acknowledged, and the routing of the packets is random, and noise has been introduced ... traffic analysis is very difficult. TCP/IP is designed to work in an environment which is unreliable but also unhostile. The sliding window algorithm and acknowledgement at the message level is suitable for that environment. TCP/IP has been optimized for speed. [stuff omitted] > Further, in email, there's currently no notion of a connection. The internal functioning of RemailerNet is not the same as the functioning of the email system. All RemailerNet communications are reliable. Packets are acknowledged and the acknowledgement includes a hash of the packet contents, so that the packet cannot be tampered with. Acknowledgements will in general take different routes from packets. > * users should communicate with trusted gateways > > This point is only half true, because the analogy only subsumes one > kind of trust. For remailers there is both trust in delivery and > trust in silence, the destruction of the message and information about > it. 'Trust in silence' is a good term. This can be enhanced in a number of ways. If you are corresponding with someone you know, you encrypt your messages. If you are corresponding with a stranger, you encrypt your message with the public key of a far gateway; then post it to the far gateway through a near gateway. The near gateway knows who is sending, but cannot read the message and does not know the destination. The far gateway decrypts the message before delivering it, so it knows the message and the destination, but not the sender. If you are sufficiently paranoid, you put your message inside yet another envelope, mailing it through the near gateway to a far gateway, which posts it on to another gateway, which finally posts it to its destination. Remailer gateways should be spread very wide geographically if the network is to be secure. If you are very concerned about anonymity, bounce a message through gateways in, say, the USA, Finland, Russia, and Ireland. If your concerns are about your employer, say, the probability of his getting at four different gateways in four different jurisdictions simultaneously is vanishingly small. If your concerns are about governmental authorities, they are not that much higher. -- Jim Dixon

1 0

Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408051716.AA14773(a)ah.com> Eric Hughes writes: > Back to the start, I guess. > > > Specifically cryptographic elements are easily added to the system > > * packets can be delayed for random intervals > > Let me repeat: > > REORDERING IS OF PRIMARY IMPORTANCE FOR REMAILER SECURITY. > > ADDING LATENCY IS NOT. No need to shout, we heard you the first time. ;-) In a system that is carrying continuous traffic, random packet delay is functionally identical to packet reordering. If messages are fragmented, random delays on sending packets out is functionally identical to reordering. More importantly, RemailerNet as described defeats traffic analysis by more significant techniques than reordering. Reordering is a weak technique. The introduction of noise, 'MIRV'ing of messages, fragmentation of messages, random choice of packet routes, and encyphering of all traffic are stronger techniques. -- Jim Dixon -- +-----------------------------------+--------------------------------------+ | Jim Dixon<jdd(a)aiki.demon.co.uk> | Compuserve: 100114,1027 | |AIKI Parallel Systems Ltd + parallel processing hardware & software design| | voice +44 272 291 316 | fax +44 272 272 015 | +-----------------------------------+--------------------------------------+

4 4

Re: Remailer ideas (Was: Re: Latency vs. Reordering)
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408061404.KAA02300(a)cs.oberlin.edu> Spencer Mullen writes: > Jim Dixon writes: > > >Commercial remailers would probably be very concerned with legal > >issues, both criminal (pornography, etc) and non-criminal (copyright > >violations). > > It would seem that remailers shouldn't be anymore accountable for > passing on illicit pornography than the postal services are today. I really do not want to try to argue the legal issues here; I am not a lawyer and claim no expertise. At a practical level, if you were running, let us say, an Internet Service Provider (ISP) and offered remailer services, you would in time attract the business of people who used your services for various unlawful purposes. You could not stop this without going through everyone's private mail. This would itself probably be illegal and certainly would lose you business. I understand that Playboy magazine spends lots of money pursuing people for copyright violations, and that criminal charges have been filed by the authorities in Tennessee or Arkansas against someone in California who sent them pornographic materials over a telephone line. The Post Office has what is called in the UK "crown immunity" against such prosecutions. So do "common carriers" in the USA. They are given special legal status. I do not know, but I believe that the telephone companies are legally common carriers. As a remailer gateway operator, you would probably have to argue things out in court, which could be very expensive. In the case of criminal charges, you would have to expect to lose your equipment for some time, and perhaps your freedom. I suspect that legally the key step would be to never store messages for any period of time. It would be prudent to erase them as soon as their receipt was verified. This would also save disk space, and it would be in line with the 'trust in silence' ethic. I would do this and then publicize the fact that I did so widely. This would discourage public prosecutors, who really don't like to do futile things. And I would incorporate the gateway and make sure it wasn't worth a great deal. This would discourage civil suits; clients get very irritated when they win the lawsuit and find that after all their legal expenses the target has filed for bankruptcy. -- Jim Dixon

1 0

Remailer listings/strategy
by merriman＠metronet.com 17 Dec '03

17 Dec '03

This may have been hashed out in a previous incarnation, but on the subject of remailers and their availability, why not just have each one broadcast a message of it's availability periodically (hourly? every 4 hours?) on, say, the Cypherpunks mailing list. Then, each remailer could also listen in, read in who's up, and if it doesn't hear from a remailer within some period of time (or some number of scheduled broadcasts), assume that it's down until it hears from that system again. This would also allow individuals to maintain personal listings of available remailers, as well, and automate the process of keeping track of what remailers are up/down/available. The additional traffic wouldn't seem to be _too_ much of a burden, those individuals who didn't want the broadcasts cluttering up their mailboxes could filter them out, and doesn't require massive effort or changes to implement (ie, new newsgroups, etc). What blazingly obvious thing am I missing here, or does it make too much sense to work? :-) Dave Merriman Finger merriman(a)metronet.com for PGP2.6ui/RIPEM public keys/fingerprints.

2 1

Re: A Different EFF on DigiTel Bill
by mnemonic＠eff.org 17 Dec '03

17 Dec '03

In article <199408291422.KAA10836(a)pipe3.pipeline.com.778170390>, John Young <jya(a)pipeline.com> wrote: >(If anyone cares, Mike posts zingers and unhealthy thoughts >like c'punks' regularly on list Cyberia-L.) Somebody's got to give those law professors some grief. --Mike -- Mike Godwin, (202) 347-5400 |"And walk among long dappled grass, mnemonic(a)eff.org | And pluck till time and times are done Electronic Frontier | The silver apples of the moon, Foundation | The golden apples of the sun."

1 0

RE: (none)
by Blanc Weber 17 Dec '03

17 Dec '03

From: Jeff Gostin <detailed explanation of 'who cypherpunks' are> So, that's "who cypherpunks". :-) ......................................................................... I really meant to ask 'where cypherpunks'. It had been a whole day & more without the hordes messages and my day seemed empty, without code or purpose, lacking controversy & jibber jabber. Blanc

3 2

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408061739.NAA05213(a)bwh.harvard.edu> Adam Shostack writes: > | If you are using unmodified Internet hardware and TCP/IP as the underlying > | transport system, then your point of entry into a remailer network > | definitely knows which machine is originating a message and the point > | of exit definitely knows where it is going. > > IP is not reliable & trustworthy. It it was, RFC931 ident > servers would be useful. ;) Theres source routing to make packets > appear to come from someplace else, and there is outright forgery, > which has limits, but can work quite well. My "if you are using unmodified ..." clause shows that I understand this. You can send from a very large network and forge your TCP/IP or (more difficult) Ethernet source address. But I can sit on the same network, build a table relating TCP/IP to ethernet (or whatever) addresses, and filter out messages that should not be there. There are commerical packages that do this sort of thing. Basically, this is a different topic. One problem is designing a generic software package and set of protocols that will allow you to route mail anonymously. This is a general problem. The hacking of specific networks is a different, if related, problem. -- Jim Dixon

2 1

What are Appropriate Topics?
by Blanc Weber 17 Dec '03

17 Dec '03

From: Timothy C. May "As for pure crypto being discussed on the list, there's a fair amount of that. I've posted my share of explanations of zero knowledge proof systems, dining cryptographers protocols, complexity theory, etc. I'm not saying this to defend myself, per se, but to note that these topics produced almost no discussion, almost no interest. Make of this what you will." I would say some reasons for the silence are that: . those who have read your comments have not thought extremely much about these themselves, so are not ready to add anything at the time. . your treatment of the subject matter was thorough enough that others don't feel the need to add further to your points. . you presented some deep thoughts that require time to digest & process. . the ideas you have about future events may have no present means to carry them out, good as they may be, and the way from point A to point B is not yet possible to achieve, as no practical method or system could yet be constructed. "* what happens to tax collection in an era of unbreakable cyphers? * how will the state react?" I would add: how will the general population react, when their security blanket is rendered ineffective? (* crypto anarchy issues from the perspective of the other side) * what's really holding back the spread of digital cash? What is the status of the work on this? I would like to keep up with its progress, if there are sources for the information. (besides The Economist) * where do we go from here? [Who's 'we', Kimosabe? :>) ] Where was anyone planning to go? There isn't anywhere else to go, physically, so it's necessary to resolve the problem of interacting in the same place at the same time with opposing methodologies. How does that work? (You aren't going to be invisible all the time, nor to everyone.) "..."Cypherpunks write code" is just one manifestation of the idea that we can actually change the world through the technological development of privacy-enhancing systems..." And privacy-enhancement isn't the *only* thing which will change the world, is it? There are other forces of cause-effect and influence which determine people's reactions to each other and to the problems of living. It lies within the broader subject of 'control': self-control, self-determination, as managed by the individual. This is where the controversy occurs - whether any or only some individuals shall be "permitted" to excercise it, and to what tolerable degree, and who shall be the "authority" that makes that decision. Much as some on the list would wish otherwise, "privacy-enhancement" goes in the direction of favoring the individual above the group, and this is difficult for some people to live with. I have seen some of Tim's ideas for future possibilities in terms of things which could come to pass or could be achieved, but I realized that I have not seen anything from him to indicate any projects which he is actually working on to bring these about. You do communicate a lot of information & ideas and do much work of explaining & clarifying fuzzy areas, which is excellent & valuable, but it still waits for others to put together the actual parts & pieces of things, if they are to be brought into actual existence as functional systems which can be employed and which can affect future conditions. "For want of a horseshoe, the war was lost." I would like to read more on what you have to say about this, as you are the pre-eminent poster on the list who likes to digress into abstract discussion. Blanc

1 0

Re: Voluntary Governments?
by Blanc Weber 17 Dec '03

17 Dec '03

From: Hal What does it mean to speak of a government in cyberspace? It is the government in physical space I fear. Its agents carry physical guns which shoot real bullets. ................................................................ Good point. What does it mean to speak of governance (or 'govenment') at all? Questions I would seek to have the answers to, in making decisions about government per se: . Who or what is to be governed? . What is inimical/destructive and to be regulated/prevented, or what is sacred which is to be upheld? . How will anyone come to know the difference? What difference does it really make (to anyone in the real world)? . Who is to do all the work of preventing or upholding (how do they qualify for the job)? . What is to be done about non-conformists to the rules (without contradicting the rules?) . When did you realize that you were an absolute authority on the subject? Blanc

6 9

RE: A Helpful Tip for Impatient Souls
by Anonymous User 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tommy the Tourist <nobody(a)CSUA.Berkeley.EDU> (Anon User) wrote: Welcome back, Tommy, we missed you! <g> Hope you're enjoying your new (CSUA) "home"... (Time for everyone to update their "chain.ini" file, BTW.) > Those wishing perhaps the ultimate in Cypherpunks ease-of-use > and greatest peace of mind, may find it useful to simply delete > everything that does NOT come from one of the following email > addresses: > tcmay(a)netcom.com > frissell(a)panix.com > sandfort(a)crl.com But Tommy ... if we did that, we wouldn't be able to read *YOUR* posts, either. Perhaps anyone who had a fetish for "ease-of-use", or was troubled by even seeing "cryptographically INcorrect" ideas (the analog of "politically correct") would tire of Cypherpunks altogether and just read the party line from Sternlight and Co. (tm). <g> The other problem is that if some brave, anonymous soul wanted to, let's say, "leak" the Clipper algorithm to the net, he'd have to forge e-mail from one of the "approved sources" above to gain an audience. However, despite your anonymity, Tommy, don't I see your tongue firmly implanted in your cheek? I sure hope so... I find the posts from the "approved three" individuals highly informative. OTOH, if *THEY* did as you suggested, traffic would be drastically reduced because it would only consist of those three talking amongst themselves. --- Diogenes -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkOdOeRsd2rRFQ1JAQHi4AP+LuJhvQPRiB0rZvDjuhfZwG+Q95N8WpTt 4lVNjLecXHKjFE6qn6tsed3/Fh/mwQUzRzx4kUihvRxqR3MAoBp1/SREXt+Rsd30 4zsxIs+BDkCCloX7rxVptZLJYG587oaIQOL0Wn/7MiDKChm/LoXrdbRwUeLL2gIU ZvvMDBBuYpI= =Vk7F -----END PGP SIGNATURE-----

2 1

e$: Cypherpunks Sell Concepts
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 1:38 PM 8/6/94 -0700, Blanc Weber wrote: >From: Timothy C. May >* what's really holding back the spread of digital cash? > > What is the status of the work on this? I would like to keep > up with its progress, if there are sources for the information. > (besides The Economist) e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$e$ I'll bite. I think that practically the only thing holding digital cash back at this point is pure and simple hucksterism. The whole concept of e$ (shorthand for e-money, with apologies to other currencies) should be promoted more. People who Really Work for a Living in Finance should be educated about the potential impact of strong crypto on money. There was a comment from Perry a while back which hit home with me. He said: >The problem is not a need for a killer app -- there are dozens. The >obstacle is regulatory problems, and finding a large and reputable >sponsoring organization (like a big bank). Now, that makes sense to me. It would go a long way towards legitimizing e$ and strong crypto if a largish bank put up a pilot project where they were exchanging, that is, making a secondary market in, real e$; maybe even DigiCash(tm). Ethier they or someone else could actually underwrite it, because you have to have both to make the market exist. Having heard what Eric has said about potential regulatory problems, I think that most of them are inadvertant obstacles, because they certainly weren't put there to obstruct e$, which didn't exist when they were written. I think if a reasonable (i.e. not illegal) business case were put to the regulators, they would (as usual) conform to whatever business interests want. I think that in order for the above to happen, some softening up of the targets has to occur. I understand that there are people on this list who are interested in selling seminars on strong crypto to the finance community. What about doing that in the context of a conference program to a larger audience? Get some famous heavies in the business world and in cyberspace to salt the conference flyer with. A certain EFFer comes to mind, among others who may be sympathetic to e$. Invite mostly businesspeople, preferably those in finance and finance operations, but also regulatory/political types. Teach them what e$ is and how it works. In return, e$vangelists can learn what questions their potential market actually need to have answered before e$ will be real. Maybe a deal or two happens, who knows? Repeat the process every year or two, but start the first one off as a "ground school" in the fundamentals. This thing doesn't have to be affiliated with the cypherpunks list any more than the original Computer Faire was affiliated with the Homebrew Computer Club. I wrote up an agenda when I was in the throes of the idea, and it's somewhere around here (I *know* it is...). Off the top of my head, I figured there'd be a schmooze reception the evening before, a brief primer on strong crypto and e$ in the morning, a schmooze luncheon (with speaker), a "where do we go from here" panel populated with business heavies in the afternoon, and a schmooze reception (with product demos, if any) in the evening to close. Notice it's very heavy on the schmooze. I challenge you to do huckster without lots of schmooze... This is not to be a volunteer effort. People who worked on this would get paid. The conference wouldn't happen if the attendance numbers weren't there. The participants will pay somewhat serious money to attend, and they will be interested in making money with the information obtained and contacts made at the conference. I'm pretty sure I want to do this one. I'd like to do it on this coast (Boston) because the money's over here, anyway, and there's still some technology over here that hasn't been made obsolete in the Bay Area. Besides, the east coast's halfway to Amsterdam, right? (yeah, I know, so's Anchorage...) So. Does anyone have any pointers? Cheers, Robert Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

3 2

CEB1B PREMEIERE ISSUE
by Gary Jeffers 17 Dec '03

17 Dec '03

* _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgp26uix.sig * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgp26uix.zip MacIntosh: * _DE:_ ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/pgp/mac /MacPGP2.6ui_beta.sit.hqx * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/PGP/MacPGP2.6ui_V1.2sources.cpt.hqx Other sites to look for the above mentioned files at: ftp.informatik.uni-hamburg.de /pub/virus/crypt/pgp This site has most, if not all, of the current PGP files. ftp.wimsey.bc.ca /pub/crypto/software/dist/US_or_Canada_only_XXXXXXX/PGP (U. S. and Canadian users only) See /pub/crypto/software/README for the characters for XXXXXXXX This site has all public releases of the freeware PGP from 1.0 through 2.6 and 2.6ui. black.ox.ac.uk (129.67.1.165) /src/security/pgp26uix.zip (MS-DOS executables & docs) /src/security/pgp26uis.zip (Unix, MS-DOS, VMS, Amiga sources, docs, info on building PGP into mailers, editors, etc.) There are several other versions of PGP here, including the MIT release. ftp.csn.net /mpj/public/pgp/ contains PGP shells, faq documentation, language kits. ftp.netcom.com /pub/dcosenza -- Some crypto stuff, sometimes includes PGP. /pub/gbe/pgpfaq.asc -- frequently asked questions answered. /pub/qwerty -- How to MacPGP Guide, largest steganography ftp site as well. PGP FAQ, crypto FAQ, US Crypto Policy FAQ, Steganograpy software list. MacUtilites for use with MacPGP. Stealth1.1 + other steganography programs. Send mail to qwerty(a)netcom.com with the subject "Bomb me!" to get the PGP FAQ and MacPGP guide if you don't have ftp access. ftp.ee.und.ac.za /pub/crypto/pgp soda.berkeley.edu /pub/cypherpunks/pgp (DOS, MAC) ftp.demon.co.uk /pub/amiga/pgp /pub/archimedes /pub/pgp /pub/mac/MacPGP ftp.informatik.tu-muenchen.de ftp.funet.fi ftp.dsi.unimi.it /pub/security/crypt/PGP ftp.tu-clausthal.de (139.174.2.10) wuarchive.wustl.edu /pub/aminet/util/crypt src.doc.ic.ac.uk (Amiga) /aminet /amiga-boing ftp.informatik.tu-muenchen.de /pub/comp/os/os2/crypt/pgp23os2A.zip (OS/2) iswuarchive.wustl.edu pub/aminet/util/crypt (Amiga) nic.funet.fi (128.214.6.100) /pub/crypt/pgp23A.zip /pub/crypt/pgp23srcA.zip /pub/crypt/pgp23A.tar.Z ftp.uni-kl.de (131.246.9.95) qiclab.scn.rain.com (147.28.0.97) pc.usl.edu (130.70.40.3) leif.thep.lu.se (130.235.92.55) goya.dit.upm.es (138.4.2.2) tupac-amaru.informatik.rwth-aachen.de (137.226.112.31) ftp.etsu.edu (192.43.199.20) princeton.edu (128.112.228.1) pencil.cs.missouri.edu (128.206.100.207) StealthPGP: The Amiga version can be FTP'ed from the Aminet in /pub/aminet/util/crypt/ as StealthPGP1_0.lha. Also, try an archie search for PGP using the command: archie -s pgp26 (DOS & Unix Versions) archie -s pgp2.6 (MAC Versions) ftpmail: For those individuals who do not have access to FTP, but do have access to e-mail, you can get FTP files mailed to you. For information on this service, send a message saying "Help" to ftpmail(a)decwrl.dec.com. You will be sent an instruction sheet on how to use the ftpmail service. Another e-mail service is from nic.funet.fi. Send the following mail message to mailserv(a)nic.funet.fi: ENCODER uuencode SEND pub/crypt/pgp23srcA.zip SEND pub/crypt/pgp23A.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. For the ftp sites on netcom, send mail to ftp-request(a)netcom.com containing the word HELP in the body of the message. World Wide Web URLs: (Thanks to mathew(a)mantis.co.uk) _________________________________________________________________ MACPGP 2.3 Program * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/MacPGP/MacPGP2.3.cpt.hqx * _UK:_ ftp://black.ox.ac.uk/src/security/macpgp2.3.cpt.hqx * _SE:_ ftp://isy.liu.se/pub/misc/pgp/2.3A/macpgp2.3.cpt.hqx * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/macpgp2.3.cpt.hqx * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/macpgp2.3.cpt.hqx * _US:_ ftp://soda.berkeley.edu/pub/cypherpunks/pgp/macpgp2.3.cpt.hqx.gz Source code Requires Think C. * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/MacPGP/MacPGP2.2src.sea.hqx -- version 2.2 only * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/macpgp2.3src.sea.hqx.pgp * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/macpgp2.3src.sea.h qx.pgp Documentation PGP is rather counter-intuitive to a Mac user. Luckily, there's a guide to using MacPGP in ftp://ftp.netcom.com/pub/qwerty/Here.is.How.to.MacPGP. _________________________________________________________________ OS/2 PGP You can, of course, run the DOS version of PGP under OS/2. * _DE:_ ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/pgp/2.6ui/pgp26ui-os2.zip * _US:_ ftp://ftp.csn.net/mpj/I_will_not_export/crypto_???????/pgp/pgp26os2.zip ftp://ftp.csn.net/mpj/README.MPJ for the ??????? _________________________________________________________________ AMIGA PGP 2.3 * _DE:_ ftp://ftp.uni-kl.de/pub/aminet/util/crypt/PGPAmi23a_3.lha * _US:_ ftp://ftp.wustl.edu/pub/aminet/util/crypt/PGPAmi23a_3.lha Source * _DE:_ ftp://ftp.uni-kl.de/pub/aminet/util/crypt/PGPAmi23a3_src.lha * _US:_ ftp://ftp.wustl.edu/pub/aminet/util/crypt/PGPAmi23a3_src.lha _________________________________________________________________ ARCHIMEDES PGP * _UK:_ ftp://ftp.demon.co.uk/pub/archimedes/ArcPGP23a _________________________________________________________________ DOCUMENTATION ONLY * _US:_ ftp://net-dist.mit.edu/pub/PGP/pgp26doc.zip * _UK:_ ftp://ftp.demon.co.uk/pub/pgp/pgp26doc.zip * _US:_ ftp://ftp.netcom.com/pub/mpj/public/pgp/pgp26doc.zip * _US:_ ftp://ftp.ftp.csn.net/mpj/public/pgp/pgp26doc.zip _________________________________________________________________ LANGUAGE MODULES These are suitable for most PGP versions. I am not aware of any export/import restrictions on these files. German * _UK:_ ftp://black.ox.ac.uk/src/security/pgp_german.txt * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp_german.txt * _US:_ ftp://ftp.csn.net/mpj/public/pgp/PGP_german_docs.lha Italian * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgp-lang.italian.tar.gz * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/PGP/pgp-lang.italian.tar.gz * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp-lang.italian.tar.gz Japanese * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp-msgs-japanese.tar.gz Lithuanian * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp23ltk.zip Russian * _RU:_ ftp://ftp.kiae.su/unix/crypto/pgp/pgp26ru.zip (MIT version) * _RU:_ ftp://ftp.kiae.su/unix/crypto/pgp/pgp26uir.zip (ui version) * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp26ru.zip Spanish * _IT:_ ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgp-lang.spanish.tar.gz * _FI:_ ftp://ftp.funet.fi/pub/crypt/ghost.dsi.unimi.it/pgp-lang.spanish.tar.gz * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp-lang.spanish.tar.gz Swedish * _UK:_ ftp://black.ox.ac.uk/src/security/pgp_swedish.txt * _US:_ ftp://ftp.csn.net/mpj/public/pgp/pgp_swedish.txt _________________________________________________________________ OTHER SITES Some cryptographic software is available from ftp://van-bc.wimsey.bc.ca/pub/crypto/software/. Read the README file and proceed from there. BBS sites: Colorado Catacombs BBS (See also the entry above for PGP 2.6) (303) 772-1062 Longmont, Colorado (2 lines) (303) 938-9654 Boulder, Colorado (free call from Denver CO, but 1 line) For free access: log in with your own name, answer the questions, then select [Q]uestionaire 3 from the [M]ain menu. Verified: This morning. Hieroglyphics Voodoo Machine (Colorado) Jim Still (aka Johannes Keppler), sysop. DOS, OS2, and Mac versions. (303) 443-2457 Verified: 5-2-94 For free access for PGP, DLOCK, Secure Drive, etc., log in as "VOO DOO" with the password "NEW" (good for 30 minutes access to free files). Exec-Net (New York) Host BBS for the ILink net. (914) 667-4567 The Ferret BBS (North Little Rock, Arkansas) (501) 791-0124 also (501) 791-0125 Special PGP users account: login name: PGP USER password: PGP This information from: Jim Wenzel <jim.wenzel(a)grapevine.lrk.ar.us> If you find a version of the PGP package on a BBS or FTP site and it does not include the PGP User's Guide, something is wrong. The manual should always be included in the package. If it isn't, the package is suspect and should not be used or distributed. The site you found it on should remove it so that it does no further harm to others. ARCHIE WHO? There are many more sites. You can use archie and/or other "net-surfing" tools to find a more up-to-date listing, if desired. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.7 mQCNAi4PT2QAAAEEAPPCZnrshEJ9PSnV+mXEwjM4kzJF0kyg2MnLMzo83vWI40ei jogncqdkXT0c2TQWg+Bsu9ckFoXdId0utumYv0aqd8yI/oU/DwJ1zJrqRL2PFbxe ZLofHoKFjvq1TiNiJq9ps3jW6iYS4IU1SzyKhjmyE+K0+WyrPPX0zg8FAL9FAAUR tCdNaWNoYWVsIFBhdWwgSm9obnNvbiA8bXBqQGNzbi5vcmc+IG1wajiJAJUCBRAu G3chZXmEuMepZt0BAZtAA/0Rw5mintlUDgHycNbeoyIiMHoLu8jWaCSaiGSt+dDU 1A/bUCo+gorv5TYxOClRf3XHjD6zSooWyUz3ehotrzPYLunhVOE2YBxPU+OvKFOc 37mcZrnXGBlF5NblnSYxp0186tGaTm7WMWx7NDlHT4GvhzHJQSOoo48ykDkKm/mk LIkAlQIFEC4PWbs/ZwY8hTPrxQEBKyMD/A7kv91C1ZZIRtkbC9k9lsWOgOnO8wG8 bGMajaco465Z5llWD+Y8QCMdSWcowtOBGfW0Wv1bZ1uebeCpg1L66pJ7C+BOExrk gPqRVCstLLiVerKGeSOZo3yXtxYKYX7mHQPrHp98ef7fUG4IiKS+S+znmGxpJwrV sHZRlhJ3hXUsiQCVAgUQLg9ZefX0zg8FAL9FAQFBTAQAh4u4Vun7WhPuL6fsXiXm paaGfeLtd3biRj/aOMAG1eHuhVdWejx71ormyKTdNB2YV56bpsE3JQ/KhBuYDo0N SkRnqeM2S+Ef7aZEg6Q44uXG52pqCZUldtCeYfOs3aLCR9SMlc6Y3zmpSwB1wKP0 5+tN9zruNYVKKBLWEIFAY7W0K01pY2hhZWwgUGF1bCBKb2huc29uIDxtLnAuam9o bnNvbkBpZWVlLm9yZz60IE1pY2hhZWwgSm9obnNvbiA8bXBqQG5ldGNvbS5jb20+ tChNaWtlIEpvaG5zb24gPDcxMzMxLjIzMzJAY29tcHVzZXJ2ZS5jb20+tCtNaWNo YWVsIFAuIEpvaG5zb24gPG1wam9obnNvQG55eC5jcy5kdS5lZHU+tC1EbyBub3Qg dXNlIGZvciBlbmNyeXB0aW9uIGFmdGVyIDI3IEp1bmUgMTk5Ni4= =rR4q - -----END PGP PUBLIC KEY BLOCK----- ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 | | | | / _ | mpj(a)csn.org aka mpj(a)netcom.com m.p.johnson(a)ieee.org | | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 | | |||\ ( | ftp://ftp.netcom.com/pub/mpj/README.MPJ -. --- ----- ....| | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAgUBLkq2xfX0zg8FAL9FAQFTNgP+MRZEelkRWavsKsLKgTpZEXix++Bhk8CW s1jgJkyFEgEjS5EDPsKUOZKT+peohlfSmMO1dvO4125b+g+jg3rI/BQQOnWA65PT 8ylmelaoQSrzPhbYvPCk/a7zzOqoGnfa3x4C3ECJBRKFvofaZOgo1pzzCxwwa/wW PtYKpgCtp34= =H24Y -----END PGP SIGNATURE----- Section 3: Michael Johnson's PGP bomb contribution. From: Michael Johnson <mpj(a)csn.org> Subject: PGP Time Bomb FAQ -----BEGIN PGP SIGNED MESSAGE----- PGP TIME BOMB FAQ There has been some confusion about the annoying "Time Bomb" in MIT PGP 2.6, as well as some other PGP version compatibility issues. This is an attempt to clear up some of that confusion. WHY IS THERE A TIME BOMB IN MIT PGP 2.6? In the process of negotiating for the right to distribute a fully legal version of PGP that the patent assignees agree doesn't infring upon their patents, MIT agreed to include an inducement for people to upgrade from the alledgedly infringing freeware PGP 2.3a to the clearly legal freeware MIT PGP 2.6 or the also clearly legal Viacrypt PGP 2.7. Folks, you may not realize it, but the RSADSI/PKP concession to allow a freeware PGP in the USA is BIG TIME GOOD NEWS! To induce a small incompatibility with a downlevel version of PGP with several bugs in it is a small annoyance by comparison. WHAT IS THE NATURE OF THE TIME BOMB? On 1 September 1994 UT, by your system clock, MIT PGP 2.6 will start generating encrypted message and signature packets with a version byte (offset 3) of 2 instead of 3. It will accept either 2 or 3 as valid. This means that messages from PGP 2.3a and old messages from MIT PGP 2.6 can be read by MIT PGP 2.6, but new messages from MIT PGP 2.6 cannot be read by PGP 2.3a. See pgformat.doc in the MIT PGP 2.6 distribution for the location and use of these bytes. This time bomb is activated by code in pgp.c that looks like this: #define VERSION_BYTE_OLD 2 /* PGP2 */ #define VERSION_BYTE_KLUDGE 3 ... boolean legal_kludge; int version_byte = VERSION_BYTE_OLD; ... /* Turn on incompatibility as of 1 September 1994 (GMT) */ legal_kludge = (get_timestamp(NULL) >= 0x2e651980); ... if (legal_kludge) version_byte = VERSION_BYTE_KLUDGE; Although a method for disarming the time bomb is obvious to the casual C programmer, disabling this feature invalidates the RSA license to use the program, and really doesn't gain you much for reasons that will become obvious below. HOW DOES THIS TIME BOMB AFFECT COMPATIBILITY WITH OTHER VERSIONS? The bottom line is that PGP 2.3a and before (as well as Viacrypt PGP 2.4) cannot read all of the latest PGP version formats, starting on 1 September 1994. Here is a summary of the version bytes generated and understood: Format generated Formats before/after understood Version 1 Sep 94 (all times) - ---------------------------- ----- ---- ----------- 2.3 2 2 2 2.3a 2 2 2 Amiga 2.3a.4 2 2 2,3 Viacrypt 2.4 2 2 2 2.6ui 2 2 2,3 MIT 2.6 2 3 2,3 Viacrypt 2.7, pkcs_compat=1 2 3 2,3 Viacrypt 2.7, pkcs_compat=2 2 2 2,3 Viacrypt 2.7, pkcs_compat=3 3 3 2,3 (Not mentioned above is MIT PGP 2.5, which was a buggy beta, nor several other versions that are outside the mainstream PGP project). If you are using one of the versions above that cannot understand version byte 3 messages, you should upgrade to one that does. The upgrade from Viacrypt PGP 2.4 to Viacrypt PGP 2.7 is only US$10, and also provides several other enhancements. As you can see, people with downlevel versions of PGP will not be able to read all PGP messages directed at them, nor will they be able to verify all of the signed messages they might wish to verify. It is also worth noting that none of the new versions have any trouble reading the old format messages. WHAT IS THE RSA KEY MODULUS LENGTH LIMIT? The RSA key modulus length limit for compatibility with all mainstream PGP versions is 1024 bits (military grade). I recommend the use of this length, at least for now. PGP 2.3a, running on some platforms (but not others), use to be able to generate and use 1264 bit keys. In addition, some people have hacked their own copies of PGP to generate and use longer keys (up to 8192 bits or some such crazy number). Distribution of these hacked versions under the "Pretty Good Privacy" trademarked name is not recommended, since it upsets the trade mark owner (Philip Zimmermann) and interferes with some of his long term plans to support longer keys in a more organized fashion. IS 1024 BITS LONG ENOUGH? Conservative estimates of increasing computing power, advancing mathematical knowledge, and the propensity of certain spy organizations to spend lots of money on these things say that 1024 bit keys are strong enough for at least 20 years or so. Less paranoid prognosticators say that such keys are good for hundreds of years. More paranoid prognosticators think that someone has already broken RSA and not told us about it, so no RSA key is safe. My opinion is that RSA keys with a modulus of about 1024 bits in length is more than adequate to protect most electronic mail and financial transactions. What do you think? HOW DOES THE STRENGTH OF RSA AND IDEA COMPARE? As implemented in PGP, the IDEA cipher used for bulk encryption appears to be stronger than the RSA cipher. In fact, to strengthen the RSA to the same level as the IDEA cipher (assuming a brute force attack), it would take an RSA modulus of about 3100 bits. WHY NOT ALLOW LONGER RSA KEYS, ANYWAY? OK, so you are more paranoid than me, and want the RSA key to be at least as strong as the IDEA cipher. Why isn't there a higher limit to the RSA key size? First, there is the minor problem that RSAREF and BSAFE (which are tied to the RSA patent license for the freeware and some commercial versions of PGP) have a key length limit of 1024 bits. Changing this involves negotiations with RSADSI/PKP, and could take some time. Second, allowing longer key sizes could create a Tower of Babel problem of incompatible PGP versions, since not all versions could handle these long keys. Third, the implementation of longer keys needs to be done in an orderly manner such that all mainstream PGP versions (Viacrypt, MIT freeware, BSAFE-based commercial, and possibly a non-USA variant) are first upgraded to accept, but not generate, the longer keys. After all PGP users can accept the longer keys, then PGP versions can start generating the longer keys with no interruption in service. It still makes sense to have a length limit for compatibility reasons. I have asked Philip Zimmermann to increase that to at least 4096 bits when he can, and I think that he will do that in an orderly manner if there isn't too much in the way of hassles with RSAREF and BSAFE licensing. If this isn't secure enough for you, shift to conventional encryption and manual (direct person-to-person) key exchange, making sure that your keys have at least 128 bits of entropy. This can be done with pgp -c or another private key encryption program called dlock that has the virtues of (1) NO patent problems, and (2) very strong encryption. (DLOCK is not nearly as user friendly as PGP, but what do you want for free?) HOW DOES PKCS BYTE ORDERING IN KEYS AFFECT COMPATIBILITY? PGP versions 2.2 and before generated key and signature block formats with a different byte order than derived from the PKCS standards. PGP 2.3 also generated this old format if you specified +pkcs_compat=0 in config.txt or on the command line. This old format is now obsolete. Unfortunately, the old format cannot be parsed by RSAREF or BSAFE, so PGP versions based on these crypto engines (like MIT PGP 2.6) cannot read those packets. Viacrypt PGP,

1 0