December 2003 - cypherpunks-legacy

RSA weak link II
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Thanks to the folks who answered my first question about the relative strengths of RSA and IDEA. Okay, 1024-bit RSA keys are easier to brute-force than 128-bit IDEA keys. Currently. We think. That's what I should have stressed in the first place. Aren't people more sure of what they think about the toughness of RSA, than they are of what they think about IDEA? (Less important question: how many RSA keys are there, as a function of size? I'm getting ln(2^(number of bits))^2, which can't be right.) -fnerd quote me - - cryptocosmology- sufficiently advanced communication is indistinguishable from noise - god is in the least significant bits -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0

Re: Remailers: The Next Generation
by jim＠bilbo 17 Dec '03

17 Dec '03

> (This is a simplistic equation, which does not take into > account the practical limitations of there being only so > many total messages flowing in the system, a point > addressed briefly below. If only 10 messages "enter the > system" and 10 messages "leave the system," the attacker > has an easier problem than than a D = 3125, for example, > might otherwise suggest.) > Since the remailer system works better (harder to track messages) as message traffic increases, then perhaps the remailers should circulate bogus messages around the mix in order to sustain a minimum level of traffic. As more real messages enter the system, the remailers would decrease the number of bogus messages they issue. How would a remailer tell the difference between a real message and a bogus message from another remailer? It wouldn't, but that's ok. All a given remailer cares about is the number of messages coming in versus the number messages that constitute a "good" level of traffic. If a remailer isn't seeing enough traffic, it would issue some bogus messages that would pass through a random set of remailers and eventually come back to itself. If all remailers did this, then I think the system, as a whole, would always have enough messages flowing though it. Real messages would not have to be delayed to defeat traffic analysis, they could be tossed into the mix as soon as they arrived at a remailer. Jim_Miller(a)suite.com

2 1

Announcing WWW access to keyserver at martigny.ai.mit.edu
by Brian A. LaMacchia 17 Dec '03

17 Dec '03

Announcing a new way to access public keyservers... The public keyserver running on martigny.ai.mit.edu may now be accessed via a World Wide Web client with forms support (such as Mosaic). In your favorite WWW client, open the following URL to start: http://martigny.ai.mit.edu/~bal/pks-toplev.html Access to keys on the server is immediate. You can also submit new keys and/or signatures in ASCII-armored format to the server. New keys are processed every 10 minutes (along with server requests that arrive by e-mail). The martigny.ai.mit.edu keyserver currently syncs directly with these other keyservers: pgp-public-keys(a)demon.co.uk pgp-public-keys(a)pgp.ox.ac.uk pgp-public-keys(a)ext221.sra.co.jp pgp-public-keys(a)kub.nl NOTE! This service is experimental, and has limited options at present. I expect to be making changes to the server over the next few weeks to make it more useful. I would appreciate any bug reports, comments or suggestions you might have. --Brian LaMacchia bal(a)martigny.ai.mit.edu public-key-server-request(a)martigny.ai.mit.edu

1 0

Remailers outside US/Canada
by Mike Ingle 17 Dec '03

17 Dec '03

Are there any cypherpunks remailers outside the US and Canada? Having a message cross multiple political boundaries makes it much harder to trace. A remailer with a return receipt would be nice too. This is a multiply encrypted message back to you, which could be attached to your outgoing message. When your message reached the last remailer in the chain, that remailer would send the receipt back to you through a different route. This would eliminate the need to ping a remailer before using it. Pinging a remailer can leave a trail back to you. With the current remailers, you can change the subject as the message propagates, by putting Subject: blah blah after the request-remailing-to line. Is there any way to send a message to multiple recipients at the end of the line? Multiple request-remailing lines don't seem to work, nor to requests separated by commas. --- MikeIngle(a)delphi.com Secure Drive. Because It's Nobody's Business But Yours!

1 0

Sorry about that...
by Mike Ingle 17 Dec '03

17 Dec '03

Remailer test message, I mean. Thanks to a wonderful mail program called D-Lite. Among other bugs, such as losing mail and a bad editor...

1 0

RE: Remailers: The Next Generation
by Hal 17 Dec '03

17 Dec '03

