- cypherpunks-legacy - lists.cpunks.org

Re: possible solution to the anonymous h
by dclunie＠pax.tpa.com.au 15 Jan '93

15 Jan '93

> RSA has a patent on their algorithm. It's quite likely that I can't > even create a key pair without their permission, let alone use it. I am not familiar with the legal status of patents and software packages, but it seems to me that they can sell you a program and license you to use it, but forcing you to use one of their key servers instead of your own seems pretty far fetched. I would be very surprised if the law is clear cut on this issue, or has ever been tested. I gather software licenses are pretty hazy territory at the best of times without getting involved in patent law as well !@#$ david

2 1

Whitfield Diffie gets award
by gnu＠cygnus.com 15 Jan '93

15 Jan '93

SUN ENGINEER RECEIVES INTERNATIONAL AWARD; FOUNDED NEW FIELD OF SCIENTIFIC RESEARCH MOUNTAIN VIEW, Calif. -- January 13, 1993 -- Whitfield Diffie, 48, Distinguished Engineer at Sun Microsystems Computer Corporation (SMCC), was recently awarded the degree of Doctor of Technical Sciences, Honoris Causa, by the Swiss Federal Institute of Technology. The award was given for founding a new field of scientific research, public key cryptography, which grew out of discoveries Diffie made at Stanford University in 1975. The Swiss Federal Institute of Technology, or ETH after the initials of its German name, is one of the most prestigious technical universities in the world. It counts among its alumni some of the foremost scientists of the 20th century, including Albert Einstein and John VonNeuman. Doctorates "by reason of honor" make up less than one tenth of the total number of doctoral degrees awarded by the ETH. They are granted for major scientific or engineering achievements and are given only after a nomination and review process taking two to three years. In conventional cryptography, encrypting and decrypting messages were inseparable; anyone who could create an encrypted message could also read it and vice versa. By separating these functions, public key cryptography allows people to guarantee the privacy of conversations with people they have never met before and to apply unforgeable "digital signatures" to their messages. In Diffie's words: it does what signatures and envelopes do for ordinary mail. At the time Diffie began his work in cryptography, he was one of only a handful of people not employed by government intelligence agencies who took a serious interest in the field. Today, the International Association for Cryptologic Research, of which he is one of the founding directors, has hundreds of members from industry and academia worldwide. Diffie joined Sun in the summer of 1991 with the title of Distinguished Engineer, although one of his inventions had already been used in the company's security products since 1987. In hiring Diffie, Sun recognized both the rising importance of security in computer communications and the critical role of cryptography in achieving that security. In the latest Sun(TM) Solaris(R) operating system, the original "secure RPC" has been improved, while more comprehensive applications of cryptography are planned for future versions of Solaris. Sun Microsystems Computer Corporation (SMCC) is the world's leading supplier of open client-server computing solutions. With headquarters in Mountain View, Calif., SMCC is an operating company of Sun Microsystems, Inc. ### Sun Microsystems, Sun Microsystems Computer Corp., Sun, the Sun logo, are trademarks or registered trademarks of Sun Microsystems, Inc. Solaris is a registered trademark of Sun Microsystems, Inc.

1 0

shrinking availability of PGP
by pfarrell＠cs.gmu.edu 15 Jan '93

15 Jan '93

On 14 Jan, Hal wrote: > >PGP is gradually disappearing from U.S. sites where it used to be >available. Recently it got taken off the EFF area on Compuserve. >We can't afford to see encryption and remailers be slowly strangled. > I agree that this would be terrible. Do you have any grounding for this generalized statement? I can understand CI$ backing off, as they were the only organization in the US making a profit from PGP. And they have the resources and assetts that could be a target if PKP wanted a test case. I just had archie look arround, and to me the number of places was about the same. For some reason, archie doesn't find it in two places I know it is: soda.berkeley.edu and phil.utmb.edu Archie did report that it is on wuarchive. I'm affraid that the legal cloud will remain over PGP for quite some time, and that the flawed PEM implementations will become the standard. Until there is someone with real assetts using PGP, PKP's lawyers will not bother to expose their patent to the possibility of being invalidated. I also don't expect to see those of us who are assett free changing from PGP to RIPEM/PEM just because it is free of the cloud. This cloud will make folks who are nervous about the changes that netwroks, communications, and encryption will bring more cautious. I expect that PGP will continue to move from site to site. Which is why archie and gopher are so important to all of us. Pat Pat Farrell, Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

If People Were Honest
by DrZaphod 15 Jan '93

15 Jan '93

