December 2003 - cypherpunks-legacy

A crypto-oriented inet connected household
by Sameer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is something that I've decided to do, and we have to get working on things, quickly. Check it out-- if you're interesting joining this thing, mail me, and we'll talk. (sameer(a)soda.berkeley.edu) The idea at this point is to get a place in June, and then get our net link maybe in the fall or winter sometime. (We'll likely have a SLIP link starting in June.) If you're not a hacker/tech/geek/etc. -- don't worry. Read through this and if you think there's something you can contribute, we can talk. The name "NEXUS-Berkeley" *really* needs some improvement. We haven't thought of a good replacement yet. (This is still a draft) 1) Introduction What's the NEXUS-Berkeley Project all about? It's a lot. There are goals, and there are dreams. Most of all though, we're optimistic. We know we can do it. So, then.. what are we doing? We're hardwiring the Gaia Consciousness. In other words. A bunch of people who want high-quality net access to their home are getting together, pooling funds, so that they can do it. That's us, the NEXUS-Berkeley folk. Our plan right now is pretty simple. We're going to find a place in Berkeley to move into. Thus we all have to work on how a bunch of net-fiends like ourselves can live together. Then we're going to get a dedicated line to the internet, and connect it to out home network of computers. I'd like to see a terminal in the kitchen, the bathroom, a few in the living room, and personal privately owned machines in each individual's bedroom. All this hardware will be wired together into a local network, which is then connected to the internet, via a dedicated line of some sort. Then we're going to start moving towards self-sufficiency-- providing internet services to the local community to bring in income. Minimally, the net-link should be paid for by our income. Ideally, we'll have enough income to pay the rent. The first step is shell accounts, sold cheaply. We can't compete with the giants, netcom, crl, etc. We will provide a service along with the shell accounts that won't be found at the giants-- a community-oriented personalized approach. We want to build a community around this thing. We'll have a local BBS, monthly meetings, internet tutorials, and maybe even parties, where the attendants can take a break from dancing and log into vrave. We don't want just tech-folk, though. We want BALANCE. We need writers, artists, teachers, techies.. If you have a talent, it's likely that the NEXUS could put it to good use. We need teachers to run the tutorials. Artists to make flyers and decorate the place. Writers to write press releases and other written work. Sociologists to study us and keep us from killing each other. 2) Technical issues A) The link We have a bunch of options for the link. For startup we can probably only afford at 56k line. There's a few choices in that regard. We can go with The Little Garden, a cooperative, whom Sameer would very much like to deal with, because of the cooperative nature of it all. There's Internex-- they provide ISDN, which is high-bandwidth, but right now ISDN runs .01/minute. If ISDN ever goes to untimed service it would be excellent, but I'm not counting on it. There's sharing 5 SLIP lines with another site, which has the benefit of cost, and a max-throughput of 56k, but it's sharing it with another site, which has its obvious drawbacks. If we want to resell the link 56k can only last so long. T1 is an inevitable situation. We will probably end up with an overbooked T1 [The Little Garden] and move up from there (time and money will tell) The provider is also quite up in the air. We can't be positive who we will want to deal with. Demand exceeds supply, so finding a provider who is civil and non-anal retentive about usage could be a chore. (Sprintlink seems like a good option.) B) The computers and hardware We'll need a main computer (or cluster, depending on how much CPU-power we need) which is owned by the group, some terminals, (bad ones for the kitchen & bathroom, but good ones for the living room) a router, and a CSU/DSU pair. Individual resident members should use privately-owned computers for their rooms. I'd like to have it set up so that there's a main NFS-mounted filesystem with most stuff, email, news, general files, but each individual's private computer is very isolated and paranoid about security, where they can store sensitive things such as PGP private keys. CFS can also be installed on the personal workstations, so that private computers need not have that much local drive space, while preserving privacy. The main choices of processors seem to be quite numerous. We have pretty much ruled out intel processors at this point. Sun and DEC seem to hold the most promise for servers. We have to learn a lot more about machines before deciding what will suit our needs. We can get something used. What kind of ethernet are we going to use? How fast will it be? What vendor? C) Machine Speed/Upgrades We will constantly be wondering exatcly where our income will be best spent. Trying to make sure all of the hardware we have is up to the task is going to be a royal pain. Each upgrade brings new problems and exposes new bottlenecks. A vitally important factor is machine speed. People hate waiting 30 sec to a min for their mail or news to index or for a program to start. This gets people complaining fast. Batch processing: For incoming mail and news, we can deal with slower machines here, but we will need power news and mail get backed up at another site and we get hit with a deluge all in one day (this happens more than you may think) We should probably allow users to use 5 megs of diskspace with maybe a one dollar per meg per month charge for diskspace used over five megs. We need need to know this before we know how much HD space to buy. D) Dialups This is a HUGE pain in the ass. The system Aron currently on staff for (eskimo.com) has a basic policy of 90% free. Meaning 90% of the time you get through on the first try. This has worked out to 13 users per dialup. We will likely find something similar. Optimally I would like to see around 10 per dialup, but resources will again be a factor. E) Miscellaneous Services Games: Something where the user has a graphic client at home and uses our machines to communicate with other users in the same general area or around the world I know DOOM can be played on networks. It would be interesting to talk with id software and see what we can hack together. 3) Social issues A) Residents We have to decide how many resident members we want. They all have to be pretty compatible in living style, as well. It seems that 5-10 would work out pretty well, with seven as the ideal. We also need *balance*. We need techs, artists, writers, teachers, and more sorts to round out the local community. A household full of tech/hacker/geek-types won't be well-rounded enough for my tastes. (Well all be net-fiends, though, of course.) Residents will be those that can make a healthy commitment of time and money to the nexus. Time and a desire to work are *clearly* more important than the size of your monetary contribution. We will however need a decent amount of capital to get the ball rolling. All types of people need apply. We have enough people to run the tech end of things even now (though we would like a few more). We intend to try living together for a month or 3 to iron out the kinks before sinking our hard won cash into a ton of equipment. There are a ton of horrible nasty issues that have to be worked out before we can even THINK of doing this seriously. B) Local community We can set up a BBS to serve everyone in the community, to help foster the community-oriented aspects. Sameer thinks that the local discussions groups should be accesible ONLY via the BBS (hopefully we can find a good free BBS system for UNIX) because there's an entirely different feeling when accessing something via a usenet newsreader than a BBS interface. We want people logging into the BBS (if they want to login directly to a shell that is cool too) as the default. Something that is intuitive and user friendly. Something that encourages communication between our customers. Encourages them to make their own spaces within the BBS (various conferences or groups-- it should be trivial for a user to start his or her own local group). We should encourage people use the machines for thier projects and interests -- hopefully things we haven't even conceived. It is important to get the users as involved in the bbs as possible. Aron has noticed that people will put up with a lot of crap if you tell them *why* it is happening and *what* is being done to fix it. Encourge folks to build a place where they will feel comfortable. Once again the community aspect of the bbs is key, it is the only thing we will be able to offer folks that crl and netcom can't. Although I do not want to do this at the expense of performance, community is something that we can only work to foster; if we pull it off will not cost us anything in the way of money. Although 95% of all muds are complete shit there are a select few that are very much worth playing. They also do a ton for a community vibe (at least some of them do) This is another thing that can start small (depending on resources) and grow to hugeness. C) Nexus Fissioning These are basically the issues of nexi fissoning, or ouside parties with the recources to do so "glomming on". Most of this can be addressed at a later date. D) Meetings User meetings are key. We nned to be able to meet these folks face to face and show them that we are in fact real folks. It makes people feel better about the service and enhances the community vibe. Aron would suggest monthly meetings. Sunday afternoons are usually the best time. A place like a pizza joint usually has no problem with this since they get little buisness on sunday afternoons. Also that is the time most people will be able to make a meeting. Before Aron left Seattle eskimo was getting between 20-30 folks a month sometimes as many as 50. He's sure it has swelled since eskimo's subscriber base has exploded. 4) Economic issues A) Incorporation We should get an EIN, and a bank account, and all that good stuff, but the question is whether or not we should incorporate as a non-profit? It has been mentioned that the "safest" way for us to go about organising as a buisness is to organise as a corperation. This protects us from being sued as individuals and has tons of other nice benefits-- limited liability. There are also numerous reasons we would like a corporation for tax reasons, because by moving personal expenses to corporate expenses we can get bigger tax writeoffs. B) Incomes for residents At the outset everyone will need day jobs. C) Self-sufficiency Once the nexus becomes self-sufficient (I'm optimistic) dealing with new arrivals/departures will get VERY interesting. D) Shell accounts for the community We can provide dialup access to the net, and our edge on the big providers will be the niche market I've been talking about. The community-oriented approach will give us our market. I'd like it to be sorta like the well but less expensive, and less elitist. Monthly meetings for users, occasional parties, and the like will build a strong commitment between the nexus and the dialup members. A good pricing structure could be $15/month, $30/quarter, and $90/year. F) Anonymous crypto services 5) Projects Projects will be what gives us noteriety in the E and RL communities. They will also be a major source of income (depending on the nature of the project obviously). Hopefully, they will also be a hell of a lot of fun. We need any and all ideas for more project areas. People who joined the NEXUS-Berkeley will have to decide for themselves how they can contribute using their own particular skills, in their own project. Thus before anyone joins the NEXUS-Berkeley an individual should write up an informal "Project Proposal" such that their commitment is made firm and we know how they'll be able to help. We will be writing up a "Request for Projects" and posting it among various newsgroups, so that interested people may join us if they so desire. A) Programming Being a mostly E oriented group (although not totally E, but that will be the focal point and that which brings us together, a facilitator if you will) we will most likely have tons of programming projects going. Some of which will relate directly to the BBS, others which may have uses to a variety of people. Writing free software for net distribution and the like. The majority of the things below are just ideas I am throwing at you. Feel free to pick them up and run or add your own. B) AI This is an interest of Aron's and he would like to work on various things in this area. C) Graphics Eye candy anyone? SGI or Amiga kinda stuff here, Dunno how we can turn it into money though I *know* there are many ways. We could possibly offer the basic scanning and manipulation services in order to help pay for the workstations and other assorted equipment. D) Cryptography Sameer is very interested in implementing and developing cryptographic and anonymity tools through the Nexus for fun & profit. There is a good deal that we can do, including pay for use anonymous remailing services, anonymous IP forwarding (IP laundry) TCP in UDP tunnelling so that nomads can have TCP/IP connectivity whereever they have a telnet dialup. Each of these schemes can bring in a good sum of money, if arranged properly E) Operating Systems Have you ever been 100% satisfied with the OS you were using? Although the manpower (ok personpower) for such a massive undertaking would not come solely from the Nexus. I do not see why it could not be a focal point for development. There is a ton of public domain code to start with and build on. I would favor a microkernel UNIX variant. We could offer free accounts to other folks who are willing to do coding (up to a reasonable level). We could offer a full blown killer OS for the price of Windows or System 7. Aron fully realizes this is one of his "lofty" goals, but he would love to see it happen. F) Zines Chris Blosser has expressed his desire to publish a 'zine for his contribution to the project. It would be a wonderful form of community building, including merely public relations all the way to contributions from subscribers to the various services which we will sell. G) Music Making money in that buiness? If we had the space (correctly zoned of course) we could put on shows of various types, showcase slightly obscure bands, and make some money in the process. There is quite a bit of shit to consider insurance and crap. We could incorporate the net into our music making-- some intercity/international collaborative music-making would be an excellent project. This could be incorporated into collaborative artwork as well, similar to things such as the OTIS Project. H) Raves & Parties As for a raves and rave like parties, these are other things we can do (both free and for profit though if anyone wants to throw a $20 event we will kill them) We have a few folks who are knowledgeable about what to do here. It would be really great to put on parties at which we have terminals available, either logged into vrave or connected with other Nexus-homes across the world each of them holding parties at the same time, so that international parties can be arranged. Sameer has mentioned this idea to many people and they are very interested-- this seems a great way of getting people interested in becoming members or simply attending our parties. Of course there are concerns about securing the equipment and noise in the neigborhood. And numbers of people. This is a great idea for community building. Do we even let folks know where the house is? All these party ideas are great, but do we really want a ton of people we don't know, knowing that we have 100 grand worth of equipment in our house? Security is a big issue here, as well as the fact that we may not have enough room to pull shit like this off. This is definetly something that needs to be hashed out. I) Testers We will probably end up with a wealth of people who want to beta test our projects. We can offer incentives to these people as well (although early use of the program should be enough). 6) The house A) Location Sameer wants it to be close to the UC Campus. Sameer attends the UC, so I'd like to live close by. There's more people in the area, which is a plus, as well. Choosing a place close to the PacBell's Berkeley Cental Office would give us improved line quality and a cheaper leased line. The location is to be somewhere in Berkeley, while there is also a small possibility that the house could be in San Francisco. There are a variety of factors involved, some of which will not be resolved for a while. There is also a more miniscule possibility that the nexi will fission off before even getting started with locations in each city. (If we end up with say 20 *seriously* interested people this would be the most likely scenario.) B) Size The house should be large enough to house 5-10 people (around 7 being considered optimum) When it comes to floors and number of rooms, that is still up in the air this depends mostly on how people want to live, some can handle living in rooms with one or 2 other people while other people *need* thier own space. Ideally, the lower level would be with a kitchen, living room, and bathroom, and the upper levels would house the private spaces of all the residents, so that we can host parties while preserving the security of each individual resident's space. C) Cost ??? I don't know much much a 6 BR place near campus costs. I read one ad that was a 6 BR place, allegedly "close to UC" for $2400/month. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWmcq3i7eNFdXppdAQHS0AP9EvGLjvpZf/p2uSaywniS2GW/gMiP7P1P UKc9Dt5Sh8bhxFlW/pc2UsR7x4Xx2/qdkYHMbSP/KjbBJTa7viXtqLIP63vrgScz 9TaY6suKaelp7Hzg+S9zxbkzxry1LwXFpmGkxGze8prOG4FdEXCPQALCfaQI/E9U xHEPWrALQZU= =PqFj -----END PGP SIGNATURE-----

