December 2003 - cypherpunks-legacy

Re: Broadcasts - Bandwidth Problem ?
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Jonathan Rochkind writes: > Many people seemed to think that a newsgroup for this sort of a thing was a > waste of bandwith. I don't really agree, and think that the bandwith is > neccesary for a distributed method of making the remailer net more robust > to remailers popping into and out of existence. In case the bandwidth on {alt.anonymous, alt.anonymous.messages} started to bother news admins, we could actively encourage them to put the groups on very short expiration periods, i.e. articles might expire after only a day. Assuming people are using automated sniffers to collect their anonymous mail, this shouldn't present any obstacle to the use of the groups as message pools. Keeping the ciphertext around in public for a shorter time sounds like a Good Thing (tm), anyway. I agree that bandwidth seems essential to foiling traffic analysis. - - -L. Futplex McCarthy; PGP key by finger or server "We've got computers, we're tapping phone lines; I know that that ain't allowed" --Talking Heads - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLuwe/Wf7YYibNzjpAQFK4AP/YFtRJMd0emeRJgZf4QaL4qPvMFKNn3Uv MYFhJ8GR2M4x1q/ZAwhJsP3NuIeRk5UAWc1Ti1OYKjDkNvoQ52DK3uOW6aCqxYp0 3REpK53F0PkuVL9EnfGImrUWAyeUr2oZOzp1O67hD0eCYhM4IdcdDudA/97Xh0R+ zRIhgC6/Gfo= =n6qM - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuwgPSoZzwIn1bdtAQFFgAF+LXvBnjZEZxsMx9MU+fGX9ynuAnrqKs6S EFbgsBG8aFvul2skOsgIBrVW5luJm4c7 =iPbm -----END PGP SIGNATURE-----

3 3

Time to exhaustively break 40-bit RC4?
by raph＠netcom.com 17 Dec '03

17 Dec '03

The SSL documents say that exhaustively searching 40 bits of RC4 keyspace takes 64 MIPS-years. When I brought this figure up at the cpunks meeting, it was roundly derided. However, I think it might be a sound estimate. The key schedule operation in RC4 does 256 "swap" operations. Let's say it takes four instructions to do each swap. So, it's 2000 instructions per key. A one-MIPS processor can search 500 keys a second. There are about 30 million seconds in a year, so that's 15 billion keys a year. 40 bits is a trillion keys, so it works out to 66 years, which is well within the Pentium-style accuracy of the calculations I've done. Am I missing something here? On the second floor of Soda Hall are about 100 HP Snake workstatations. I think they're about 100 MIPS each. During the winter break, they will be sitting mostly unused. If the math checks out, they should be able to search keyspace in two and a half days. Anyone wanna do some cracking? Raph

6 9

Re: extra dashes in PGP-related blocks?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 5:03 PM 12/12/94, Andrew Brown wrote: >but is a remailer (or pgp) smart enough to take the output from checking >a signature and run pgp over it again? is it going to know to take something >and pass it through pgp until pgp can't do anything with it any more? i think >that's the problem that jrochkin was addressing. he has a pgp encrypted >message and then signs it and then wants to mail it to a remailer so that the >remailer can decrypt the message but it won't ecause the encryption is >nested... > >wasn't that it? Well, no, not really. My problem was that a user would send me their public key, inside of a signed message, and the "BEGIN PUBLIC KEY" stuff would have the "- " on it. Which means that before I can add it to my keyring, I've got to edit out the extra "- "s, and then save it in a file, and then pass it through PGP, instead of just passing the original message though PGP, or using the Mac "copy" command on a part of the message and sending that through PGP. Or someone sends me an encrypted address block inside a signed message, and I've got to do the same before I can use it. I now understand why PGP does what it does, but it's still a pain. Perhaps the ideal mail reading program would run my incoming mail through PGP before I even saw it, so I wouldn't have this problem. Well, actually not. My ideal mail reader would check the signatures before I saw them, but would also leave them intact on the message, so I could re-check them myself manually if I wanted. Oh well. It's not a limitation on functionality of any kind, just on convenience.