Tim has made some excellent points regarding the remailers. A couple of quick comments: I don't know if charging for messages can be made to work. Karl has a remailer which requires digital tokens. You can get them for free just by sending an email message. But I'll bet almost no one uses them. Why should they, when there are free ones? That is the big problem. The free ones undercut the pay-per-use remailers. Unless the pay remailers offer significantly more features and advantages to the users, they won't be used. Especially if we are talking about actually mailing physical cash to the remailer operators in order to receive tokens, this will be terribly inconvenient and will further raise the threshold barrier against for-pay remailers. So, the question is whether the value can be made large enough. Most of Tim's comments are focussed on the security of the remailers. For some applications this is important, particularly the more world- shaking ideas we have discussed. (And despite the skepticism I expressed last week about the degree to which cryptography can change the world, I do believe it can be a strong force for positive change.) If people are fighting for freedom against a powerful adversary, they will need the kind of security Tim is talking about. But how much remailer use falls into that category? Not much, right now. I frankly don't see improved security as a major problem that needs to be addressed in the short term. It's worth mentioning that despite the charges of hypocrisy in the Detweiler affair (we are supposedly violating our own principles of freedom and privacy) no one has proposed trying to violate remailer confidentiality to produce proof that Detweiler is behind the Squish posts. Even with our current network Detweiler has managed to achieve considerable privacy. The fundamental purpose of the remailer network is to defeat traffic analysis. We want to protect the privacy of WHO you communicate with as well as WHAT you say. I agree with most of what Tim says, but I feel that the biggest problems are with ease of use and social issues rather than security at the present time. In my opinion, what the remailer network needs is, first, standardization, as Tim has proposed. Secondly, it needs reliability and robustness. Third, it needs to be easier to do two-way messaging. Related to this, we need software that can take a message from a remailer and display it as coming from the sender, either as nym or truename. (Karl has a script which does this for elm or mh, I forget which.) Fourth, we need to find solutions to the political and social problems the remailers cause. Tim's idea of a global blocked-address database is a good start here. My picture of remailer use is a little different from what a lot of people may be thinking of. Just as we envision a world in which everyone uses good, strong encryption to protect the privacy of their electronic messages, I would like to see privacy protection with regard to patterns of communication. Who you communicate with tells a lot about you, in some ways as much as what you say does. In my ideal future, remailers and similar technologies are as ubiquitous as encryption, providing real protection of privacy. Hal

1 0

Applied Cryptography, $35.71 (fwd)
by css＠netcom.com 17 Dec '03

17 Dec '03

Forwarded message:

1 0

