February 1993 - cypherpunks-legacy

scheme
by Timothy Newsham 23 Feb '93

23 Feb '93

I posted this to sci.crypt, I would also like the opinion of the people on this list: --------------------------------------- I have posted about this before, but this time I decided to whip up some code so you can all see what I'm talking about and all the details. This encryption scheme uses XOR to encrypt data 1 character at a time. Because of this it is suitable for protocols where you need to send single bytes (or less) at a time. Examples of this would be interactive ascii. Also it is easily applicable to crippled lines like 7 bit lines. This is because if the plaintext is 7 bits you can send just the 7 bits after the XOR. Even more general you can use it to encrypt any size at a time, down to single bits if you just have 1 bit to send immediately and dont want to wait for more data to become applicable. Ok. So what are its disavantages? Syncronization, as soon as synchronization is gone thats it, its all over. Each block of 'pad' is generated from previous plaintext, if you cant figure out the previous plaintext you are lost. Notice it uses a hash() function, this could be anything, ie DES, or perhaps a one way function (no unhash() is ever needed). The algorithm is fairly simple, the beginning is a bit wierd and could have been done several ways. The first 8 bits in this implementation are used for synchronization. prog -e key <file >file2 prog -d key <file2 >file3 ok.. here it is.. poke holes in it. What are the weaknesses, is it totally unsecure? Is it as secure as the hash function (ie. if DES was used, is strength equivalent to the strength of DES?) -------------cut here--------------------------------------------- #define SIZE 8 #ifdef MEMCPY #define bcopy(s,d,l) memcpy(d,s,l) #endif usage(s) char *s; { printf("%s [-e|e|-d|d] key\n",s); exit(1); } main(argc,argv) char **argv; int argc; { char data[SIZE],pad[SIZE],c[1],c1[1],*p,key[SIZE]; int cnt,encrypt=0; if(argc!=3) usage(argv[0]); for(cnt=0;cnt<SIZE;cnt++) /* fill in extra characters in key */ key[cnt]=0xaa; strncpy(key,argv[2],SIZE); p=argv[1]; if(*p=='-') p++; if(*p=='e') encrypt++; else if(*p!='d') usage(argv[0]); if(encrypt) { /* to start off encryption, we send a bunch of random bits */ /* then we hash those bits and use them as pad */ blkrand(data,SIZE); write(1,data,SIZE); hash(data,key); } else { /* to start off decryption, we receive the random bits and */ /* hash them (just like the encryptor did) and we should */ /* have the same starting pad as the encryptor */ read(0,data,SIZE); hash(data,key); } bcopy(data,pad,SIZE); cnt=0; while(read(0,c,1)>0) { /* read characters, send them with our pad */ /* every time we run out of pad, we make new pad */ /* by hashing old data */ *c1 = *c ^ pad[cnt]; if(encrypt) /* data is the plain text always */ data[cnt]=*c; else data[cnt]=*c1; write(1,c1,1); if(++cnt==SIZE) { cnt=0; bcopy(data,pad,SIZE); hash(pad,key); } } } /* provide a block of random bits */ blkrand(block,len) int len; char *block; { srand(time(0)); while(len--) *block++ = (rand() >>7)&0xff; } /* hash a block, could be DES, or even a one way function */ hash(block,key) char *block,*key; { char b2[SIZE]; int i=SIZE; while(i--) b2[i] = *block++ ^ *key++; bcopy(b2,block,SIZE); }

1 0

RE>Congratulations to All!
by mbrennan＠netcom.com 23 Feb '93

23 Feb '93

Reply to Message-Id: <9302232131.AA17884(a)netcom.netcom.com> from tcmay(a)netcom.com (Timothy C. May) > It seems we are getting lots of newcomers to the list (though I keep > seeing cancellations posted to the general list, too!). It might be nice to > hear from them about their reactions. Actually, I may (regretfully) be sending in my cancellation as well. This group is fascinating, but I find most of the discussion goes right over my head. Also, the mail generated is just too voluminous. I log into my netcom account by modem (and use Eudora to retrieve my mail). Yesterday I had about 40 messages from this list, today I had over 70! Whew!!! That's a lot of mail to retrieve by modem. What I'd really like to see is a digest form of this list. Also, for newcomers like myself a FAQ would be of tremendous benefit. > The recent interest by "Mondo 2000," "Wired," and "The Village Voice" in > Cypherpunks activity and in digital privacy in general suggests we are > doing something quite important and interesting. I'd say you're quite right about that. Keep up the great work! ------------------------------------------------------------------------------ Michael Brennan Internet: mbrennan(a)netcom.com Applelink: M.BRENNAN Compuserve: 76206,2462

