December 2003 - cypherpunks-legacy

Re: Leaving the Country
by tim werner 17 Dec '03

17 Dec '03

>Date: Sun, 17 Jul 1994 18:27:52 -0400 >From: "Perry E. Metzger" <perry(a)imsi.com> > >Goldwater was a friend of his to the end. Recently, some Republicans >have been shocked to discover that Goldwater supports equal treatment >under the law (although not "affirmative action" or other similar >crud) for Homosexuals and other similar unattractive groups, and that >he holds other evil "liberal" views. Some conservatives have gone so >far as to denounce him for "slipping". They never have understood what >his views have been all along, either. > >However, might I point out that none of this has anything to do with >cryptography? That may be true, but does it have to do with punks? tw

1 0

Re: Encrypting fax machine
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 6:07 AM 7/18/94, John Young wrote: >[. . .] >We use an encryption algorithm called seeded pseudo-random >number generator, Mr. Varga said. The company chose that >algorithm because it is in the public domain, he added. *Groan* One would think that anybody who would go to the expense of designing an encrypting FAX machine could at least afford to read the introduction to any beginning crypto book. Heck, I bet it's even the generator on page 46 of K&R's second edition C book. b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

2 1

article: DES strength against attacks
by baum＠apple.com 17 Dec '03

17 Dec '03

"The Data Encryption Standard (DES)and its strength against attacks" by D. Coppersmith in IBM J. or R&D, v38#3, May 1994 pp243-250 ..in this paper, we examine one such attempt [to break DES], the method of differential cryptanalysis.... we show some of the safeguards against differential cryptanalysis that were built into the system from the beginning. Disclaimer: The present author participated in the design and test of DES, particularly in the design of the S-boxes and in strengthening them against differential cryptonalysis. Naturally , this author has strong opinions about DES and its history. Any opinions in this paper are those of the author and are not necessarily shared by IBM ************************************************** * Allen J. Baum tel. (408)974-3385 * * Apple Computer, MS/305-3B * * 1 Infinite Loop * * Cupertino, CA 95014 baum(a)apple.com * **************************************************

1 0

Re: article: DES strength against attacks
by smb＠research.att.com 17 Dec '03

17 Dec '03

"The Data Encryption Standard (DES)and its strength against attacks" by D. Coppersmith in IBM J. or R&D, v38#3, May 1994 pp243-250 ..in this paper, we examine one such attempt [to break DES], the method of differential cryptanalysis.... we show some of the safeguards against differential cryptanalysis that were built into the system from the beginning. Disclaimer: The present author participated in the design and test of DES, particularly in the design of the S-boxes and in strengthening them against differential cryptonalysis. Naturally , this author has strong opinions about DES and its history. Any opinions in this paper are those of the author and are not necessarily shared by IBM Let me strongly recommed this paper. It shows, quite graphically, just how tightly coupled some parts of DES are. You don't make up a good cipher by random bit-twiddling! (By contrast, I heard a presentation last week on the cryptanalysis of another cipher. It wasn't that strong a cipher -- 2^18 ciphertexts, 2^27 operations to crack it -- but it would have been far weaker had it not been for chance. The cipher had a right shift operation; originally, it was left unspecified if an arithmetic or logical right shift should be used. When different C compilers started producing different results, the inventor arbitrarily decided to standardize on arithmetic right shifts. It turns out that the other choice was far weaker -- but he didn't know that.)

1 0

