- cypherpunks-legacy - lists.cpunks.org

REAL WORLD ENCRYPTION
by Sandy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Sadly, I think the following topic is the real crux of most people's objections to the deployment of digital banks on the Internet. NIGHT OF THE LIVING G-MEN--Some of you have opined that the Federales will never give us a license and/or will go after us once we are in business. First, we will not have our license, charter, offices or personnel in the USA. We will locate our operations only where are services are protected by the local authorities. Second, there is no law forbidding Americans--or nationals of most western countries--from doing business with foreign banks. We and our clients will be in compliance with all relevant laws. Third, even if the powers-that-be don't like what we are doing, there is very little they can do about it. They haven't invaded Cayman, Hongkong or the Isle of Man because of their banking operations, I seriously doubt they will do so on our account. For those who will only settle for *absolute safety*, I am sorry to say, no such thing exists in the real world. All benefits entail some risks. Not creating and using digital banking, however, may be the riskiest thing we can do. S a n d y Those who profess to favor freedom, and yet deprecate agitation, are men who want crops without plowing up the ground, they want rain without thunder and lightening. They want the ocean without the awful roar of its many waters. --Frederick Douglass P.S. Send UNencrypted e-mail to "sandfort(a)crl.com" and PGP encrypted e-mail to "ssandfort(a)attmail.com". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWUO8k5ULTXct1IzAQHdSwQAg1fuo5A5Zqst21WkyWKilbqnuHG1C2KA lweB33dLftuu19xzQrJDyfvvZuhS1RzzXao6kDdKkYHEC4L4rwtQXaERWa0mXWU9 E/zfrXXTPoyOD3asCrg15vCrHyfWqaYRPO6lMDXzux8FdeCGuh900azqFH7fkaSn GJhPnLwZgqs= =AU5a -----END PGP SIGNATURE-----

1 0

Re: Message Havens
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal wrote: >Karl's idea about message havens is interesting, but I don't fully >follow how it differs from the anonymous pools we discussed last year Well, the biggest (and maybe the only) difference is mail doesn't leave the haven. It's like a post office box, you have to show up to retrieve your mail. - From my experience running remailers, posts other operators send here, general observations, and various attacks we've all suffered through, it seems like most of the problems/objections we get stem from the fact that anonymous remailers (drum roll...) actually send mail! For example: * Eli just sent a message about somebody who used his remailer to mailbomb something... *this list has been victim to the rantings of various individuals anonymous and otherwise. *somebody forwarded a ClariNet post through Scott Collins' remailer thus causing him difficulty *remailers operators have to fear some fool will remail to whitehouse.gov (or the operatros have blocked that address) *the message pool Miron runs is susceptible to mail bombing I'm not saying we should junk the anonymous remailers and replace them with message havens... it's just a suggestion that may solve a few problems we are having. Until positive reputation filters show up and everybody digitally signs their posts, etc. Digital cash payments for each message stored would greatly reduce the mailbomb problem for message havens as well as anonymous remailers. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdL1ToOA7OpLWtYzAQEoigP+PmJtyybo24swqPD5MaDRhuvwKhhMMfn7 txaTbdVM8mzoKWgKlsB2Sw89ZO2CMl7Rijv4kgmdaxTBL278p7CuescTmRnwYACr ArlH9DSDsM9eXqVq2jLd33J2PBWhBnpn5TdOOUIJZ7B7HrT0KgaIzFv7lGhsBXQy PUh87BWOhE4= =8T8B -----END PGP SIGNATURE----- -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

