- cypherpunks-legacy - lists.cpunks.org

Ha ha
by Secret_Squirrel＠Treehouse.COM 10 Oct '92

10 Oct '92

Whoah. That's helarious. NOT! Secret Squirrel does not cotton to imposters, and that sure as hell ain't my Public Key. So don't even bother trying to write any encrypted messages with it. My key remains: 23l1t34u -- SHRDLU

1 0

*Economist* on encryption
by whitaker＠eternity.demon.co.uk 10 Oct '92

10 Oct '92

The following is intended for limited-distribution, educational purposes only.... Citation: The Economist, Sept 21, 1991 v320 n7725 p104(2) COPYRIGHT Economist Newspaper Ltd. (UK) 1991 ---------------------------------------------------------------------- Title: A cure for the common code: computer cryptography. ---------------------------------------------------------------------- Subjects: Public key cryptosystems_Standards Digital signatures_Standards Data encryption_Research United States. National Institute of Standards and Technology_Laws, regulations, etc. Reference #: A11286848 ====================================================================== Summary: Advances in the mathematics of prime factorization algorithms have led to a technology that, once standardized, will dramatically improve public-key cryptography. The RSA algorithm is popular in the computer industry, but the government favors an alternative. ====================================================================== ANYONE can sign a postcard, but how do you sign a piece of electronic mail? Without a "signature" to demonstrate that, say, an electronic transfer of funds really comes from someone authorised to make the transfer, progress towards all-electronic commerce is stymied. Ways of producing such signatures are available, thanks to the technology of public-key cryptography. They will not work to everyone's best advantage, though, until everyone uses the same public-key system. It is an obvious opportunity for standards-makers - but in America they have turned up their noses at all the variations on the theme currently in use. The alternative standard for digital signatures now offered by America's National Institute of Standards and Technology (NIST) has brought a long-simmering controversy back to the boil. Public-key cryptography could become one of the most common technologies of the information age, underpinning all sorts of routine transactions. Not only does it promise to provide the digital equivalent of a signature, it could also give users an electronic envelope to keep private messages from prying eyes. The idea is to create codes that have two related keys. In conventional cryptography the sender and receiver share a single secret key; the sender uses it to encode the message, the receiver to decode it. In public-key techniques, each person has a pair of keys: a disclosed public key and a secret private key. Messages encoded with the private key can only be decoded with the corresponding public key, and vice versa. The public keys are published like telephone numbers. The private keys are secret. With this technology, digital signatures are simple. Encode your message, or just the name you sign it with, using your private key. If the recipient can decode the message with your public key, he can be confident it came from you. Sending a confidential message - putting electronic mail in a tamper-proof envelope - is equally straightforward. To send a secret to Alice encode it with her public key. Only Alice (or someone else who knows her private key) will be able to decode the message. The heart of any system of public-key cryptography is a mathematical function which takes in a message and a key, and puts out a code. This function must be fairly quick and easy to use, so that putting things into code does not take forever. It must be very hard to undo, so that getting things out of code does take forever, unless the decoder has the decoding key. Obviously, there must be no easy way to deduce the private key from the public key. Finding functions that meet these criteria is "a combination of mathematics and muddle", according to Roger Needham of the Cambridge Computer Laboratory. The greatest successes to arise from the muddle so far are those using functions called prime factorisation algorithms. They are based on the mathematical insight that, while it is easy to multiply two numbers together, it is very hard to work backwards to find the particular two numbers which were multiplied together to produce some given number. If Alice chooses two large prime numbers as her private key and publishes their 150-digit product as her public key, it would probably take a code-breaker thousands of years to work backwards to calculate her private keys. A variety of schemes have been worked out which use this insight as the basis for a workable public-key code. Most popular of these is the so-called RSA algorithm, named after the three MIT professors who created it - Ronald Rivest, Adi Shamir and Len Adleman. It has been patented and is sold by a Silicon Valley company, called RSA, that employs 15 people, most of them ex-MIT graduate students. Faculty firms are to computer start-ups what family firms were to the industrial revolution. RSA has attracted both academic praise and a range of heavyweight commercial customers: Microsoft, Sun Microsystems, Digital Equipment and Lotus Development. But, despite repeated applications, it has never been endorsed by those in government. Rumours abound that the code-breakers in the National Security Agency have discouraged standard-setters from recommending RSA because they do not want to promote the use of codes they cannot break. RSA, for obvious reasons, does not discourage the rumours. Whatever the reason, the standard-setters at the NIST have side-stepped the debate over RSA with their new algorithm, DSA. As set out in the standard, DSA verifies the identity of the sender, but does not encrypt the message. It appends to the message a number calculated from the message and the sender's private key. The recipient can then use this number, the message and the sender's public key to verify that the message is what it seems. The NIST says that this technique is well suited to "smart cards" and other applications where there is not a lot of computing power available for working out codes. Because it hopes that DSA Will be used for verifying the identity of everyone from welfare recipients to military contractors, its flexibility is a boon. Meanwhile, however, more and more companies are choosing a public-key cryptography system for communicating confidentially - often RSA, sometimes something different. Someday, probably soon, governments will want to choose, too. Watch out for fireworks when they do. ------------------end forwarded article-------------------------- Russell Earl Whitaker whitaker(a)eternity.demon.co.uk Communications Editor 71750.2413(a)compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK-----

