January 1993 - cypherpunks-legacy

Fans!?
by DrZaphod 16 Jan '93

16 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 (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

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

/usr/lib/newsbin/ctl/newgroup: `news@math.fu-berlin.de (Math Department)' tried (fwd)
by Mark Turner 15 Jan '93

15 Jan '93

You may be interested in this recent attempt to create a bogus newsgroup, especially if you've been following recent discussion in sci.crypt. Regards, Mark. According to news(a)dis.demon.co.uk.... > From dis.demon.co.uk!news Fri Jan 15 00:38:27 1993 > To: usenet(a)dis.demon.co.uk > Subject: /usr/lib/newsbin/ctl/newgroup: `news(a)math.fu-berlin.de (Math Department)' tried > Date: Fri, 15 Jan 93 0:33:57 GMT > From: news(a)dis.demon.co.uk > Sender: news(a)dis.demon.co.uk > Message-ID: <9301150033.aa12907(a)dis.demon.co.uk> > > /usr/lib/newsbin/ctl/newgroup: `news(a)math.fu-berlin.de (Math Department)' tried > to create newsgroup `alt.fan.david-sternlight'. > Request was refused: component exceeds 14 characters. > === > Control: newgroup alt.fan.david-sternlight > Newsgroups: alt.fan.david-sternlight.ctl,control > Path: demon!pipex!bnr.co.uk!bnrgate!nott!torn!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!lkdfjilu!sternlight.com!nobody > From: dsfc(a)sternlight.org > Subject: newgroup alt.fan.david-sternlight > Message-ID: <rezalevabgib12370(a)sternlight.org> > Sender: news(a)math.fu-berlin.de (Math Department) > Organization: J. Random Site > Date: Wed, 13 Jan 1993 20:14:32 GMT > Approved: news > Lines: 21 > > > one mo' time... > > For your newsgroups file: > alt.fan.david-sternlight David Sternlight, sci.crypt crusader > > > This group is designed for the praise of the wit and wisdom of our > leader, David Sternlight, the man battling the evil use of > cryptography wherever it may lie. > > The group is being created entirely for the use of the David > Sternlight Fanclub, which holds the patent on this newsgroup and would > be forced to sue if anyone else tried to use it. Indeed, we would be > disgusted by the implicit lack of respect for intellectual property. > Also, this newsgroup may not be imported or exported from any eastern > block country in contravention of the ITARs. > > Thank you, > > The David Sternlight Fanclub > === -- /\/\ark Turner Demon Systems / Demon Internet Office: mark(a)demon.co.uk (+44 81 349 0063) 42 Hendon Lane, London Home: mt(a)kram.org (+44 831 823 212) N3 1TT, England ------------------ PGP version 2.0 Public Key available ------------------- *** IP level dial-up connectivity to the Internet for a tenner a month! ***

1 0

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

15 Jan '93

> I thought about this. The major problem is that once the PEM > beta-testing period ends, all keys must be registered with "approved" > (by RSA) central authorities. I highly doubt they'd issue > pseudonymous keys, but maybe they would allow someone to set up a > heirarchy especially for that purpose. I'm not convinced. Who says ? RSA may wish this to happen, but surely anyone who wants to can set up their own key service. david

2 1

Electronic money legality
by Hal 15 Jan '93

15 Jan '93

The question came up here some time ago as to whether it would be legal to issue electronic money, or regular money, for that matter. I got a couple of books out of the library to try to learn something of the history of private bank notes. It seems that private bank notes were the rule rather than the exception in the U.S. up until around the time of the Civil War. However, the notes were issued by banks which generally had a charter or license from the state government. I'm not sure whether a private individual could have legally issued his own banknotes without state permission. Around the time of the Civil War the Federal government levied a 10% tax on all issues of banknotes. This was intended to drive them out of use, and it did. Apparently this tax is still in effect today. George Selgin's book, The Theory of Free Banking, is a call to return to a situation of competitive note issue, where each bank would print its own "money" and people would use all these different monies freely according to their preferences. Regardless of the pros and cons of this idea, he does mention the legal situation briefly in footnote 7 of chapter 11: "Strictly speaking, issue of bank notes by commercial banks is not presently illegal; however, such issue must still meet the bond-deposit requirements established under the National Banking System or the 10 percent tax on state bank notes. Since all bonds eligible as security for circulating notes were retired before 1935 (or had the circulation privilege conferred upon them withdrawn), note issue, while not illegal, is nevertheless impossible under existing law. Restoration of commercial bank note-issuing privileges merely requires repeal of the bond deposit provisions of the original National Banking statutes and of the prohibitive tax on bank notes." One other point I learned was about the nature of "legal tender" laws. If a money is a legal tender, a creditor cannot turn down an offer by a debtor to repay using that money. If he does turn it down, the debt is void (roughly). So, legal tender laws don't forbid repayment of a debt in some other form (I can give you a bike in place of the $100 I owe you), (if we both agree), but they may specify that even if a debt is denominated in some other units, I can repay using federal reserve notes. This is what happened when the U.S. stopped redeemin for gold during the 1930's - long-term contracts had routinely been denominated in gold, but the courts held that dollars could still be used to pay them off. So, legal tender laws don't appear relevant to the use of digital money, except that contracts based on digicash could still be paid off by dollar bills if the debtor wants. Hal Finney 74076.1041(a)compuserve.com

1 0

possible solution to the anonymous harrassment problem
by Marc Horowitz 15 Jan '93

15 Jan '93

(I'm also marc(a)mit.edu. But composing over a 9600 baud line sucks :-) I just had an idea. Assume we have some sort of workable system for anonymous return addresses. What if every message were *required* to have one, and if the remailers verified their correctness (at least as far as we can, given the fakability of net mail)? Then, if someone received harassing email, she could ask the remailer maintainers to find the real name of the sender of a piece of mail. Assuming reasonable remailer maintainers (and we can use positive reputations to decide that), they'd be able to do this. The system has a built-in safety: All the remailer maintainers would have to agree that a message was indeed harassing to the recipient before they would use their private keys to follow the chain back. Unless all the maintainers agreed to trace the message, it would be impossible, and the sender's anonymity would be assured. I'm just trying to think of technical solutions to our societal woes, as hopeless as this may be. Remember, if people were honest, we wouldn't need encryption, either. Sigh. Marc

2 1

Forwarded article.
by whitaker＠eternity.demon.co.uk 15 Jan '93

15 Jan '93

This article was forwarded to you by whitaker(a)demon.co.uk (Russell Earl Whitaker): --------------------------------- cut here ----------------------------- Newsgroups: demon.security Path: eternity.demon.co.uk!demon!visigoth.demon.co.uk!pettsj From: James Petts <pettsj(a)visigoth.demon.co.uk> Subject: Public Key Exchange Message-ID: <C0u8ww.1xD(a)demon.co.uk> X-Xxmessage-Id: <A77AE8E4BD010855(a)visigoth.demon.co.uk> X-Xxdate: Thu, 14 Jan 93 09:54:44 GMT Sender: news(a)demon.co.uk Nntp-Posting-Host: visigoth.demon.co.uk Organization: No Affiliation X-Useragent: Nuntius v1.1.1d13 Date: Thu, 14 Jan 1993 09:55:42 GMT For those who are interested, there is a short article in today's (14/1/93) New Scientist explaining how quantum uncertainties can be used to improve the security of exchanging cryptographic keys. ===> James Petts <=== *** CAUTION - READ THIS .sig AT YOUR OWN RISK! *************************** * * NOTE! VISIGOTH HAS NO * * Q. Wenn ist das Nunstueck git und Slotermeyer? * CONNECTION WITH ANY * * A. Ja!... Beiherhund das Oder die Flipperwaldt * OTHER SITE AT * * gersput! * DEMON.CO.UK * * * * ************************************************************************** * pettsj(a)visigoth.demon.co.uk (preferred), pettsj(a)cix.compulink.co.uk * ************************************************************************** --------------------------------- cut here -----------------------------

2 1

Re: anonymous service shutdown (pax)
by dclunie＠pax.tpa.com.au 15 Jan '93

15 Jan '93

I have had a fairly long discussion via email with the AARnnet administrator involved. He points out that wrongly or rightly (he believes wrongly) the AARNet does not have an "open access" policy, and the network is setup exclusively to service the university community. Public access systems are tolerated, but barely, and mainly through the grace of those who administer the system rather than those who fund it. The complaint in question was actually not at all specific, and came not from the NSF but from one of the NASA Internet officers who is responsible for the US end of the link to Australia (and pay for some of it). Essentially the complaint was one of increasing mail traffic on an already congested link to the US, as well as concern about the "hiding people's identities so they cannot be responsible for what they say". Personally I disagree with the second complaint, but cannot dispute the first, without statistsics about what component of the link was being consumed by the posting service. I suspect it was very small but these things all add up. It seems a shame that the anonymous system is being terminated "on principle" but the AARNet person has been friendly about it, in fact positively graceful in view of my somewhat inflammatory post, and so I guess I just have to leave it there. Hopefully eventually commercial vendors will provide an alternative channel to the university-based network here currently, much as has happened in the US over the years, and these questions will be less of a concern. david

1 0