Re: Message Havens
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Downloading the whole message base to scan for one's messages >will place a massive load on net.resources, and probably >a prohibitive load on most people's terminals. I disagree. The only resource that will be hit is the message haven (unlike say every computer in the world that carries the certain usenet group you have chosen to use as a communications vehicle). Geez, think of like a place that offers anonymous ftp. It's resources are hit, but I don't buy the "massive load on net.resources". The only load I can envision being hit on a person's terminal is the time it would take to browse all messages. You have to read each message and have your communications software log in a file, or scrollback/record each one individually. I mean, the info is already coming to your computer, you just have to save it. Maybe the haven could offer a way to get all the days/weeks/whatever files in one big chuck; this is clearly no worse than just ftp'ing a large file. > This scheme should avoid this nescessity: This scheme is precisely what I described earlier! The two users agree on what to name/tag the file, and that's how they get messages to each other. The problem is Bob can't just retreive that one file (if he is concerned about traffic analysis), so he can get them all so a watcher learns nothing. You have suggested downloading a smaller portion of the available message base instead of the whole thing. >The gopherhole must be trusted not to divulge which posts came from >who, and it's key must not be compromized. Alice and Bob can get their messages to the haven via anonymous remailers to avoid problem #1. I didn't envision the message haven even having a key. It isn't needed if they both are encrypting with the other person's key anyway, so I'm not sure what problem #2 is. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdL5hYOA7OpLWtYzAQHx8QQAtlVYJvSGyR0uGq8a8IodCewZNBwSVHou 7YJssBHIBp/I+V+s1fMpBkUSmG6oINu5L/VEeEQXRswHGJJ/F6jLtxkrFlY/kcff XKTqizrroVtemYQpZtjpPowT2eQsdlonewbslZc3Y+GdZfErgCzoiYW2dXIX8tnG yD2OvZKCAYs= =i3Ea -----END PGP SIGNATURE-----

1 0