1 0

Remailer and gateway list
by skaplin＠skypoint.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Can someone please provide me with a list of all of the current remailers and mail -> usenet gateways? Thanks, Sam ============================================================================== The release of atomic energy has not created a new problem. It has merely made more urgent the necessity of solving an existing one. - Albert Einstein ============================================================================== skaplin(a)skypoint.com | "...vidi vici veni" - Overheard | outside a Roman brothel. PGP encrypted mail is accepted and | preferred. | Change is the only constant in the | Universe..."Four quarters, please." E-mail key(a)four11.com for PGP Key or | Finger skaplin(a)mirage.skypoint.com | Smile!! Big brother is watching. ============================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: This message digitally signed to verify the identity of the sender iQEVAwUBLuzfI8lnXxBRSgfNAQEH8wf8CON8wTlCcJPalXWfXMUC4efhG319fISX 8DdRWu7hRJWIbxWQ3kUmqVSk6oGHQv9OuiRR1xJH0x+dcKmdfb7CzJkZ50eX92vI HBCdSE4xfBGWKr/CtLVP3ag8OOcd2dMsZRjG0p0y2oV54fYD70KkUXW6mg1L5xUC eZMpWmi3ZgFZC3xSZREa7nv8TnPkpZBgT7mojFNpwn7vPY29L5Zbb78USSmfR0E0 oNY0JyePxiuMXT4XDHV8XrA/f7fTNtXgGJTZAtHE8ZaU6R10NQBx2AKUnh362X0L RqxHPbgC1Q9ooTkAPPw/4qleceM2j2ZjKbzb5DozCshUdEB88fcNsQ== =z2QT -----END PGP SIGNATURE-----

1 0