Re: PROTOCOLS: Re: Hashed Hash
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 10:54 PM 7/17/94, wcs(a)anchor.ho.att.com (bill.stewart(a)pleasantonca.ncr.com +1-510 wrote: >> I'm planning on implementing the "cryptographic protection of databases" >> on page 61 of Schneier, to create a directory of a professional >> organization that would be useless to telemarketers. >> [hash last name to get DES key and location of encrypted data in list.] Not quite; the last name would at least be the foundation of the key--otherwise, just use the first field to decrypt the second. Location is either 132 or 160 bytes from the start of the hash; all else is obscurity that wouldn't be all that effective. Remeber, anybody can do individual lookups, or else I'd just use some secure method to get it into people's hands. If you can do individual lookups, you can do a lot (all) of them; the best I can hope for is to slow that down, preferably in a cryptographically secure way. >> [ problems of brute-force and popular-last-names attacks ] > >If you're only concerned about telemarketers, this amount of obscurity >may be enough - anybody competent enough to hash a list of, say, >10000 last names x 1000 first names into your database is at >least an *interesting* telemarketer :-) All it takes is some ambitious employee with connections to somebody with a medium-sized workstation with a fair amount of idle time, like overnight. A cheapie Alpha would do very nicely. Let it work--at no cost other than initial setup and electricity--for a month or three, and you've got an awful lot of names, even if you don't have the whole database. There's not much obscurity here. Just write a minimal wrapper to the existing (supplied) decryption code, unless my "security" relies on non-cryptographic stalling, like counting to a million before doing anything. I sure don't want to rely on that. And a company such as Microsoft wouldn't even notice the effort. Think about it: a database of musicians (the group I'm doing this for is the Phi Mu Alpha Sinfonia, the men's professional fraternity in music) known to be technically inclined--after all, their database is cryptographically protected. Who better to target for their musical instrument CD? >If you're concerned about telemarkers from the NSA/FBI/KGB, >then the algorithm isn't enough anyway [. . .] If any TLA wants the unencrypted database, they can have it from me for the price of a warrant--and that's just to be sure that they're not imposters. Our membership rolls are alerady public. >An intermediate variant is to use a password as part of the hash; >if everybody has their own password, the table size is N**2, or you can >give everyone the same password without increasing the table size, >and still be able to distribute the list on FTP. >[. . .] Nice idea. If there is demand for a program such as this after I've written the basic version for Sinfonia, I'll code that, as well. >On the question of whether there are functions I(m) = H(H(m)) for popular >hashes, by definition there are, since H(H(m)) is one. Well, by that definition, DES is a group.... >For most of >the cryptographically useful functions, though, there aren't any that >are faster than running the hash function twice. Some exceptions are >hashes like a**x mod p, x**a mod p, and obviously (a*x+c) mod p. >But DES is known not to be a group, and MD5 is ugly enough it probably >isn't group-like either. Any chance you (or anybody else) can point me in the direction of sources that would state this definitively? I'd much rather do multiple hashes than use some sort of kludge with multiple DES encryptions, but I won't unless I can find something in the literature. "A job worth doing...." > Bill Thanks for your help. b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

1 0

GUT and P=NP
by kkirksey＠world.std.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I was reading Hawking's _Black Holes & Baby Universes_ and an interesting question struck me: If a Grand Unified Theory exists, would it not prove P=NP to be true? My Armchair Cosmologist's (TM) reasoning goes something like this: If a GUT exists, and that GUT is proven to be true (making it the Grand Unified Law, I suppose), any behaviour we believe to be non-deterministic really isn't: it obeys the GUL. So P=NP must be true, since NP is an artifact our pre-GUL way of looking at things. Am I way off base here? Can anyone with more knowledge in this area than I tell me if I'm right, wrong, or somewhere in between? Many thanks, Ken ============================================================================= Ken Kirksey kkirksey(a)world.std.com Mac Guru & Developer - ----------------------------------------------------------------------------- Harassment is a power issue, and power is neither male nor female. Whoever is behind the desk has the opportunity to abuse power, and women will take advantage as often as men. - Michael Crichton (in _Disclosure_) -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLisd3+sZNYlu+zuBAQFIewP+Pailgh2SFHki+eakhVU9wRCX4kvTXGt/ A2cL/GdIAWkMTPDwOIjzG6MusXcyNUTnTIiAp+Ctzti2xa8F2hsyXU5yd8RQh6aE ukmmKGvzYBocmiPV2ekl5aSlubV8+0BG4bLDDY5IKOwy1P+oXhY9539YumXuVq+D xKp/7PdRBcU= =Gx6j -----END PGP SIGNATURE-----

6 7

Re: Why triple encryption instead of split+encrypt?
by John Douceur 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: <solman(a)MIT.EDU> >Date: Monday, July 18, 1994 4:18PM >Clearly, if you have access to P0, P1; C0 and C1 this attack crushes the >algorithm. In most books I've seen, it is assumed that you do not have >access to this. The assumptions about the information available to the cryptanalyst vary with the type of attack. The essence of a known-plaintext attack is that both plaintext and cyphertext of several messages are known, and the task is to deduce the key. This is more practical than it may sound, since there may be (for example) header information that has small or no variability among messages. >Nonetheless, your cryptanalytic algorithm makes clear an additional >constraints that must be placed on the system which I had not realized: >From the algorithm, the plaintext, and the cypher text, in must not be >possible to reconstruct both the plaintext, and the cyphertext for either >half of the message. >To that end I would suggest the improvement of making the splitting >operation dependent on the keys. For that matter, one could have a third key which is used by the splitting algorithm. If one chooses to make this splitting key a function of the two DES keys, then this approach reduces to your suggestion, at the expense of a smaller keyspace. It could be said that, in the code fragment of my previous message, the splitting key is fixed at 0x55555555. So now the meet-in-the-middle attack regains its earlier applicability: A known-plaintext attack would encrypt P with the splitter, decrypt C0 with DES, and attempt to meet in the middle to discover key K0; similarly, decrypting with C1 to get K1. If you can design a splitter that is as cryptographically secure as DES (good luck), then the resulting algorithm is as secure as double DES. Actually, the computational complexity of a cryptanalysis would be somewhere between one and two times that of double DES, since it requires one encryption analysis and two decryption analyses. In your previous message, you commented: >I have a hunch that if I'm wrong, its because the time required to do secure >non-redundant secret splitting is as large as the time I'm saving. If your secret-splitting algorithm is as secure as DES, then it probably runs as slowly as DES does, making your hunch correct. However, even if this were not the case, the security of this scheme is significantly less than that of triple DES. JD -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLisjcEGHwsdH+oN9AQHwDgQAualDZ4kcq15Cs/oIufau4f23x11gVmEY nAkWt7teczUa+ZUHIRrsY1x3D6FDgzQLdBeajMpz3W8XHzO9HjAykbx3Rg8eTeQf ZjGtysnNhSqJwtQLypGhZV+kSv8n4UY5lYkhGHVhTbnn/2ynyjKmqZMkmoN66Klt GcbayT4Jhzw= =qfay -----END PGP SIGNATURE-----

2 1

JUST GO AWAY Sue D nym!
by kelly＠netcom.com 17 Dec '03

17 Dec '03

Hey detweiler... I am not as gentle as perry is... just go away... you DONT have any votes here... p.s. I WIll be notifying netcom management again of your activities...

1 0

Big Brother comes to Campus
by Robert A. Hayden 17 Dec '03

17 Dec '03

I wanted to forward this to everyone to show ya what the school is trying to spring on us over the summer when nobody is around. --------------------------- Acting for: XXXXX XXXXX Mankato State's new ID card is fast becoming a reality. We are calling the new ID the MavCard and have begun taking pictures of the summer orientation students. Attached is a brief summary of the features of the MavCard we have given to parents and students who were here for orientation. Soon we will be taking pictures of other students, faculty and staff. I will inform you of the time and location. If you have any questions or concerns about Mankato State's MavCard, please let me know. Mankato State University MavCard As part of our mission to improve campus services, Mankato State University is introducing the new MavCard, a more efficient identification card (ID) that can also act like cash to pay for many on-campus services. The MavCard is more efficient because it will become the only ID card you need for access to university facilities, services and events including the Memorial Library, athletic and student activities. The MavCard will also eliminate the hassle of carrying cash. It can be used like cash for library charges, vending machine products, photocopying, laundry services and more! Mankato State University's goal is to provide one convenient card that does it all! It all begins with your new MavCard for the 1994-95 academic year. Where to Get Your MavCard The Office of Business Affairs will start processing MavCards during Freshman Orientation, the first two weeks of Fall Quarter, and until the entire campus community has been issued new ID cards. Hours and convenient processing locations will be posted at the Office of Business Affairs, Administration Building. It's Quick and Easy Getting a MavCard is quick and easy. A new photo imaging process will use a video camera and computer to create and store all of your card information in seconds. Your picture, along with all other card information, will be directly transferred to one durable plastic card (the same size as a credit card). One process, one card does it all! The First Phase Beginning Fall Quarter 1994, you will be able to use your MavCard in the Memorial Library, food and vending machines, laundry machines, photocopying services, the University Bookstore and Residence Hall meal plans. How the MavCard Works The MavCard will carry three primary information identifiers, along with your name and picture. The first identifier is your library and Residence Hall meal plan Barcode on the front of the card. The second identifier is a small black magnetic Cash Stripe on the back of the card. This Cash Stripe will retain information on the amount of funds you apply to the card through one of the many CASH-TO-CARD or $10, or $20 on your Cash Stripe, you will activate your the card through one of the many CASH-TO-CARD or ACCOUNT-TO-CARD machines on campus. By placing $1, $5, $10, or $20 on your Cash Stripe, you will activate your new MavCard. For safety purposes, there will be a $20 limit on the funds that can be placed on the Cash Stripe at any time. Once your Cash Stripe is activated, you can use your MavCard like cash to pay for campus services such as photocopying, vending and laundry. The third identifier is a large magnetic Bank Stripe on the back of the card, similar to the bank stripe on a credit card. The Bank Stripe is like an electronic check! Once money is deposited to your MavCard account, the card can be used instead of a check to purchase goods and services. The amount of the purchase is deducted directly from your on-line bank account so there is no possibility of overdrawing your account. This Bank Stripe is also used to obtain cash from the automatic teller machines which will be available on campus. A Personal Identification Number (PIN) is used with this stripe so that your account is protected in the event the card is lost or stolen. The Bank Stripe will save you time, reduce the need to carry cash, and help eliminate the hassle of writing checks. Calling Card Option The MavCard can be used as a personal long distance calling card. Information on this feature will be available from MCI during Welcome Week. Future Phases In the future the MavCard will expand to include building access, voting, campus food services and direct deposit of financial aid, refunds and student payroll. Questions & Answers Will I have to get a MavCard or can I just use my old ID? Your old ID will still be valid when classes start in the Fall of 1994 and until all students can get their new ID. The process to get your new MavCard is quick and easy. What will the benefits of using the MavCard really be to non-campus residents? The MavCard will do much more than just consolidate your ID with meal plan information. Even if you do not those offered through the library, vending machines, your ID with meal plan information. Even if you do not use a meal plan on campus, other services including those offered through the library, vending machines, photocopiers, food services...will be easier to use than ever before. What if I lose my MavCard? Contact the Office of Business Affairs at XXX-XXXX. Since your information, including your photo, is stored in the computer, replacement cards can be processed immediately. Who do I contact with any questions about the MavCard? The Office of Business Affairs at XXX-XXXX, with any questions or suggestions on how to make the MavCard work... and save...for you! ===================================================== Basically, they can now track you whenover you enter a building, get financial aid, or even purchase a soda or make a photocopy. I feel used. -- ____ Robert A. Hayden <=> hayden(a)vorlon.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> I do not necessarily speak for the \/ Finger for PGP Public Key <=> City of Mankato or anyone else, dammit -=-=-=-=-=-=-=- (GEEK CODE 2.1) GJ/CM d- H-- s-:++>s-:+ g+ p? au+ a- w++ v* C++(++++) UL++++$ P+>++ L++$ 3- E---- N+++ K+++ W M+ V-- -po+(---)>$ Y++ t+ 5+++ j R+++$ G- tv+ b+ D+ B--- e+>++(*) u** h* f r-->+++ !n y++**

1 0

Re: Detweiler
by Matthew Ghio 17 Dec '03

17 Dec '03

|ghio said that Detweiller must have forged that Big Collision message |sent to his remailer, because the person it was attributed to hadn't |logged in. I wonder if "rsh" shows up in that type of login?? maybe |he "rsh"ed to the account to send from there?!?! and didn't log in |to have a cover story?? The messages appear to be being forged via port 25. He's sent several dozen of them, and they all have different from addresses. |btw, I haven't seen anything from Detweiller at tmp(a)netcom.com. I assume |he still has the account?!?! maybe if someone calls netcom and complains |they will do something?? Well, I complained... Haven't heard anything from them yet tho. |i'm glad ghio caught that message in his mailbox through careful screening |so that it wouldn't go out to the newsgroups. I always thought the |remailers were automated, but I guess in most case the operators are |screening all the stuff. this is good, because we don't need any more |Detweiller junk out there (amazing how peaceful things are without him!!!) |too bad if the message was forged, because it would be LOTS of fun to |EXPOSE THE BASTARD!!! (insert evil smirk here) No. The remailer is automated. I don't normally screen messages before they are sent out or otherwise censor them. The message he sent went out to the newsgroups. After I saw the anonymous messages appearing, I started having the remailer save copies of all messages. He seems to have an automated process set up to spew these things out. I have now temporarily disabled my remailer until this crud stops. |BTW, here is something I was wondering. on the Detweiller message he has |an "errors-to: /dev/null" field. what does that do? why did he put that |in there, anyway? i've never seen any documentation reference it. do |the remailers handle it? It doesn't do anything that I'm aware of. My remailer does support "Request-Remailing-To: null" which will just delete the message. The more recent messages just have a blank Errors-To: header. I keep getting messages from him every few minutes. blah...

1 0