1 0

Anonymity
by Secret_Squirrel＠Treehouse.COM 10 Oct '92

10 Oct '92

Anonymity is good. Anonymity works. >> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key...\ << Uh... it's kind of an inside joke. Uh. Sorry. Anyway, why would you want to reply only directly to me and not to the list in general?

1 0

Re: +-=*^
by nobody＠soda.berkeley.edu 10 Oct '92

10 Oct '92

Since there has been complaints about the size of my public key here is a more secure 512bit version, please discard the prevous key -Secret_Squirrel PS: please redistribute this key asap. to others. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+ =Byn9 -----END PGP PUBLIC KEY BLOCK-----

1 0

+-=*^
by Secret_Squirrel＠Treehouse.COM 10 Oct '92

10 Oct '92

re: Interface for re-mailer; why not hitch it to emacs or something? re: problem with key distribution; right, OK, I hadn't thought that there might be a security problem with casually giving someone your key without them being able to authenticate that it came from you. Good point. Here's my public key. If you feel it is not secure enough, we can always use the cone of silence: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 23l1t34u -----END PGP PUBLIC KEY BLOCK-----

2 1

re: +-=*^
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 10 Oct '92

10 Oct '92

U> re: problem with key distribution; right, OK, I hadn't U> thought that there might be a security problem with U> casually giving someone your key without them being able U> to authenticate that it came from you. Good point. But as Eric pointed out, and I realized later, the underlying social structure will allow detection of bum keys (presuming the scammed person or someone s/he knows notices, etc, and so on, a wholew world resides here...) U> Here's my public key. If you feel it is not secure U> enough, we can always use the cone of silence: U> U> -----BEGIN PGP PUBLIC KEY BLOCK----- U> Version: 2.0 U> U> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key... PS: Too much anonymity? I have to reply in hte mailing list to this person cuz it's a faked From... (trust me) * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

The technical explanation of "::" incoming header pasting
by Eric Hughes 10 Oct '92

10 Oct '92