In Message Thu, 14 Jan 1993 18:56:47 -0500, Marc Horowitz <Aktis.COM!marc(a)netcomsv.netcom.com> writes: > Remember, if people were honest, we wouldn't need encryption, > either. Sigh. Being honest has nothing to do with wanting privacy. Every mail system should have, and NEEDS a way to be anonymous. That is all. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

2 1

need for more anon remailer sites
by Daniel Ray 15 Jan '93

15 Jan '93

With the shutdown of PAX, if we are not going to roll over and let this type of site go away, what we need is a large new group of such sites. 20-50 or more anonymous remailer sites that each gets used randomly and occaisionally, with usernames that are not obvious such as "anon432", both in the U.S. and elsewhere in the world, are whats needed. the list of sites must remain fluid and unpredictable, and formats and conventions must also variate so that no one can get "a fix" on it. A person that wants to anonymously mail something can choose different sites each time, or perhaps there may be a subsystem that chooses this for them, WITHOUT the mail actually going there first, if a site is in charge of "ran- domizing" the traffic. I suggest using a truly covert approach of using non-account first names and other interesting words that are indistinguishable from regular usernames as anonymous temporary mailing names. This obviously is very tricky and would have to be worked out carefully, since it may, even in the future, conflict with an actual choice of a valid username for an anonymous site. But it can be done. and we need to spare the .sig at the bottom that advertises the anon service. that should be left to separate ads, not mixed in covert email itself. One of the things that has gotten to me is to do secret acts in overt ways, almost asking the Government to defy them! Secret things should be done secretly. Once, if in the future, cryptographic email is so common as to make this unnecessary, then we can relax it. But not completely. Secret should still always be DONE IN A SECRET WAY. I.e. using steganography and other covert procedures, fluid, nonfixed proce- dures, to ensure no disturbance with rerouted and/or encrypted email traffic. Yes this is security-by-obscurity, but it can work if it is just an adjunct to other strong methods such as good ciphers and procedures that use proper contingency planning. PAX, most likely, did no contingency planning for what happened to it. All things of this type need "what ifs" for every possible interference that can happen, not that all possibilities would be addressed. But they should all be looked at, if they can be thought of. Suppose the ante goes up and all this stuff becomes actively illegal. What then? If a large network is *already* in place, the risk is much lower than trying to do something after the fact. And it would be a more mature network of rerouting and encrypting sites, that have already learned from their mis- takes. we need --all--this-- to survive. otherwise it is all just a toy application of covert technology. norstar The Northern Lights, Troy NY | tnl dialins: +1 518 237-2163 @ 1200-2400 bps 8N1 $free ` | / ------------------------------------------------------- --- * --- Internet: norstar(a)tnl.com / | . Sysop of TNL Public Access UNIX |

2 1

pax shutdown
by BRIAN MCBEE 15 Jan '93

15 Jan '93

> I agree that the PAX shutdown is an ominous development. Nobody's > internet access is perfectly free from the kinds of pressures that were > brought against PAX. What steps can we take to keep the same thing from > happening to us? > > I agree with Karl that a big step would be to spread remailers more widely. > Eric Hollander is running three remailers in addition to the ones Karl > mentioned - hh(a)soda.berkeley.edu, and two other machines which I don't > have handy. They don't encrypt but they forward, and that's good enough > for many purposes. > > Some time back, there was mention that the owner of the commercial Portal > system would run one. Could someone follow up on that who knows him? > > PGP is gradually disappearing from U.S. sites where it used to be > available. Recently it got taken off the EFF area on Compuserve. > We can't afford to see encryption and remailers be slowly strangled. > > Hal > 74076.1041(a)compuserve.com If it turns out that pressure to shut down really did come from the official net hierarchy, there are other places on the net which should be nearly immune from that kind of pressure. There are thousands of UUCP sites which predate the Internet. And anyone getting their connectivity from one of the commercial providers (PSI, UUNET, ANS, etc.) can theoretically use those networks for whatever purposes they choose. ----- Brian McBee ----- (503)378-4276 ----- brian(a)opac.osl.or.gov ----- ----- Oregon State Library, State Library Building, Salem, OR 97310 ----- Plan globally, attack locally

1 0

Fans!?
by DrZaphod 15 Jan '93

15 Jan '93

In Message Fri, 15 Jan 1993 09:30:37 +0000 (GMT), Mark Turner <demon.co.uk!mark(a)netcomsv.netcom.com> writes: >> For your newsgroups file: >> alt.fan.david-sternlight David Sternlight, sci.crypt crusader >> The David Sternlight Fanclub Joke, Right???? DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

more on security/obscurity/reality
by Daniel Ray 15 Jan '93

15 Jan '93

Thinking about everything some more, I have a few more things to say regarding my previous message stating the need for 20-50 new networked and "randomized" anon remailer sites, and the need to keep secret things secret. One thing I've really noticed over the 5 or 6 years I've been on the net is the real hatred people have for what is coined "security by obscurity." I think it is because of the terrible way people have gotten burned by relying on conceiled methods only, or secret algorithms as ciphers to protect their material. The method is discovered one way or another, and everything caves in on itself! Quite understandable. Yet I cringe at the way people have just turned their backs on the whole meta-philosophy of "coversion." If, for instance, you are to do battle with an unbearable, overwhelming power, such as the Government, then what is the only real way to "win?" Besides convincing them not to do battle with you? It is by staying conceiled, secret, untargetable. If they don't know to fight you, or, if they do know, but cannot find you, then you stay all right. Once it gets to a face-to-face confrontation, however, you lose, and you lose immediately, there is nothing you can bring to bear, since it is now just a force equation, and they have over 10,000 times the force you do. Or more... This is one of the applications of the secret side of life. Modern crypto- graphy has advanced, I think, by declaring all coversion as eventually discoverable, and only seeking algorithms that will suffice even if the enemy knows your methods. I agree with this. I guess I part company, however, when people totally throw out being secretive as a partial or adjunctive solution to something that is intrinsicly secret to begin with. The addition of conceilment, disinformation, invisibility, etc. can be a tremendous advantage when combined with strong methods (good ciphers that don't rely on coversion). It is a multilayered approach that first tries to not become a target, and, if it is a target is still hard to crack. When us little people try to maintain privacy against a Govt. that is REALLY PISSED OFF BY EVEN THE IDEA WE WANT TO STRONGLY PROTECT OURSELVES, a multi- layered, contingency-based approach is required. The most important part of it is not a strong cipher, but, not to become a detectable or locatable target. i.e. coversion and secrecy. People, in response to the PAX snafu, have advocated some kind of protest and demonstration as a solution. Sure, these can be tried. But no Govt. in its right mind will let this powerful privacy go on. It just cancels them out, and they will not have it. It'll get worse as time goes on. It applies equally to "free" and non-democratic Governments. To the world community itself. They will not have it. And we will not have them. So there you are. What to do? Create a fluid, "night"-based, invisible and unfixable multi- system of coversion and strong ciphers. So, if they get a part, the rest goes on as before. All parts of it well thought out. Everything subject to evolution, but, a base assumption that things are already quite bad. They are. I wish more of you actually lived an illegal life...you would know what I am saying without the need to say it. You need to have really faced a real risk against authority, with YOUR life on the line. And no amount of talk substitutes for experience here. Oh well. norstar The Northern Lights, Troy NY | tnl dialins: +1 518 237-2163 @ 1200-2400 bps 8N1 $free ` | / ------------------------------------------------------- --- * --- Internet: norstar(a)tnl.com / | . Sysop of TNL Public Access UNIX |