cc: FBI (fwd)
by css＠netcom.com 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: Remailers: The Next Generation
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cypherpunks, I tried to send this out earlier, but I haven't seen it at my site. I've been having problems with messages either not getting out or not being delivered back to me, so I don't know if this made it out to you. If not, here it is. If so, I'm sorry for the duplication. --Tim Forwarded message: From: tcmay (Timothy C. May) Message-Id: <199401220929.BAA27006(a)mail.netcom.com> Subject: Re: Remailers: The Next Generation To: cypherpunks(a)toad.com Date: Sat, 22 Jan 1994 01:29:19 -0800 (PST) Cc: tcmay (Timothy C. May) Hal Finney has added many useful points: > I don't know if charging for messages can be made to work. Karl has a > remailer which requires digital tokens. You can get them for free just > by sending an email message. But I'll bet almost no one uses them. > Why should they, when there are free ones? > > That is the big problem. The free ones undercut the pay-per-use Good point. My hunch is that "nothing is free" and the usual evolution will be followed: initially free-but-poorly-supported capabilities, followed by some flavor of commercial services which are in competition with the "free" services, and then a widening gap in quality/robustness between the free and fee services. For example, my own Netcom service costs $17.50 a month and competes with local free or nearly free BBS services that offer some form of Internet access. The advantages of Netcom are sufficient to make it worth paying for. Another example, in a different situation, is the explosive increase in bookstores in the last 20 years, even when libraries offer books for free. People _will_ pay for convenience, features, robustness, etc. It may be a marketing struggle, but eventually fee-based services seem to win out over free-but-flaky systems. > remailers. Unless the pay remailers offer significantly more features > and advantages to the users, they won't be used. Especially if we are > talking about actually mailing physical cash to the remailer operators > in order to receive tokens, this will be terribly inconvenient and will > further raise the threshold barrier against for-pay remailers. I agree this is a speed bump. In fact, most folks are making very little use of existing features (chained hops, encryption) and overall volume seems pretty low. Part of my reason for proposing a formal "second generation" is that enough new features, and greater ease of use (standards, scripts, automatic selection of routings, ratings services) may tip the balance toward wider use. Also, the loss of penet-type servers with a centralized point of attack (e.g., Julf's machine) may suddenly and urgently shift the burden onto Chaumian-style distributed systems. (Just a hunch I have.) > So, the question is whether the value can be made large enough. Most > of Tim's comments are focussed on the security of the remailers. For > some applications this is important, particularly the more world- > shaking ideas we have discussed. (And despite the skepticism I > expressed last week about the degree to which cryptography can change > the world, I do believe it can be a strong force for positive change.) > If people are fighting for freedom against a powerful adversary, they > will need the kind of security Tim is talking about. Yes, I confess that my slant on things is toward the "ideal mix," that extremely strong system of distributed mixes that will provide the underpinning for the untraceable system we all want (for the reasons of protecting privacy in a surveillance society that Hal mentioned) and for the more radical stuff that some of us want. Working toward the ideal digital mix seems to be the right thing to do, as a strong foundation will make so many other things easier. Making the systems easier to use is of course also important, and several of my points were oriented toward this. But I agree my focus is on making the next generation more bullet-proof. (As an aside, more people will be willing to run turn-key remailers if they are convinced the remailer functions are sufficiently robust to head off charges that they knew what was flowing through their remailers, that the system won't barf and dump a bunch of messages into the trash or into their machine logs, and that the software will run without their involvement. Such robustness will allow and encourage the spread of cheap remailer boxes. Price competition on remailer rates will make the burden of paying drop. This is the hope, at least.) > now. I frankly don't see improved security as a major problem that > needs to be addressed in the short term. It's worth mentioning that Perhaps Hal is right, perhaps not. But regardless of the exact priorities, agreeing on some standards, some scripting conventions, and encouraging a "pinging service" (like what Karl Barrus does with his periodic summary, but with more statistics on delays, packet sizes, etc.) seem like some things we need to do. Thinking of several of these as aspects of the next plateau, the "second generation," may help to focus energies on adding features. > In my opinion, what the remailer network needs is, first, > standardization, as Tim has proposed. Secondly, it needs reliability > and robustness. Third, it needs to be easier to do two-way messaging. I agree with all of this. I did not address two-way mail, using either the "onions" (a kind of return-rely envelope) proposed by Eric Messick and Hugh Daniel about a year ago, or the "pools" described by Miron Cuperman. (Readers may recall that the "BlackNet" experiment I ran called for respondents to encrypt their replies, with no mention of their names or addresses, to the public key of BlackNet and then post the cyphertext to one of several groups...thus was 2-way anonymous communication created.) One project that could be interesting is this: a merger or hybrid of the distributed, hard-to-kill Cypherpunks remailers and the wildly successful, centralized, easier-to-kill penet system of Julf. That is, multiple penet-type sites, using mixes between. Or meshed in other ways. The idea is to make sure that greater security against legal and governmental action is built-in. (I realize Julf's system keeps a mapping between real IDs and pseudonyms, and this centralized mapping is the point of attack. Still, some decentralization, some scattering across multiple national borders, would be useful. Perhaps something involving secret-sharing protocols.) Oh, and I agree with the comments a couple of people made that running constant traffic between remailers is a good way to ensure message latency does not result in excessive delays. We've actually talked about this before, but nothing has been done on this. One of the problems (also a strength) is that our various remailers are all run by different people, on different machines, etc. They are not like Western Union telegraph offices, with coordinated policies. Setting up regular communications, robust connections, is thus not as easy as it might be with uniform remailers. (A speculative solution: a group of remailer sites can agree to form a kind of "guild," agreeing to work together to keep uptimes high, use standardized software, etc. All voluntary. Like franchises of McDonalds. The participating remailers could agree to run traffic at certain rates between their machines, work together to ensure adequate robustness, issue a report on all of their machines, etc. Remailers that don't want to participate can still be used, but would likely have poorer interaction with other machines and might eventually lose business.) --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. -- .......................................................................... 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.

2 1

List software with PGP authentication/administration
by Sameer 17 Dec '03

17 Dec '03

I have recently written some mailing list software which authenticates PGP signatures (it is *way* too centralized for my tastes, but most of my "market"-- the people who are using the list that the software is running on-- have rather lame computers or lack the time/skill to install PGP for signature verification locally.). The most important part of the software, however, is that it uses PGP-signatures for remote administration. It requires that a remote administration request be PGP-signed before it accepts the administration commands. It is running a *rudimentary* keyserver service.. It accepts new keys, but it doesn't release keys on demand. (I'm going to have it release keys to subscribers only, soon.) Here's the documentation. If anyone would like to take a look at it, and play with it, etc., please mail me. It's not very clean code. (It's a combination of some perl and sh scripts. I'm pretty clueless about perl, so there are many inefficiencies. I plan on fixing them once I learn perl better.) -- PGP Signature Authentication The list software does automatic verification of PGP signatures, and prepends a few lines to every message that goes out-- whether or not the signature is good, bad, or nonexistant. -- Administration If you are the administrator of the list, you can issue list-administration commands within a PGP-signed message. To do so, begin your message with the line: ::administrate <password> Following lines are commands to the list software. Supported commands currently are: "subscribe address" -- subscribe address to the list "unsubscribe address" -- unsubscribe address from the list "sendlist address" -- send the list of subscribers to the address -- User Commands There are a few commands which any user can use, whether or not the message has been PGP-signed. To send out a subscriber list to someone who is subscribed to the list, anyone can send a message to the list saying: ::sendlist following by the addresses to which he or she wants the subscriber list to reach. Only people who are subscribed to the list, however, can get the subscriber list through this command. (Anyone can issue this command, however.) To add a key to the PGP-database so that messages signed with this key are recognized, anyone can send a message to the list saying: ::addkey following by an ASCII-armored PGP public key block. Anyone can post anonymously to the list as well. In order to do that, the message should be sent to the list (signed or unsigned-- if the message is signed, however, the signature information still reaches the list) with the line: ::administrate anonymous As the first line.

1 0