1 0

Congratulations to All!
by tcmay＠netcom.com 23 Feb '93

23 Feb '93

With all the volume on this list, and the controversy over "Deadbeat" (in both his/her content and the multiple postings), and the flame wars (not here, of course!) over the anonymous postings, I wanted to say a few things. I'll be brief. * Congratulations to all on the amazing progress being shown. The "problems" are themselves valuable learning experiences, spurring on new developments and forcing important issues to the fore. * The escapades of "Deadbeat" are especially valuable, as weaknesses are revealed and fixes are implemented. The sociology of anonymous systems is a largely unexplored territory. (From the phrasing he uses, "Deadbeat" seems to be one of our regular posters, and is clearly not some malicious outsider intent on destroying our system--and even if so, he's still doing us a service!). * Our own Lance Detweiler posted to sci.crypt a very long and excellent summary of anonymous mail, remailers, and general issues. It is still there, titled, "IDENTITY, PRIVACY, and ANONYMITY on the INTERNET." I'm surprised it hasn't been mentioned here more often. In fact, it ought to be posted to _this_ list, in case someone isn't reading sci.crypt (that's hard to believe, though). Others, like Hal Finney, have also posted recent summaries of remailers. * The "whistleblower" group idea is a good one, as is the "pools" idea. The whistleblower application is already in use via a modem system in Washington (I saw this mentioned about a year ago...I can dig up the details, maybe), though not using any form of crypto anonymity. I confess to having similar ideas some time back, which I mentioned at the first physical Cypherpunks meeting, in September, though I completely missed the importance in terms of _public relations_. In other words, I think it's a great idea. (The obvious benefits of an anonymous whistleblower group will make it hard for government types to object. Even if a lot of "noise" is posted (spurious claims, rumors, etc.), the exercise will be beneficial. And journalists who begin to dip into such a group for possible articles, will thus become educated themselves.) * The actions of the "*.army.mil" guys may have also spurred on some of our activists. What Kelly Goen is proposing to do--spreading these crypto anarchy methods to other politically active groups--is also a wonderful development. * It seems we are getting lots of newcomers to the list (though I keep seeing cancellations posted to the general list, too!). It might be nice to hear from them about their reactions. And perhaps Eric Hughes could occcasionally summarize list statistics, as he did several months back. For example, how many are now on the list? How many "*.mil" sites? Etc. * The recent interest by "Mondo 2000," "Wired," and "The Village Voice" in Cypherpunks activity and in digital privacy in general suggests we are doing something quite important and interesting. * All in all, I think amazing progress is being made. -Tim May -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: MailSafe and PGP available.

1 0

link encryption
by Timothy Newsham 23 Feb '93

23 Feb '93

I have been working lately on a program to encrypt my modem traffic between home and the unix. I call the program 'link' for link encryption. Currently it uses DES and RSA, RSA to exchange a random session key and DES to encrypt all general traffic. I spent some time today cleaning up some of the code so that it would be more modular and portable. The unix end i is presentable now but would require a remote end to work along with it. I dont feel that my Amiga end is good enough to even use regularly, there are some bugs in the Amiga end, and I haven incorporated the most recent changes into it either. I wrote the code to be modular and hopefully easily attached to other term programs in hopes that people would patch some code into their favorite term program and use it. If anyone wants the unix code I'm giving it out now, It is a bit long so I wont post it to the list unless I get enough replies (aand not too many "dont post it!" replies). If anyone has an ftp site they wish to put it on that is fine too. I'm releasing the code into the public domain, do with it what you please. Its in no way complete, I plan to add more features and hopefully robustness to the code in the future. ...

1 0

anonymous return addrs.
by Hal 23 Feb '93

23 Feb '93

Marc.Ringuette writes: 2. The anonymous message includes a cryptographic "stamped self-addressed envelope" which contains a layered list of remailer addresses encrypted at each layer. This requires modified behavior of remailers; they must be willing to "unwrap" an address-list separately from the message body, and then "wrap" the entire message with the destination's public key, in order to disguise the correspondence between input and output. I think this has been discussed here before. Has anyone implemented it? I strongly suggest that this method be implemented in the cypherpunks remailers. Let's call it the SASE feature. What do you think? I do think this is worth trying. The current remailers will do the "unwrapping" but they won't "re-wrap" in the public key of the next remailer. This means that the incoming and outgoing messages can be easily matched up since the non-address portion is the same. I'll look into trying something like this. One issue is how the remailer finds the public key of the next one in the chain. The simplest way would be for it to simply try a lookup on its PGP keyring using the outgoing email address, and if it matches, encrypt it. You'd want a special PGP keyring for this which had only remailer keys on it. (Or, it might be interesting to encrypt _all_ outgoing mail (even to destinations) if we had a key for that outgoing address. This might increase the utilization of PGP, although users probably would complain!) Even if not every remailer did this, you'd still get pretty good security if several of them did. Hal