1 0

Re: Details on return envelopes
by Eric Messick 15 Jan '93

15 Jan '93

As per Hal's suggestions, I've come up with a simpler example. I've also hardened it against an attack that he noticed, which has considerably changed the protocol. Hal writes: > Another general point, which may be important. Chaum emphasized that his > anonymous addresses should be use-once, because if two people send messages > to the same anonymous address, someone who has access to the mail going > into and coming out of the remailer will see identical address fields > coming out for the pair of messages. I think Eric's scheme has the same > property. While thinking about this weakness, I realized that everything gets a lot easier if each (re)mailer knows the public key of the next. This is public knowledge, so there's no need to hide the key once the next destination is known. If there was a complete database of public keys of remailers that each remailer had, the key could be found from the address. Since that database might not be up to date, the public key is transmitted along with the address. Consequently, I was able to remove all of the conventional keys from the protocol. All encryptions are now done with public keys. Of course, there is still the conventional encryption done for each public key encrypted packet. The protocol is strengthened against this attack by fresh encryptions at each stage which hide the constant string. Note that the remailer itself can still identify the set of messages that were sent using the same envelope. It would be nice to fix this, but it seems unlikely at this point. Any ideas anyone? --------------------------------------------------------------------- I've got two examples here: a paired down one, and a slightly fuller one. The first has no postage, which cuts down considerably on the excess. The second example is just the first with the postage added back in (just to show that it still works). The envelope specifies hosts &Z and &R. The sender routes the message through &Y before using the envelope. So, the message goes from &S to &Y to &Z to &R where it is delivered. The complete simplified transaction is reproduced below, starting with the initial envelope: Addr: &Z, z, z(&R, r, r(junk)) To: &Y Addr: y(y(&Z, z, z(&R, r, r(junk))), pad) Message: y(M, pad) To: &Z Addr: z(z(&R, r, r(junk)), pad) Message: z(M, pad) To: &R Addr: r(r(junk), pad) Message: r(M, pad) The sender basically ignores the contents of the envelope, but wraps it in the public key y for safe delivery to &Y. The message and the address info are both then padded and encrypted with y. The reason for encrypting the address info with y twice will become clear shortly. &Y receives the message labeled To: &Y above. The outer y encryptions are removed, followed by the inner y encryption on the address field. The message M, and the original envelope are thus revealed to &Y. &Y now knows to send the message to &Z, and knows the public key z. The message M is then padded and encrypted with z. There is already a portion of the address field that is encrypted with z. That portion contains all of the info that &Z needs to know, but this info, as Hal pointed out, is a constant string; an external observer could use this to associated a group of messages with a single envelope. To obscure this, the string is encrypted a second time with z. Recall that a random conventional key is generated each time a public key encryption is done, so a constant plaintext string will encrypt to a different cyphertext string each time. The padding helps keep the string from being identified by its length. To keep the protocol consistent, the original envelope had to be encrypted with y twice. The resulting message is sent to &Z, where the same processing is done. Let's trace it in detail this time, but without the extraneous padding. &Z has received: Addr: z(z(&R, r, r(...))) Message: z(M) Which looks to the outside world like: Addr: z(...) Message: z(...) But &Z can decrypt those z(...)'s to obtain, first: Addr: z(&R, r, r(...)) Message: M And then: Addr: &R, r, r(...) Message: M With r thus exposed, &Z can encrypt both M and r(...) with it to obtain: To: &R Addr: r(r(...)) Message: r(M) Which to the outside world looks like: To: &R Addr: r(...) Message: r(...) With everything nicely hidden. This is what gets sent to &R. Knowing r, &R can recover M. We're done. -------------------------------------------------------------------- I'll present the postage example without further comment, except to note that at each step, all fields are freshly encrypted with the next hop's public key. Addr: &Z, z, z(Sz, Qz, &R, r, r(junk)) Pneed: Pz, Amt_z, Pr, Amt_r To: &Y Addr: y(y(Sy, Qy, &Z, z, z(Sz, Qz, &R, r, r(junk))), pad) Post: y(Py($y, Pz($z, Pr($r))), pad) Pdue: y(Qs(stuff_s), pad) Message: y(M, pad) To: &Z Addr: z(z(Sz, Qz, &R, r, r(junk)), pad) Post: z(Pz($z, Pr($r)), pad) Pdue: z(Qy(stuff_y, Qs(stuff_s)), pad) Message: z(M, pad) To: &R Addr: r(r(junk), pad) Post: r(Pr($r), pad) Pdue: r(Qz(stuff_z, Qy(stuff_y, Qs(stuff_s))), pad) Message: r(M, pad) -eric messick

