December 2003 - cypherpunks-legacy

Re: Index for ftp site csn.org:/mpj/
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> A bigger problem is that PEM uses DES rather than IDEA. I just learned > of a new attack by Mitsuru Matsui of Mitsubishi that requires 2^43 > *known* plaintexts, not chosen ones. The note I received says that it > ``breaks the scheme in 50 days on 12 HP9735 workstations''. This was > presented last week at the Japanese Conference on Cryptography and > Information Security. RIPEM supports two key triple DES. Mark

1 0

Re: MacPGP BAD on soda.be
by Duncan Frissell 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com W >> Re: encrypted valium W >Just wait until Chemical CAD/CAM becomes available - shipping valium W >will be protected by the First Amendment, the data police will be W >competing with the drug police to confiscate your computers, W >and LD wibe ranting that drug dealers are using crypto remailers W >for both payments and product delivery :-) Likewise, the BATF. "Who's that knocking on my door?" "The Dowager Dutchess of Dykedom's Daring Destructors?" "But my stout door will only last a few minutes and I have no weaponry." "Oh, woe is me." "But wait, I just got my new 3D molecular deposition printer and the varlets have yet to block my wireless net link. What is the address of that hot new weapons haven. Quick, download the DDF's for that new full auto flechette cloud Block Leveler (plus DDF's for the ammo belt)." Copy the gun DDF out the printer port, wait that looong 30 seconds, grab the freshly printed device, copy the ammo belt ddf out the printer port (after clicking the icon for continuous printing), grab the end of the belt as it starts to come out of the printer. Get the kids, dogs, goats, and chickens into the circle around the printer, when the door gives way, start a circle sweep taking out the house, the garden, and all vertebrate life out to the visible horizon." ******* Just kidding. No problem running off a couple dozen Ruger Mini 14s though. Though cypherpunks is not the place to argue RTKBA issues, it *is* the place to discuss issues like the effect of crypto, and reduced costs of information, on society. Since some of the things that people will choose to trade over the nets will be porno, drug files, and weapons files (they are already doing so), and since desktop molecular synthesis units and molecular deposition "printers" are inside our event horizon, they can be discussed here. DCF Who (despite evidence to the contrary) doesn't have a psychological need for automatic weapons merely a tactical one (just like Salman Rushdie). --- WinQwk 2.0b#1165

1 0

Re: 2-way anonymous via SASE
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Jon Boone <boone(a)psc.edu> writes > Isn't it true that no matter how many remailers you use, the full spec > of the return path has to be included? And if the last remailer is > keeping a log of all messages passed, then the reciever/replier need > only interrogate the last remailer to find out the sender's address? No, the last remailer only needs to know how to send mail to the preceeding remailer. Depending on how fancy a remailer system you're using, and whether the recipient or remailer operator can be trusted, there are different amounts of work you need to do to get what you want. If you're creating 1-shot reply tokens, they can be set to send to an address at the n-1th remailer, which anonymizes and adds the address for the n-2th remailer, etc. This gives you reasonable security as long as at least one remailer can be trusted and isn't coercible. Don't know if anybody's implemented remailers supporting this yet; Julf's anon.penet.fi remailer gives a more persistent return address. BTW, an alternative to arranging digipayment to every remailer in the chain, which is complex, slow, and introduces opportunities for leakage, might be to create a "Remailer Postage Cooperative"; postage gets sent to the first remailer only, and the remailers use some sort of settlements process to divide up the payments, the way phone companies or post offices do. Postage might vary by number of hops you're paying for or whatever (e.g. a 3-hop stamp), and settlements might be per-message or might just be apportioned by the difference in amount of traffic flowing in each direction. This works better with a stable system of remailers, but even if the remailers aren't all cooperating, it at least lets you reduce the number of postage-stamp messages to the number of cooperatives your message uses instead of the number of remailers, and reduces setup considerably. > Jon Boone | PSC Networking | boone(a)psc.edu | (412) 268-6959 > finger boone(a)psc.edu for PGP public key block Finger can be faked - including your Key ID or fingerprint in your .signature file lets people be more sure it hasn't. e.g. > finger boone(a)psc.edu for PGP public key block ID #123456 # Bill Stewart AT&T Global Information Systems, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

2 1

Re: Index for ftp site csn.org:/mpj/
by Derek Atkins 17 Dec '03

17 Dec '03