1 0

anon.penet.fi fixes
by Hal 23 Feb '93

23 Feb '93

Eric Hughes suggests: > Currently to mail to person 1234 at penet, you send mail to > > anon1234(a)penet.fi > > This mail goes out anonymously from the sender, either using an > existing mail address or creating one. But if one were able to reach > person 1234 also with the email address, say, > > name1234(a)penet.fi > > the behavior could be _not_ to make this posting anonymous. > > To wit, the 1234 indicates that you are replying to a pseudonymous > recipient, and the anon/name pair indicate whether the sender is > anonymous. Thus no change in default behavior, and no new header > lines. I'd extend Eric's idea to say that mail to a non-anonymous address (like Deadbeat's postings to Cypherpunks) should be shown as coming from "name5877" rather than "an5877". Then when we gullibly sent our true email addresses to him, our Penet anonymous ID's would not be revealed (because the "reply" command would send to "name5877" which would prevent the double-blinding). But, what would we do for anonymous Usenet posts (assuming those are still allowed)? If they are shown as coming from "an5877" as they are now, then Deadbeat's trick would work via posting to Usenet. ("Please send your current email address for information on the latest..."). If they are shown as coming from "name5877" then users who are accustomed to the old way of working will find themselves not being anonymized when they thought they would be. Deadbeat suggests: > Here's a way out that will satisfy me and Johan: assign Alice a new > pseudonym here and now, one that will be good for replies only. If > Alice has registered with the remailer in the past, i.e., if she has a > password, then she knows how to X-Anon-To:, but has opted not to. If > she has not registered, then it is also appropriate to assign her a new > ID. However, should she later register, I suggest she be given a new, > permanent, password-protected ID, just in case her earlier reply > inadvertently exposed her real ID (in the way we have been discussing). > > In essence, I'm suggesting that the Finnish remailer have two classes > of anonymous IDs, one that is password protected, and one that is not. > The former should never be used without the X-Anon-Password header. A problem with this is that I would have to remember, for each different anonymous communicant I send to, whether I am using my "password" ID or my "non-password" ID. The difference would come down to what method was used when I initially began communicating with this person. If the initial contact was in response to mail they sent to my "real" email address, then I must remember to use the "non-password" ID for all succeeding communication, on the theory that they know my real email address. OTOH, if the initial contact was to my anonymous address, then I have to remember to use my "password" ID for all following communication, so that I don't accidentally reveal my "non-password" ID, which some people can link to my real address. >From this point of view, part of the problem appears to be the desire to live in both worlds - the real world and the shadow world. It will be hard to keep track of which world each communication is in. Perhaps Deadbeat's and Eric's ideas could be combined, where mail to real email addresses would come from "name5877", and replies to such addresses would use the "non-password" ID. This might help people keep track of how to reply to each message. I still think there is a problem with how anonymous posts should be labelled, and how replies to such posts should be handled. Hal

1 0

Doubled penet messages
by Hal 23 Feb '93

23 Feb '93

I see what's causing the double messages from Deadbeat. Penet puts an X-Anonymously-To: cypherpunks(a)toad.com into the header that it sends. (I'm not sure why it has to do this; isn't this redundant with the "To:" header?) The cypherpunks mailing list rebroadcaster keeps this header. The mailing list goes to Chael Hall's remailer. That remailer sees the X-Anonymously-To line in the header and thinks this message is a remailing request. (The other Cypherpunks remailers uses a different header line for their remailing requests.) That remailer then obediently sends the mail to Cypherpunks, and so we get two messages. Either Chael's remailer should not accept X-Anonymously-To as its remailing request, or Penet should not put X-Anonymously-To into the outgoing message headers. Perhaps this would be a good time to standardize the supported set of headers for remailing requests. Hal

2 1

Beware of anon.penet.fi
by Hal 23 Feb '93

23 Feb '93

I'd like to verify that X-Anon-Doubleblind: no would mean that no X-Anon-Password would be needed with the message. This way, remailer operators who use their personal accounts for remailing could establish a Penet anonymous ID and password for personal use, and be confident that remailer users would not be able to send mail through Penet that would be delivered with that anonymous ID exposed. Also, we could patch the remailers to add the X-Anon-Doubleblind: no line to mail which goes out to Penet, just in case the user forgets. (I don't think there is a need for mail through one of our remailers to be delivered to Penet with an X-Anon-Password, since only the remailer operator knows the correct password to use, so virtually no one would be able to use this feature.) I am confused about the exact rules that Penet uses to decide when a password must be given. I get the impression that if no password has been registered, anonymous posting and mailing to non-anonymous addresses is forbidden, but you can still mail to anonymous addresses. If a password has been registered, you must give it to do any of these three things. Is this right? Hal