Re: Real-time surveillance of the police
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Don Doumakes wrote: ... why on earth would the police, who will not consent to civilian review, ever go along with something orders of magnitude more extreme? (1) There are civilian review boards; the consent of the police is not a prerequisite. If they don't like it, they can get a real job. (2) It is in their best interests to be protected from false accusations, and to be able to be quickly located under emergency conditions. ObCrypto/Privacy: I suspect there would be an immense amount of radio traffic involved in keeping track of a substantial group of people ... [I doubt] the ability of the receivers to digest it all in real time. (1) My suggestion was for (probably local) recording, not real time monitoring of video; therefore, no bandwidth problems. (2) Tim might want to comment, but my understanding of the localizer technology is that it too is somewhat "local" and that polling or burst transmission keeps the bandwidth requirements at manageable levels. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Re: alt.anonymous.messages propagation
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- (Replied to this once privately, but since mail continues to come in I'll repeat here) In article <9412122127.AA17019(a)hodge-podge.MIT.EDU>, Derek Atkins <warlord(a)MIT.EDU> wrote: >> Nope, no alt.anonymous. 'Leastaways, not off the servers that the turist >> accounts use. And since I configured news on the machine, I'd love to >> hear if there are MIT servers that have a larger set than life.ai's. > >I just looked on news.mit.edu and bloom-beacon.mit.edu (the MIT >news-transport machine), and I found both alt.anonymous and >alt.anonymous.messages, so I don't think saying "MIT doesn't get >alt.anonymous" is at all correct. > >It may be correct to say that "GNU.AI.MIT.EDU doesn't get >alt.anonymous", but GNU is _NOT_ MIT! Yup, that's why I qualified my statement. Can't check on servers I don't know about, after all. FTR, it's not GNU that I'm on/help maintain. It's bronze. So, life.ai.mit.edu is a deficient newsserver and I'll switch the default on bronze to news.mit.edu after appropriate consultations. - -- Todd Masco | It's difficult to be loud about keeping your enumerated cactus(a)hks.net | rights when you're busy exercising your unenumerated ones. cactus(a)bb.com | http://www.hks.net/~cactus/cactus.html - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuz6VCoZzwIn1bdtAQG1/wF7BAGUuLjGM1JVjpYxP1e6eUYNRSUPrvbX /alvpNH0g8mVFKaSPf8EH1nEeiV4K4Pf =MsKC -----END PGP SIGNATURE-----

1 0

Anonymous Repository
by Tony.Gurnick＠nzdairy.co.nz 17 Dec '03

17 Dec '03

To solve anonymous replys heres a little scenario. Alice wants something from bob (crypto?) but dosent want bob to know (or any others (NSA?)) to know. 1) Alice sends a request to bob via and anon-remailer chain. 2) In the request she specifiys that bob is to put a special code in the message and send it to anon-repostiory(a)nowhere.com 3) Bob sends the info + the special code, for whatever reason. (Payment recieved?) 4) Alice sends a message to anon-repostiory(a)nowhere.com saying to copy bobs message (using special code) to a new secret special code (here code represents a file name) - This message could/should be encrypted and the repository should delete it after the copy is made. 5) At some indetermined time in the future alice ftp`s or sends a mail message to anon-repostiory(a)nowhere.com and retrives bobs message. This should defeat traffic analysis but will do nothing if the repository is compromised! But the same goes for anon-remailers. There are huge blanks in this, so does anyone want to comment? T

1 0

A Golden Opportunity
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cypherpunks, It seems to me that we have a golden opportunity to apply our crypto know-how, and our special perspective, to truly important issues. In recent days we have seen on our own list commments from folks from Netscape--surely a major players in whatever's coming--and from attendees at the recent IETF meeting (that stuff is Acronym City to me, so I stay out of the debate). And contributions from Phil Zimmermann, Bruce Schneier, Steven Levy, and the like. "Can't we all just get along?" is a much-laughed-at slogan, but it seems to apply here. We have a golden opportunity to influence the Net of the future, surely a good thing. (And I haven't even mentioned the Cypherpunks connections to digital cash of various flavors.) I understand that this list is no substitute for things like the recently-occurring IETF conference (or whatever it was), but it seems unproductive to be arguing here. (Argument can be good, of course. Amanda Walker _started_ the argument, but the resulting debate has been illuminating, so I think the outcome of the argument has been generally good.) I suppose what I'm suggesting is that we treat the confluence of influntial people here as a good opportunity to debate the future. We probably can't debate fine points in great detail--the list just can't support the passing of detailed specs back and forth--but I think many of us are willing to put up with some acronyms in exchange for you putting up with our non-IETF comments (:-}). The future Net is now being architected. What better time for Cypherpunks to apply their various views? --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay

2 1

[cpunks] Re: public accounts / PGP / passphrases
by tim werner 17 Dec '03

17 Dec '03

>Date: Mon, 5 Dec 1994 05:24:12 -0500 >From: "L. McCarthy" <lmccarth(a)ducie.cs.umass.edu> >...The only solution I can imagine is to keep >a notebook computer running Linux at work, and dial in to the DECstation >five feet away from my desk at work. I've no idea how to convince the tech >staff here to add a dedicated phone line to my lab for this purpose. Any >better suggestions on using PGP safely during the workday ? Well, for one thing you don't need a phone line in your scenario. You can probably just connect the serial port of your laptop to one of the decstation serial ports, using a null-modem cable (pins 2 and 3 swapped; 4 jumpered to 5; 6, 8, and 20 jumpered to each other; and 7 passed through, or something like that) But I agree that the idea of buying a laptop so you can use PGP at work is odious. There must be a better way. tw

2 1

Re: Clarification of my remarks about Netscape
by Amanda Walker 17 Dec '03

17 Dec '03

[I'm sending this to the list because it does have some crypto content] "Kipp E.B. Hickman" <kipp(a)warp.mcom.com> writes: > > There is no need to bypass existing efforts just to add cosmetic value to > > your own software. > This has nothing to do with security... Agreed. My annoyance with Netscape is not based solely, or even primarily, on security concerns. In fact, my only annoyance with your security proposal is that it is at the wrong layer (or, more accurately, at layer which should be secondary). In my view, you picked the right technology, but applied it to the wrong problem :). > Clearly I'm an idiot. Explain it to me. SSL is a mechanism whereby a client and a server can establish a secure, authenticated transport channel. The problem is that this isn't what I want to secure and authenticate. Most of the time, in fact, I don't care about the transport: I may be talking through a proxy (like the current CERN httpd), or bringing things in from a cache, or talking to a load-balanced server array. I want the *documents* I'm accessing to be secure and/or authenticated. I want my HTML documents signed and certified by the *author*, not the server. I couldn't care less about the server if I can verify that I've got the right document in response to my query. Similarly, if I send the contents of a form containing, say, my Amex number, I want to encrypt the session key with the public key of the merchant, not the service provider. This is what I (and many others) mean by an "end to end security model." Transport security is a nice secondary ability (it helps defend against traffic analysis, for example, and casual snooping by students with packet sniffers), but without end-to-end security, it's simply a way of providing a false sense of security. I wouldn't want to do away with the TCP checksum field simply because the modem I use for my SLIP link is "error-correcting," and I feel the same way about security. > I put my email address in there for that very reason. Jeesh. I'd rather that technical feedback occur in a public forum like the IETF. I have no pretensions about being a security expert, and I want people to shoot down my bad ideas too. Heck, I *like* having my competitors tell me what's wrong with my ideas :). > > This serves as a direct barrier to competition from other commercial > > vendors. > This is an outright lie. We don't use TIPEM. You could build a > conformant SSL implementation using RSAREF and the freeware IDEA > cipher code. Nope, not if I want to sell it (note the word "commercial" in my comment). RSAREF cannot be used for commercial software, nor can IDEA under the PGP license. There is no feasible way to license the RSA patents for commercial use except by licensing TIPEM. I have been told this outright by Kurt Stammberger of RSADSI (their VP of marketing, I believe). This is not secondhand information. All commercial software that I know of using RSA public key encryption and RSA stream ciphers (such as RC2 and RC4) uses TIPEM and BSAFE, including Lotus Notes and Apple PowerTalk. RSA's royalty structure is based on a percentage of revenue, with the percentage on a sliding scale based on gross corporate revenue (not just on products which use RSA's patents). If you keep your margins low to compete in the marketplace, you lose. Even you folks are making your money on high-margin products (servers) rather than low-margin ones (clients), I'd wager at least in part because it's a way to make money despite having to pay RSA royalties. The RSAREF license has been loosened up some recently, but it's still restricted to freeware. > As for a barrier to competition. So what else is new? We > all have barriers to overcome before we can compete. Should we get rid of > TCP/IP as a barrier to using the web? I don't have to pay royalties to sell an implementation of TCP/IP. Your analogy fails. > You are somewhat right here. In fact, this was done because we are a company > interested in surviving long enough to withstand the eventual attack > by microsoft. You've already got your eggs in the right basket on this one--sell servers and services, not client software. Microsoft has a miserable track record in the server arena (witness the underwhelming success of Windows NT :)). It's also less of a commodity market, which is where Microsoft excels (no pun intended). > As a result we received critical review > from some decent members of the crypto community, including: > > Martin Abadi > Mike Burrows > Alan Schiffman > Matt Robshaw > Burt Kaliski Mostly RSADSI people, by my count. Great technical background, but I wouldn't call relying on one of your technology vendors "peer review"... > As for the IETF standards process, we are pushing the > document into the RFC process. Precisely. Rather than working with others in the industry and research communities, you are trying to push your proposal into the standards track. > The market will decide one way or the other. On this I agree completely. Amanda Walker

4 3