> I can't speak for RIPEM, but that's not accurate for PEM. You can have > as long a chain of signatures as you want up to the certifying authority. > That may not be as general as you'd like, but it's better than just a > single authority. I think we have a lack of communication here. What I said is completely true about PEM, as well as RIPEM. You cannot have more than one signature on your certificate. I did not mention signature chains in my message at all, only signatures. For example, in PEM, you have the root key sign some certificate, and that certificate signs another, and so on down the chain to a user certificate. However, in PEM I cannot sign your certificate! *THAT* is what I'm talking about. PEM certificates can have one, and *ONLY* one, signature on them. I'm not saying that I think the PEM CA model is bad -- there are good points to it. I just feel it is too restrictive. I like being able to have anyone sign anybody's key in PGP, and building certification in that manner. The fact that in PEM you have a lot of hoops to jump through in order to become a CA will, IMHO, be its downfall. Right now anyone can become a PGP Certification Authority. -derek

1 0

Clipper Petition
by Dave Banisar 17 Dec '03

17 Dec '03

Clipper Petition Electronic Petition to Oppose Clipper Please Distribute Widely On January 24, many of the nation's leading experts in cryptography and computer security wrote President Clinton and asked him to withdraw the Clipper proposal. The public response to the letter has been extremely favorable, including coverage in the New York Times and numerous computer and security trade magazines. Many people have expressed interest in adding their names to the letter. In response to these requests, CPSR is organizing an Internet petition drive to oppose the Clipper proposal. We will deliver the signed petition to the White House, complete with the names of all the people who oppose Clipper. To sign on to the letter, send a message to: Clipper.petition(a)cpsr.org with the message "I oppose Clipper" (no quotes) You will receive a return message confirming your vote. Please distribute this announcement so that others may also express their opposition to the Clipper proposal. CPSR is a membership-based public interest organization. For membership information, please email cpsr(a)cpsr.org. For more information about Clipper, please consult the CPSR Internet Library - FTP/WAIS/Gopher CPSR.ORG /cpsr/privacy/crypto/clipper ===================================================================== The President The White House Washington, DC 20500 Dear Mr. President: We are writing to you regarding the "Clipper" escrowed encryption proposal now under consideration by the White House. We wish to express our concern about this plan and similar technical standards that may be proposed for the nation's communications infrastructure. The current proposal was developed in secret by federal agencies primarily concerned about electronic surveillance, not privacy protection. Critical aspects of the plan remain classified and thus beyond public review. The private sector and the public have expressed nearly unanimous opposition to Clipper. In the formal request for comments conducted by the Department of Commerce last year, less than a handful of respondents supported the plan. Several hundred opposed it. If the plan goes forward, commercial firms that hope to develop new products will face extensive government obstacles. Cryptographers who wish to develop new privacy enhancing technologies will be discouraged. Citizens who anticipate that the progress of technology will enhance personal privacy will find their expectations unfulfilled. Some have proposed that Clipper be adopted on a voluntary basis and suggest that other technical approaches will remain viable. The government, however, exerts enormous influence in the marketplace, and the likelihood that competing standards would survive is small. Few in the user community believe that the proposal would be truly voluntary. The Clipper proposal should not be adopted. We believe that if this proposal and the associated standards go forward, even on a voluntary basis, privacy protection will be diminished, innovation will be slowed, government accountability will be lessened, and the openness necessary to ensure the successful development of the nation's communications infrastructure will be threatened. We respectfully ask the White House to withdraw the Clipper proposal.

1 0

Re: 2-way anonymous via SASE
by Hal 17 Dec '03

17 Dec '03

From: "Jon 'Iain' Boone" <boone(a)psc.edu> > So, you use a chain of anonymous-id's to set up your return-path? Unfortunately, return-paths are not exactly the strong point of the current cypherpunks remailers :-). That is what much of the discussion in this thread has discussed: how to best allow for convenient but secure return paths. > What if you have a remailer that only assigns you an id for that message > so that your id is equivalent to (say) the Message-ID (or some portion > thereof)? How do you return-path without specifying? Your syntax is a bit hard to follow here, but I'm guessing that you are proposing such a remailer as a way of providing for return paths. The remailer would remember the message-id's of outgoing messages, and would remember where those messages came from. Then if a reply came back for one of those message-id's it could send it to that remembered address. There were some proposals along these lines made last year, or maybe back in 1992. This scheme doesn't seem to generalize well to multi-remailer paths. Also, I think people would be nervous about having remailers keep this kind of out-to-in mapping information. > Jon Boone | PSC Networking | boone(a)psc.edu | (412) 268-6959 > finger boone(a)psc.edu for PGP public key block #B75699 It is interesting that it is theoretically easy to make a fake PGP key which matches someone else's "displayed keyID", the low-order 24 bits of the RSA modulus. If someone did this they could make a fake PGP key for you with ID B75699, then fake finger and they would be able to substitute their own key for yours. Rather than displaying your key ID it would be better to display your key fingerprint, visible with "pgp -kvc", although it is 128 bits rather than 24 bits so may be a bit cumbersome for a signature. Here is how you make a key which matches a given low-order 24 bits. Pick a random prime p. Take the low order 24 bits of p and divide into the given 24-bit "displayed keyID", mod 2^24, to get qx. Now you simply need to find a prime q whose low order 24 bits are qx. This can be done by picking a random q = qx + rand()<<24 (e.g. a random number whose low-order 24 bits are qx), and repeat q += 1<<24 testing each q for randomness. This can even be sieved for a very fast test similar to what PGP does. It would be an interesting exercise to write such a routine. I understand there is already at least one 24-bit collision on the public key servers, not unexpected given a few thousand keys. Hal