There's a new feature in the remailing software. Some people can't add arbitrary header fields because of mailer or gateway restrictions. This restricts them from using the remailer. I have added a facility to allow new header fields to be pasted onto the end of a header when the mail arrives. This effectively happens before processing by the remailer software. These new fields exist during transit in the message body, where they remain untouched. Only after the message is delivered to my account does this operator take effect. Syntax: If the first line of the body is the two characters "::", then the following lines are appended to the header, up to the next blank line. Here's how it works. First of all, here's my new .maildelivery file: ------- cut here ------- # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remailer/remail.perl" Request-Remailing-To "" file R remailer/archive * "" pipe R "/usr/local/lib/mh/rcvtty -biff" * "" pipe ? "perl remailer/incoming.header.perl" ------- cut here ------- Comments are indicated by #. The Request-Remailing-To lines have been there. The second of the makes an archive for debugging purposes. It will go eventually. The third field, "*", indicates all fields, it runs 'rcvtty' on my mail; this replaces the function of biff, since mail is getting piped to slocal now, disabling biff. The last line is the important one. It says "If the mail hasn't been delivered by now, run the incoming header rewrite script on it. If that doesn't work, continue trying to deliver it." Now here's the trick. slocal has no way of taking the output of the rewrite and continuing to process it. (It should. It would make this whole job easy.) So in order to continue processing, you need to redeliver the mail. You could invoke sendmail and mail it back to yourself, but that would mangle the existing header. So the thing to do is to recursively invoke slocal from within the perl script. Here's the perl script to do all this: ------- cut here ------- # First read in the whole header. # We check for the Second-Pass: line to detect infinite loops. while (<>) { last if /^$/ ; exit 1 if /^Second-Pass:/ ; $header .= $_ ; } # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::$/ ) { while (<>) { last if /^$/ ; $header .= $_ ; } } else { # There is either an empty body or no pasting operator # Thus exit with a return code of 1 to indicate that # the mail has not been delivered. exit 1 ; } # There was a header pasting operator. # So we open 'slocal' as a pipe, effectively redelivering the mail # back to ourselves. #open( OUTPUT, ">foo" ) ; open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ; select( OUTPUT ) ; # print a "From " line to satisfy slocal @weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ; @months = ( "Jan","Feb","Mar","Apr","May", "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ; printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ; printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ; # Now just print out the message print $header ; print "Second-Pass:\n" ; print "\n" ; while (<>) { } continue { print ; } ------- cut here ------- Here's how the perl script works. The first loop reads lines from the existing header. When it sees a blank line (regexp /^$/) it terminates the loop. If it sees a field "Second-Pass", it knows it has filtered this message before and exits with a return code indicating that the mail has not been delivered. The variable $header is appended with the current header line. $header contains the whole header when the loop terminates. Properly speaking, the Second-Pass test is not necessary to detect infinite loops. Since the pasting operator gets removed during the rewrite, the script won't return an exit status of 0 more times than the pasting operator appears. But should something get screwed up, such as a different module adding pasting commands (how? I don't know), the Second-Pass test should prevent infinite recursion. The next statement reads another line from the input file. This line is the first line of the message body. If this line is the pasting operator, then header lines are accumulated in $header as before until a blank line. The difference is that these header lines are being read from the body of the message. If there is no pasting operator, the script exits undelivered. At this point we now have to redeliver the message back to ourselves. We first open slocal as the output pipe. The next section is a kludge. It turns out that slocal strips off the out-of-band "From " (no colon) line that the mail delivery system uses. In other words, the message which slocal pipes into its pipes is not identical to the message it itself received. This means that slocal cannot be directly recursed. What this section does is to create a "From " line to make slocal happy. It calls localtime() and then formats those numbers into the proper form. It turns out that slocal will deliver this mail without the "From " line, even to /usr/spool/mail, but it doesn't do so properly. On my system, in added some delimiters which I think I've tracked down to the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these are not null on my system, there's some garbage added which screws up separation of the spool file into messages. Adding a "From " line fixes that. This misbehavior may not be so surprising, considering that slocal was "meant" to be invoked only in a .forward file. Now we print the variable $header which contains the whole header, including newlines. Using a single string removes the need for an array. We added the Second-Pass line and a blank line for the end of the header. The final loop prints out the rest of the message body. There is another way to proceed to get the same functionality. One could write a filter to translate the first occurrence only of \n\n::\n into \n. We could then pass the message through this filter before slocal saw it. And for now, that would do the same thing. But suppose we want more that one rewrite rule active? Then you would only be able to apply each rewrite rule exactly once in fixed order. You want to be able to rewrite a message and then apply all the rewrite rules again. At least one other rewrite rule is planned: automatic decryption. Since decrypting a message will completely change the body, and since some of the header fields may need to be hidden, you have to be able to decrypt the body and then paste on header lines. But since you need to indicate an encrypted body by a header line (well, not really, but it's more reliable), and since some people can't add these header lines, you need to paste lines before encryption as well. Thus the rewrite rules need to be applied asyncronously and hence I'm using a fairly complex slocal scheme to do a simple filter. Eventually I hope to write an equivalent to slocal which knows about message rewrites and simple filters, but that's for later. Eric

1 0

my key
by Peter Shipley 09 Oct '92

09 Oct '92

Here is my casual key, for a more secure key please contact an authorized dealer near you (Eric Hughes or I). -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRl ciBNIFNoaXBsZXkgPHNoaXBsZXlAYmVya2VsZXkuZWR1Pg== =/Dhz -----END PGP PUBLIC KEY BLOCK-----

1 0

New feature of the remailer
by Eric Hughes 09 Oct '92

09 Oct '92

New! Just finished. Fidonet support. Dumb mailer support. Incoming header line pasting. Here's what's going on. There are a lot of mailers, the Fidonet gateway in particular, which don't allow you to put arbitrary header lines in your outgoing messages. Previously people using these systems couldn't use the remailer because they couldn't put the necessary "Request-Remailing-To:" in the header. Now they can. Instead of putting header lines into actual header, I now support a syntax which allows header lines to be _added_ to the header on incoming mail. These extended header lines are in the body of the message proper, but a filter on incoming mail effectively adds them to the header. This allows anybody who can send me mail with a reasonably unmangled body to use any feature of the remailer that should ever get written. Example: ------- cut here ------- To: hughes(a)soda.berkeley.edu From: Secret_Squirrel(a)treehouse.com Subject: Mrs. Tree's secret recipe for pinole :: Request-Remailing-To: Crusader_Rabbit(a)rocky.moosylvania.org I just paid $2600 for this recipe [etc. etc.] [...] ------- cut here ------- If "::" is on the first body line all by itself, whatever lines follow up to the first blank line will be appended to the header when it is scanned for special instruction lines. This new feature is completely modular. It doesn't (seem to) break any of the other existing features. I'll post the source with an explanation tomorrow. In the meantime, try it out. Eric

2 1

Oct. 10 RSVP's
by Eric Hughes 09 Oct '92

09 Oct '92

As of tonight, Thursday 10, the Saturday meeting is in two days. I'd like to get RSVP's from everyone who plans to attend, so that I know how many are going to be there. SEND ONE EVEN IF YOU THINK I KNOW THAT YOU'RE COMING! I can't keep everyone's attendance plans straight. Thanks. Eric

1 0