1 0

Re: Details on return envelopes (padding)
by Eric Messick 15 Jan '93

15 Jan '93

Hal writes: > I did spot one possible problem. Remailer &V sends to &W an address > field that looks like: > > Addr: w(B), w(Sw, Qw, C, &X, x(C), x(...), pad) > > but I don't think &V has enough information to create the 2nd item here. > The reason for the A, B, etc. keys is, I think, to allow new padding to > be done as the message gets passed between each pair of remailers. > I think that may need to be used here as well. &V can't put padding into > the w(Sw,...) block. It may not be at all obvious or intuitive, but &V *CAN* put padding into the w(...) block. I'm no longer trying to do this (see my previous posting), but it could still be useful in some situations, so I'll try to explain it more clearly. PGP uses binary structures for all of this, but I'm going to pretend that it's all ascii, just so we can see what's going on easier. That block w(...) looks something like this: CTB: RSA <-- that's *C*ypher *T*ype *B*yte Length: 12345 bytes Key_ID: w IDEA_key: RSA(w, random_key) CTB: IDEA Length: 12315 <random initialization bytes and cypher check> CTB: Plain Text Length: 12300 Here we have 12300 characters. Note that all of the lines that are indented are encrypted with random_key using the IDEA cypher. ...End of the encrypted text. To add padding to this, simply append some cryptographically strong random bytes to the end, and adjust the unencrypted lengths by that much. No one can tell that your new bogus lengths don't match the length on the plaintext packet without actually being able to see the plaintext packet length field. The decryptor believes the plaintext packet length, and automatically throws away the bogus bytes that were decrypted. While writing this, I realized that when I tested this, I may have only changed the outermost length. It is possible (but I think it is highly unlikely) that PGP would get sick if you changed the second length value. Since I no longer need to do this, I don't have any incentive to check this out again. It's not that difficult, but I hate editing binary files... -eric messick

1 0