3 2

Matsui-san Attack
by buckley＠wti.com 17 Dec '03

17 Dec '03

]> A bigger problem is that PEM uses DES rather than IDEA. I just learned ]> of a new attack by Mitsuru Matsui of Mitsubishi that requires 2^43 ]> *known* plaintexts, not chosen ones. The note I received says that it ]> ``breaks the scheme in 50 days on 12 HP9735 workstations''. This was ]> presented last week at the Japanese Conference on Cryptography and ]> Information Security. 50 days on 12 HP9735 = 600 days on a single HP9735 The 735 has a pretty fast Mflop rating (compared to Sun, IBM, SGI, PC, and Macs). Using a comparable breaker on the average machine, it is going to take two years to "break the scheme". That leaves two years to create stronger/tighter strategies.

3 2

Re: 2-way anonymous via SASE
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Jon Boone writes > Isn't it true that no matter how many remailers you use, the full spec > of the return path has to be included? And if the last remailer is > keeping a log of all messages passed, then the reciever/replier need > only interrogate the last remailer to find out the sender's address? At no time do any of the remailers see a "full spec of the return path", especially the last remailer in the chain of remailers used for the reply message. You might view the SASE as a "full spec of the return path", however, only the receiver of the original message sees the full SASE, and the SASE is mostly a bunch of encrypted information nested in layers that only become readable as the SASE gets "unwrapped" in its trip back to the original sender. Each remailer involved in the return trip sees only the layer of the SASE that becomes readable when it decrypts the portion of the SASE it received from the previous hop. By the time reply gets to the last remailer (inner most layer of the SASE), the reply contains no information about any of the outer layers of the SASE. All it contain is: (Bob, D, (stuffN))Rx, (((reply)A)B)C (A, B, and C, indicates keys used to re-encrypt the reply. They are not addresses of previous hops.) If Bob was really unlucky, it is possible he could build an SASE using only remailers that are under the control of Ted. If this happend, then Ted would be able to trace back to Bob. However, "Bob" could be an anonymous Penet-style account and Ted would still not have learned who "Bob" really is. Jim_Miller(a)suite.com

1 0

Linear Cryptanalysis of DES - New Developments by Matsui
by schneier＠chinet.com 17 Dec '03

17 Dec '03

On Jan. 27, at the Japanese Conference on Cryptography and Information Security, Mitsuru Matsui of Mitsubish presented a known plaintext attack on the full 16-round DES. It requires 2^43 plaintext-ciphertext pairs, and breaks the scheme in 50 days on 12 HP9735 workstations. I have absolutely no more information at this point. I will post again when I know something else. Bruce

1 0

An interesting tidbit in Information Week Magazine
by Chris Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hi Everyone... Just noticed a little 6 liner on page 10 of the Jan 10 edition of Information Week Magazine: Quoted from said magazine... The government's information superhighway team is finally coming together. Commerce Secretary Ron Brown last week named the National Information Infrastructure Advisory Council. Members include Craig Fields, chairman of MCC; Mitch Kapor, chairman of the *Electronic_Frontier_Foundation* and co-creator of Lotus 1-2-3; nathan Myhrvold, senior VP for advanced technology at Microsoft; Bert Roberts, chairman of MCI; and John Sculley, former chairman of Apple. End of Quoted text - Emphasis on EFF MINE! I wasn't around in the beginning of January and didn't notice if you guys had a discussion about this. If so - sorry, otherwise - interesting isn't it? Keep up the great work everyone! Chris -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU28RdQ8XnNL4/CHAQEUfwQAlptuqMdmQzCb1MofpIEqjaddJEgvnaz2 V6Qm1RQZry+tMgXlbKyABMhut5T2rc6TexQOIG2pywmgH/V9ru2UQLF+mGhqFKR5 bOn6jPfanFSWxBOMU0Hzc0GPU3Gxf69UsOAKSqwdkR+DTjcziAVdnEjt3CFaO0OR DxCCG2TFOAM= =yjp7 -----END PGP SIGNATURE-----

1 0