1 0

Young cypherpunk seeks summer position in the Bay Area
by Sameer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- (Could some exi-bayer please forward this to the main Extropians list? I've been busy lately and unsubbed. Thanks.) This young motivated, energetic, talented cypherpunk is in search of some sort of summer position, internship, whathaveyou which will use his skills to the fullest. I've been hacking UNIX for the past three and a half years now, and I've been employed using UNIX for the past semester. I've been spending much time outside of class & work learning perl and other fun elements of UNIX-- I've installed linux and xwindows on my roommate's 486. I've recently been working on a fully anonymous anon server which protects users against direct attacks upon the server itself. Although I spend a great deal of time outside class learning to administrate my local machine, I have still found the time to do well in my classes. I plan on majoring in both Computer Science and Physics because they are both so compelling that I can't choose one or the other. While I would prefer a position which is BARTable from Berkeley, because I don't own a car, I can probably get a car if needed. -Sameer SAMEER PAREKH 2650 Durant #802F Berkeley, CA 94720 510-643-1741 (voice) 510-321-1014 (pager) sameer(a)soda.berkeley.edu OBJECTIVE: A summer position in the Bay Area utilizing my computer skills. EDUCATION: University of California at Berkeley, Berkeley, CA 94720 Graduation: 1997 Intended Majors: Computer Science/Physics --- GPA: 3.9 Libertyville High School, Libertyville, IL 60048 Graduated 1993 --- GPA: 4.343 Class Rank: 8/460 Languages: 5 years Spanish, 3 years Latin COMPUTER EXPERIENCE: Systems: UNIX (System Vr4 & BSD: SunOS, Ultrix, HP/UX, Dell, Dynix, Linux), XWindows (tvtwm, olvwm), MS-DOS, Macintosh, GS/OS Languages/ Shells: C, C++, Perl, Awk, Sed, Bourne Shell, TC Shell, Scheme, Pascal, BASIC EMPLOYMENT: Assistant Network Administrator - Haas School of Business Computer Center September 1993-Present o Install network hardware/software o Write programs and scripts for the day-to-day administration of the UNIX computers, including automated mail alias creation and modification o Write and maintain UNIX scripts to manage mailing lists, gopher, and other UNIX services Student Technician - Libertyville High School March 1992-June 1993 o Operate lighting, sound, & fly systems for private groups renting the school's theatre and auditorium facilities o Train underclassmen in operation of lighting, sound, flies, and other technical equipment o Responsible for operation of auditorium facilities for school events, including concerts and assemblies ACTIVITIES: Computer Science Undergraduate Association AWARDS & ACHIEVEMENTS: National Merit Scholarship Finalist Illinois State Scholar Advanced Placement Scholar Semifinalist for the US Physics Team Junior Engineering Technological Society District Competition First Place Physics Third Place Computer Fundamentals Most Valuable Team Player State (Illinois) Competition First Place Physics Fourth Place Computer Fundamentals REFERENCES: Available upon request -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCUAgUBLWmf7Xi7eNFdXppdAQHkLwP3XBGQrvKGxk0l7TxRqBE5ghOjA+Ojo+Cp EJx207mn+6yjR4UNLheHSPGWQhG7RtYsH6ziXR2XqfjBNv7YSMG6Tb5nmteySTMO 4uy7I8dozZ4mQBf+sAbkvk0SpSgw+Md9lz6WRmUI2PCbQSwHlHbp5zgoqpwk9AY7 4DFzz3GeNw== =g5Wv -----END PGP SIGNATURE-----

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

PGP Tools question, and soda archives.
by Seth Morris 17 Dec '03

17 Dec '03

Hey all. I've been trying to get the PGP Tools library to work on my system (MSDOS, Turbo C 2.0, 286), and have been having a hell of a time. Aside from the problems getting the makefile to function here (the DOS 127 character command line limit killed the ptd.exe cc line), the demo locks up in fifo_destroy. Looks like there's a missing NULL termiantor. Now, I saw a bug fix on the list a few days (weeks?) ago, and I'm not certain if the file I have has that included (pgptl10c.zip), so I tried to check the cypherpunks archives at soda.berkeley.edu to find the reference. I don't have shell acces here (have to use a menu, can't use elm's filter, no ftp, no telnet, etc), and gopher failed to connect to soda to let me look. When I borrowed a friend's shell account for a few moments to try the ftp, soda shut down when I told it I was anonymous. So, is soda still the archive (have I missed a major announcement?)? Is there a later version of pgptools? Has someone else fixed the MS-DOS support? (I finally just yanked the multiple platform support from my copy, figuring that if my code compiles here with MS-DOS support forced but I haven't changed the library code itself then my code SHOULD compile on a machine where the multiple platform support is functional)? Is there a fix to fifo I need to make or track down? Has soda locked out anonymous ftp permanently? (I also use the White Wolf archives there.) Is there an approved of pool or newsgroup to send messages to Pr0duct Cypher? I hate to add to the cypherpunks traffic with comments directly to him/her. (We NEED to get the return addresses working, or Pr0duct should try the new anonymous address server (from Ghio? I should know, I saw the name 50 times today!)!) Seth Morris (Seth.Morris(a)launchpad.unc.edu)