2 1

No Subject
by nowhere＠bsu-cs.bsu.edu 23 Feb '93

23 Feb '93

In-reply-to: Johan Helsingius' message of Tue, 23 Feb 1993 10:52:16 +0200. <9302231011.aa20353(a)penet.penet.FI> -----BEGIN PGP SIGNED MESSAGE----- > > Well, I don't agree that doubleblind is a great idea. > > Neither do I. But many of the users of anon.penet.fi are > not very computer-and-email-literate, and they have been using other > services, providing double-blind. Unfortunate, but too late to change now... Can you elaborate on those other services? The Finnish remailer is the only one I'm aware of. Also, I'm confused about these "not very computer-and-email-literate" users -- aren't they forced to use an X-Anon-Password header? I'm surprised there hasn't been more ruckus about the default behavior. There must be many folks whose identities have been inadvertantly exposed. > What we can do is to provide better ways for those who *are* computer > literate enough to use extra headers etc. I don't think this will help. With my mail environment, I have to go to lengths to send an anonymous message, concocting X-Anon-To and X-Anon-Password headers. It's worth the effort, since this helps to preserve the secrecy of my pseudonymous identity. But the first time I mess up, and send an unfettered message to an anon.penet.fi client, I am unmasked. What I'm saying is that I'm hip to headers; it's the simple stuff that trips me up. And I still don't understand how the unfettered message gets past the X-Anon-Password filter. > > I think it's imperative that the sender use X-Anon-To to be > > pseudonymous. This is consistent with the principle of least > > astonishment. > > But in this case I feel the principle of least astonishment is overruled > by the principle of least risk of accidental exposure. I think the risk of accidental exposure is heightened by the default behavior of the Finnish remailer. Maybe we're using the same words to describe different things. > I think that hornet's nest needed to be kicked. But I am also > disappointed that not enough people defend the need for anonymity in > places like news.admin.policy. Some of us gave up on USENET policy long, long ago. Personally, I stick to the alt.* groups. > I think pseudonyms *should* be prominent - as you have noticed, anon.penet.fi > adds an explicit warning at the end of every message. In time, I hope such warnings will be unnecessary, as people grow accustomed to the use of pseudonyms. DEADBEAT -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK4o0+PFZTpBW/B35AQGlcAF/UC0HNtSoIQe2arEoK5uzkjX+7fCwPUqC l/2o0wifS7SLGLfoshQpd3vaczDktaBV =TPtY -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi. *IMPORTANT server security update*, mail to update(a)anon.penet.fi for details.

2 1

No Subject
by nowhere＠bsu-cs.bsu.edu 23 Feb '93

23 Feb '93

In-reply-to: Johan Helsingius' message of Tue, 23 Feb 1993 09:32:54 +0200. <9302230851.aa19921(a)penet.penet.FI> -----BEGIN PGP SIGNED MESSAGE----- > > The problem became > > apparent to me when I sent pseudonymous mail to a prominent person on > > this list; his reply exposed his pseudonymous id at anon.penet.fi, > > surely without his knowledge. > > I think this would be fixed by the "X-Anon-Anonymize: no" (or whatever) > hack. But for reasons I have outlined in the earlier round of > discussions, it can't be the default. Comments? If it's not the default behavior, then it will be a recurring problem. > There has been a lot of discussion about this, and I'm afraid it's too > late to change the *default* behavior now... Why? It seems to me the X-Anon-Password header was a pretty major change, yet you made that change to preserve people's pseudonymous identities. The instant challenge is just as grave, don't you think? > P.S. In case I forgot to announce it, as you could see from the message > I'm replying to, PGP stuff doesn't get stripped at anon.penet.fi > anymore..... Great stuff. Thanks. DEADBEAT -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK4o8FfFZTpBW/B35AQFQgwF/QU9NQmgtFKfv+KMoghtSwTL/e8vh3G4b vwlZy3yWF6D4+LVAnOEcuh0gvxJSNi51 =hD4O -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi. *IMPORTANT server security update*, mail to update(a)anon.penet.fi for details.

2 1