Someone yanking your chain? (rather than LD`s account...)
by pgpkeys＠wasabi.io.com 17 Dec '03

17 Dec '03

Hey, maybe its just me, but when I saw "Steve Dempsey"s first mail to cypherpunks come time ago where he represented himself as Lance`s postmaster, I thought "funny, this guy writes just like Detweiler when Detweiler is acting sane..." So Dempsey has now said that he`s chopped LD`s account...Hmmm... How come this was posted today? > From: ld231782(a)longs.lance.colostate.edu (L. Detweiler) > Newsgroups: sci.crypt,comp.society.privacy,alt.privacy,sci.answers,comp.answers,alt.answers,news.answers > Subject: Privacy & Anonymity on the Internet FAQ (1 of 3) > Date: 18 Feb 1994 15:22:13 GMT ^^^^^^^^^^^ > IDENTITY, PRIVACY, and ANONYMITY on the INTERNET > ================================================ I also notice while you were all wondering where LD could still be getting his cypherpunks feed from, Dempsey had become a subscriber to the list. (You guys really should block that EXPN command you know...it`s been mentioned often enough...)

1 0

New Remailer up!
by Matthew J Ghio 17 Dec '03

17 Dec '03

At last, my long-promised pseudo-account remailer is open for testing. Here's how it works. Send mail to mg5n+getid(a)andrew.cmu.edu you will receive back an encrypted email address of the form: mg5n+eaxxxxx(a)andrew.cmu.edu (ea=encrypted address, in case you were wondering) All mail sent to that address will be forwarded to you. When you post anonymously, you can include that address for people to make replies to. That way, people can send replies to your messages but not know who you really are. Most of the cypherpunk remailers allow you to insert a Reply-To: header. Random padding is added to the address before it is encrypted. Therefore, every time you request an encrypted address, it will be different. This allows you to get a different email address for each of your cypher-tenacles. :) Messages sent thru the remailer are not anonymized. The complete, unaltered message is forwarded. If you want anonymnity, first send your mail thru one of the anonymous remailers. Source code is availaible. Email me if you want it. P.S. Expect a moderate delay for messages sent thru this remailer.

3 3

Mixmaster Test
by John Anonymous MacDonald 17 Dec '03

17 Dec '03

Sorry for the spam, folks ... just looking for a mixmaster that puts the Subject: line into cypherpunk messages. Name-Withheld-By-Request Editor in Chief, Cypherpunk Enquirer

1 0

Mixtest
by John Anonymous MacDonald 17 Dec '03

17 Dec '03

Sorry for the spam, folks ... just looking for a mixmaster that puts the Subject: line into cypherpunk messages. Name-Withheld-By-Request Editor in Chief, Cypherpunk Enquirer

1 0

Just wrote a simple perl script to autosign messages
by Sameer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I just a simple perl script which autoencrypts a message based on the To: line.. it's not very robust, but: The To: line must be of the form: To: Name <address> To: address (Name) To: address It uses a userid of "address" to encrypt. It doesn' allow multiple names on the To: line. #!/usr/bin/perl $pgp = "PGPPATH=/home/sameer/safe/pgp /usr/local/bin/pgp" ; $header = "/tmp/header.$$" ; $body = "/tmp/body.$$" ; open (HEADER, "> $header" ) ; while(<>) { print HEADER $_ ; $to = $1 if /^To: (.*)$/ ; $to = $1 if /^To: .* \<(.*)\>$/ ; $to = $1 if /^To: (.*) $.*$$/ ; last if /^[ \t]*$/ ; } close ( HEADER ) ; open (PGP, "| $pgp -eaf \"$to\"\ > $body" ) ; select (PGP) ; print <> ; close (PGP) ; select (STDOUT) ; open ( HEADER, $header ) ; print <HEADER> ; close HEADER ; open ( BODY, $body ) ; print <BODY> ; close BODY ; -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWm2Rni7eNFdXppdAQHB1gQAjOVUdh+45+u1t9hiYS6IeK5A0LoRWpS/ 3ekx8ohTudmXND1OKr3r9j9mjWtZr8TD8Upc7rVy6Ez3P7vdHa75uiuqzy4mwaUM ORDrBL19gjqR9w8leoSylFpNRAHVOCTx4NzoFpDTEXWpGcq6fF7jL4OPpRIMH7lj hkIuR7BnAjY= =AxMi -----END PGP SIGNATURE-----

1 0

Ladder DES
by ritter＠cactus.org 17 Dec '03

17 Dec '03

Ritter Software Engineering 2609 Choctaw Trail Austin, Texas 78745 (512) 892-0494, ritter(a)cactus.org Ladder-DES: A Proposed Candidate to Replace DES Terry Ritter February 22, 1994 Introduction Data enciphered by DES, the US Data Encryption Standard, has become vulnerable to modern technical attacks. Currently, such attacks require substantial capital and high-tech engineering development to produce a special "DES breaking" machine. However, once such a machine is built, attacks would become relatively fast and cheap. Businesses which currently protect very expensive and marketable secrets with DES should take immediate notice. To maintain earlier levels of security, DES must be replaced with a stronger cipher. The one obvious alternative to DES is a simple construct built from DES called triple-DES. Triple-DES, while generally being thought of as "strong enough," also carries the baggage of requiring three times the processing of normal DES. Because every security system is required to provide more benefit than its cost, raising costs by a factor of three (when compared to the alternative of normal DES) is a significant issue. Such costs could dangerously delay the retirement of ordinary DES. Requirements The goal of this sequence of designs is to identify one or more better candidates to replace DES. Obviously, the first requirement is that each candidate be substantially "stronger" than normal DES. One problem here is that we can only _argue_ strength, so it is important that candidate designs be openly presented and reviewed. We cannot expect that most proposals will withstand such review. The second requirement is that each candidate design also be faster than triple-DES; otherwise, we might just as well use triple-DES and be done with it. Speed is a measurable design quantity. My third requirement is to include operation on data blocks larger than the 8-byte DES block. Although DES is not normally used in a way which is conducive to "dictionary" attack, such attacks could be effective on the bare cipher itself. This raises the possibility that a "certificational" weakness may exist which we currently do not know how to exploit, but which may be dangerous anyway. This particular weakness depends upon small blocks. At this point there is still some question as to whether it is _possible_ to come up with candidate designs which meet these three requirements. Ladder Diagrams DES itself is frequently shown in figures which are described as "ladder diagrams" because of their appearance: | v Initial Permutation v <-- SPLIT --> | | | k1 | v v | XOR <-- f -----| | | | k2 | | v v |----- f --> XOR | | . . . | k16 | | v v |----- f --> XOR | | | | --> COLLECT <-- v Inv. Init. Perm. | v This is the data-transformation part of DES. Not shown is the key-schedule computation which produces k1 through k16, the 48-bit "round" keys. Also not shown is the construction of function "f." It will later be interesting to note that in DES each 32-bit data rail value is expanded to 48 bits, the XOR occurs with a 48-bit key, and the result contracted to 32 bits in 6-bit to 4-bit substitutions known as "S-boxes." Ladder-DES Consider this simple construct which looks something like two rungs or steps on a ladder: A B | k1 | v v | XOR <- DES1 ----| | | | k2 | | v v |---- DES2 -> XOR | | v v C D A, B, C and D represent 8-byte blocks; k1 and k2 represent 56-bit DES keys. This enciphers two DES data blocks in two DES operations; this is a data rate similar to normal DES. It can be described as working on a single large block composed of A and B. Note that the data paths are twice the size of those used in DES itself. Also note that the design is asymmetric: While ciphertext block C is a function of every bit in plaintext blocks A and B, as well as every bit in key k1, ciphertext block D is _also_ a function of key k2. Known-Plaintext Attack on Two-Rung Ladder-DES With known-plaintext, we essentially have a single-DES complexity: Since A is known and C is known, the output of DES1 is known. Since the input to DES1 is also known, to find k1 we just do a normal DES search. Alternately, since B is known and D is known, the output of DES2 is known. Since the input to DES2 is also known, to find k2 we just do a normal DES search. Total complexity: twice DES; thus, hardly worth using. Four-Rung Ladder-DES Now consider a similar construct, twice as long: A B | k1 | v v | XOR <- DES1-----| | | | k2 | | v v |---- DES2 -> XOR | | | k3 | v v | XOR <- DES3 ----| | | | k4 | | v v |---- DES4 -> XOR | | v v C D A and B are 64-bit DES blocks; k1 through k4 are 56-bit DES keys. A total of four DES operations process two DES blocks at double-DES rates. We would expect this to be both stronger than normal DES and faster than triple-DES. In general, the left-leg of a ladder-DES structure is affected by one fewer key than the right-leg. Belief Can we "believe" in this basic structure? Well, DES itself is based on it. But we do need to remember that DES also includes seriously nonlinear data expansions and contractions around each XOR. Certainly expansion and contraction could be added to ladder- DES, although this could be expensive. (To avoid specifying particular S-box contents, we could specify a cryptographic RNG which would be used to permute a base S-box arrangement; this should also avoid normal differential attacks.) It is not clear that the lack of expansion and contraction operations necessarily negates the overall approach. Key Reduction The four-rung ladder-DES construct uses four 56-bit DES keys, but certainly a cipher would be strong enough if it had "only" a real two-key (112-bit) keyspace. Thus, we might consider making k3 = k1, and k4 = k2, or perhaps, k3 = k1 and k4 = k1 XOR k2. On the other hand, perhaps it would be worthwhile to support additional keys simply to avoid the necessity of showing that a reduced key approach could never reduce strength. Known-Plaintext Attack on Four-Rung Ladder-DES No longer do we have the advantage of knowing both the input to and the output from XOR operations, so we can no longer gain access to the output of particular DES operations. Thus, the obvious search strategy is not available. Divide-And-Conquer Attack on Four-Rung Ladder-DES Normally we try to separate the effects of the different DES operations, so we can "divide and conquer" each separately. In this case, DES4 is the obvious first choice, since with the keys k1..k3 fixed, only k4 affects the output, and then it only affects block D. However, unless we know the values of k1 and k2, we don't know the input to the bottom XOR, and so apparently cannot separate DES4 to work on it. Meet-In-The-Middle Attack on Four-Rung Ladder-DES With four keys involved, and no obvious "middle," it is not clear how this attack could be applied. 2x Four-Rung Ladder-DES The basic Ladder-DES construct can be expanded to cipher four blocks at once: A B C D | k1 | | k2 | v v | v v | XOR <- DES1 ----| XOR <- DES2 ----| | | | | | k3 | | k4 | | v v | v v |---- DES3 -> XOR |---- DES4 -> XOR | | | | v v v v E F G H Re-arrange Blocks H E F G | k5 | | k6 | v v | | v | XOR <- DES5 ----| XOR <- DES6 ----| | | | | | k7 | | k8 | | v v | v v |---- DES7 -> XOR |---- DES8 -> XOR | | | | v v v v I J K L This construct enciphers four DES data blocks in eight DES operations; again, this is a speed comparable to double-DES, and substantially faster than triple-DES. Ciphertext block I is now a function of every bit in plaintext blocks A, B, C, and D, as well as every bit in keys k1, k2, k4, and k5. Every bit in the 64-bit I is a complex function of 480 bits. We could certainly afford to reduce the number of keys in these constructs, and this might be done in any number of ways. For the 2x construct, for example: k2 := k1 XOR k3; k4 := k3 XOR k5; k6 := k5 XOR k7; k8 := k7 XOR k1; leaving us with a need for four keys: k1, k3, k5 and k7. It is also possible that the same two keys could be used in every two- rung ladder-DES section, for a total of two keys. Conclusion DES operations can be arranged into a "ladder-DES" constructs which are especially-clean and familiar and seem to resist known attacks. These constructs seem potentially stronger than normal DES and are demonstrably faster than triple-DES. Thus, ladder-DES could be a reasonable candidate to replace DES.

1 0

Who is "M"?
by Lucky Green 17 Dec '03

17 Dec '03

I met a person named "M" at Tim's party a month ago. Would somebody please email me some contact info? Thanks, -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred Member JPFO. "America's Aggressive Civil Rights Organization"

2 1