2 1

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

Gun conversion info banne
by Duncan Frissell 17 Dec '03

17 Dec '03

To: CYPHERPUNKS(a)toad.com S.> Duncan Frissell <frissell(a)panix.com> writes: S.>Then there's the time in the early '80s when the Consumer Products S.>Safety S.>Commission banned the "Button Book." S.> S.>Query: S.> What pray is the "Button Book". S.> Readers may recall that many years ago, their parents gave them this book that had, attached to its pages, all sorts of fastening devices. The Button Book had cardboard pages with shoelaces, zippers, buttons, buckles and all sorts of great stuff. Good training for fastening things. The CPSC felt that the buttons were too easy to remove. The old "oh no your book is dangerous it may kill my (stupid) kid." The publisher didn't try a 1st Amendment defense. I don't know if they've ever reissued. DCF Who survived to adulthood before the CPSC (as difficult as that may be to believe). --- WinQwk 2.0b#1165

1 0

Mac encryption
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

What is everyones opinion of the best encryption software forthe Mac? Frederic Halper fhalper(a)pilot.njin.net

2 1

ADMIN: cypherpunks-ratings created
by hughes＠ah.com 17 Dec '03

17 Dec '03

While we were creating majordomo groups, I had Hugh create a new mailing list for our use, cypherpunks-ratings. The ratings list is meant for the implementation of distributed moderation similar to what I outlined for Usenet a week or two ago. This experiment is slightly different, since we're going to leave the main list as it is. The ratings list currently doesn't go anywhere. You can join the ratings list, but that doesn't get you anything. We'll turn on distribution of the list later. Here's the deal. The ratings posted to the ratings list have to be some fixed standard form. This form has yet to be decided upon, and should be debated on this list. I will implement a filter which only passes syntactically correct ratings, once the syntax is decided upon. At this point we'll turn on the list. Other motivated cypherpunks participants will have to come up with a system to merge the two lists into a coherent whole, as well as provide an interface for creating and sending ratings. Ratings are intended to be broader than voting. Ratings should be manifold, in order to support various areas of interest. Ratings can support voting, but not vice versa. Please use the RATINGS: tag in the subject line for discussion. Eric

1 0

Unbridled Enthusiasm
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

* Reply to msg originally in CYPHERPUNKS Uu> At last, my long-promised pseudo-account remailer is open for testing. Uu> Here's how it works. We know you're excited, but did you have to post this THIRTY-TWO times? Just wondering...

2 1

RATINGS: Subject tags
by Hal 17 Dec '03

17 Dec '03

One issue is the purpose of the ratings system. I don't think it will help to solve the problem of intentional disruption. If the disrupter is really motivated, he could have multiple identities and give positive ratings to his messages, so they would get through. I think a good purpose would be filtering out uninteresting or lower-quality messages. Unless someone else vouches for a message, it would not appear for a subscriber to the filtered list. Eric asked that discussions on this topic use the "subject tag" concept, putting "RATINGS:" in the subject line. Subject tags are a good idea but are not widely used. If more people would use them it would help people to read those messages that interest them. My suggestion is that the ratings be based on subject tags. A rater reads a message, and if he endorses it as being worth reading he sends in one or more subject tags (keywords) which apply. Then someone on the filtered list could subscribe based on particular tags that interest them. The advantage is that this way even newcomers' messages are tagged with useful keywords, tags provided by old-timers on the list when they approve the messages. This also provides for the multi-dimensional aspect of approval, more useful than a simple "thumbs up". I won't try to suggest a syntax, but under this proposal a rating message would include some message identifier (perhaps the list should produce messages with an incrementing message number), along with a list of applicable subject tags. Hal

3 3