December 2003 - cypherpunks-legacy

Re: Restrictions on crypto exports
by Mike Godwin 17 Dec '03

17 Dec '03

Bill Stewart writes: "Mike - you write that an FTP archive is a library open to the public. While it looks like one to me, the important thing is convincing a grand jury or jury that it's true, or heading off a prosecutor who'll try to paint ftp archives as 'subversive hacker BBSs' or nonsense like that." I don't think we disagree here. "Do you know if anyone's doing this in an organized fashion?" No. I'm really just making a prediction of what the likely outcome of such cases will be. --Mike

1 0

Re: a quote
by Peter Wayner 17 Dec '03

17 Dec '03

Nah. When I'm drunk and driving I always use the left side of the road. If I was in Britain, there would be no problem!

1 0

MISC: thought for the dat
by Brian D Williams 17 Dec '03

17 Dec '03

thought for the day; In Starfleet, all communications are encrypted automatically. Although there is no honor in knowledge gained through stolen transmissions, some of our enemies have no honor. A true Klingon does not "sneak"-he shouts into the face of his enemy. But I have seen many types of dishonor, and so I am prepared for it. -Lieutenant Worf,chief of security, U.S.S.Enterprise From the star trek next generation book "20th century computers and how they worked" by Jennifer Flynn published by alpha books. ISBN 1-56761-257-1 Brian Williams Cypherpatriot

1 0

money money money...
by Jim McCoy 17 Dec '03

17 Dec '03

I have been tossing some of the electronic money ideas around in my head, and the two things that seemed to be the hardest problems were how to keep the feds from stomping on such a bank and how to give its currency value. Here are a couple of thoughts on these problems: Legalities: Why does it need to be a bank? Actually, it seems to me that the first step is to actually create the "currency" for use as a means of exchange and let the net provide the banking structure. Once currency exists cryptography will allow for the banking structure to be created in whatever manner the market demands. The hard part seems to be the jump-starting necessary to create the currency and get the system going. So why not approach this as a currency problem and not as a banking problem. In other words, how much easier is it to set up a "currency exchange and check cashing" operation compared to a bank or credit union? All the digital currency exchange would need to take in the money from users, and pay out digital coins in cash. Once such an operation existed the formation of a digital economy would be possible by just migrating existing services to work with the system. Such an operation could support itself by charging a small transaction fee (e.g. $0.25 for deposits and $0.25 for withdrawls plus the postage for sending the check...) Products and Value: I have only glanced over the papers available, but the IMP archive stuff (internet mercantile protocols) might just provide the immediate market for us to piggy-back upon. The imp people seem to be oriented towards using PEM for monetary transactions, but it seems to me that it would be possible to subvert such a system for our own use by simply setting up a server similar to an anonymous remailer that allows one to deposit electronic currency from the previously mentioned currency exchange and then creates a imp system PEM message coming from the remailer. The remailer can ask as a sort of purchasing agent, converting the digital coins created by the currency exchange into whatever type of imp certificates the user wants and it uses the purchasing agents identity to provide the anonymity that the imp schemes seem to not care about... So, what say you fellow cypherpunks? jim p.s. Anyone coming to the crypto conference in Austin Wednesday? If so and you want a copy of my most recent draft of a "Musings on a Crypto-Secure Linux" let me know and I will bring a few printed copies...

1 0

Re: MISC: thought for the dat
by smb＠research.att.com 17 Dec '03

17 Dec '03

thought for the day; In Starfleet, all communications are encrypted automatically. Although there is no honor in knowledge gained through stolen transmissions, some of our enemies have no honor. A true Klingon does not "sneak"-he shouts into the face of his enemy. But I have seen many types of dishonor, and so I am prepared for it. -Lieutenant Worf,chief of security, U.S.S.Enterprise From the star trek next generation book "20th century computers and how they worked" by Jennifer Flynn published by alpha books. ISBN 1-56761-257-1 Hardly a new sentiment. From Kahn: ``Gentlemen do not read each other's mail''. Henry Stimson, Secretary of State, 1929, shutting down the American Black Chamber. In 1940, Stimson was Secretary of War, and a recipient of MAGIC....

2 1

Need to Declare Policies on Remailer Record-Keeping
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

(I hope this is not considered "off-topic" by anyone.) It would be nice if the operators of the current remailers made clear their archiving/record-keeping policies on remailer traffic. An "ideal mix" is like an "ideal op amp": very hard to build in practice, but very useful as a concept. David Chaum's 1981 paper anticipated many of the issues some of us later discovered, and which are dwell upon at length on this list. Some brief descriptions of the "ideal mix" (remailer): 1. Records. No records kept of incoming or outgoing traffic (in Chaum's mix, done by tamper-resistant hardware implementing software that keeps no records; in DC-Net approach, no single entity knows traffic, so only collusion can reveal traffic). Score: Many remailers keep records/logs, either explicitly ("to help in debugging") or by default (Unix records, system requirements, etc.) I have been shocked on a couple of occasions--a useful, educational shock--to get e-mail messages from the operators of remailers, saying things like "I couldn't help noticing your comments--I agree with you that...." Now partly this was my problem, in that I was not using PGP to chain my transmissions (in which case no snooping remailer operator will be able to get my true name except by colluding or traffic analyis), but it also indicated that some remailers are not taking a sufficiently hands-off policy...more on this point later. 2. Encryption, obviously, to hide mapping between ingoing and outgoing traffic. Score: Pretty good (no pun intended), though use of encryption is reported to be low. PGP has helped immensely. 3. Latency: some number N of messagers needs to be stored (securely, unobservably, as in #1) and then sent out in an order that obscures order of arrival. (Lex order, for example.) Score: Someone has been trying to implement this, but it is not widespread. (People want fast response, and in a low overall message volume environment, this could be impossible. If N = 100, could be a very long wait.) 4. Padding of message lengths in such a way that messages cannot be tracked by message length. Score: I don't think this is being implemented. We've talked about "quantizing" to several standard message lengths ("short," "medium," and "long," uncreatively enough) for this reason. 5. Other issues can be found in Chaum's papers, in the attacks on DC-Nets (one of which I distributed with the 70 pages of printed material handed out at the first Cypherpunks meeting), and in the many messages on remailers here on this list. Hal Finney's analysis, for example. In light of the recent subpoena, I urge that #1, record-keeping, be addressed quickly. If the authorities are seeking sources of crypto material, or routes used in conveying such material, they may conceivably issue subpoenas for site records. Some suggestions, which protect the remailer operators and the users: a. Keep no records, use scripts to delete records that may be generated that you have control over. b. The "best" remailers will be on systems under the control of the remailer operator himself (there seem to be a few of these), as he can control archiving and logs. c. Remailer operators should announce their policies on logs, announcing their philosophy (e.g., "to protect myself, I keep copies of all traffic through my remailer," or, "I keep no records whatsover--once it's through my system, all traces are deleted."). d. Trust in what they remailer operators say is another big issue...if the FBI operated a remailer, would you trust what they say? One avenue for helping here is to have independent agents reporting on their experiences, and perhaps confronting the remailers with evidence (such as the "helpful messages" I 've sometimes gotten) of their actual policies. e. Increased use of encryption. Lots more here. For now, just getting the remailers to publically state their policies will be helpful. To us, in allowing better market choice in which remailers we use, and to them by making their lack of record-keeping (for example) a matter of public record. Let's plan ahead for the day when Cypherpunks traffic, and remailer records, get subpoenaed. That _could_ be the next test case. I don't think I'm being paranoid. In any case, there are some fairly easy _social_ changes to the remailer system that we can make that will improve the security against traffic analysis and subpoenas. -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^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it.

2 1

nonrandom string
by cjl＠micro.med.cornell.edu 17 Dec '03

17 Dec '03

I address this to the list at large hoping that one or more of you can explain something unusual that I observed. A friend of mine and I have been using PGP for several months and I just recently noted that in at least three of the recent posts to me that the first 18 characters of the encrypted message were identical. The first words of the plaintexts were not identical and so I assume that these characters are something else, perhaps the stuffer that I have heard mention of on this list. This repeating string is of concern for obvious reasons (e.g. so much for anonymity), and I would like to understand the cause of its recurrence. Please post to me and I will post a precis of the most reasonable suggestions. cjl

1 0

Re: meaningless rumor
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Matt writes: > [Steve writes:] > >they may throw in charges of importing IDEA, though I doubt that they'd > >indict just on those grounds; in an era of key escrow, they'd certainly > >like a court to rule they had the power to exclude subversive foreign > >crypto.... > > Assuming that whoevever implemented PGP did not himself import the cipher, but > based the implementation on the EUROCRYPT '90 paper that was 'imported' > by Springer-Verlag, I don't understand what the basis would be for such a > charge. Now an indictment against Springer for shipping the proceedings > (which contained C source code for IDEA) into the US - that would be > interesting... If memory serves me correctly, Phil's original PGP offered DES and bass-o-matic, and the IDEA encryption was implemented in the Europeans PGP2.0 version (though I don't know if it was done by Phil or by Europeans, I think the latter.) This means that the IDEA implementation was imported by person or persons unknown, presumably including Phil and many others. During one round of Sternlight Wars, I proposed doing a U.S. implementation, but John Gilmore convinced me that importing software is legal under the then-existing ITAR wording. This could be an opportunity to test it in court. Bill

1 0

REMAIL: policy
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim asks about remailer policy: here is mine. About logging: I think there are two kinds of logs remailers can keep. By default, the "archive.remail" and "archive.pgp" (and "archive.ripem") files are kept, which record messages as they pass through. Also, there is debugging logging, which records stuff like the return value of pipes, user environment variables, whether pasting tokens and message delimiters are found, etc. Further, Hal showed how the maildelivery file can be extended to log usage only - an entry appended to a file for every use (see the cypherpunks gopher site :-) in "Anonymous Mail" for how to do this). I don't keep debugging logging or archive logging - I unlink the archive.* files every time slocal is invoked. Actually, I don't keep usage logs either. However, I haven't had a chance to drop in a sendmail agent, so there is always the syslog file I can't control. Hm.. I suppose I could just remove the relevant lines from the maildelivery file and avoid the archive.* files completely. I will do that. Errors (malformed messages) are dropped in the elee7h5@rosebud and elee6ue@rosebud remailers, and get forwarded to me (klbarrus(a)owlnet.rice.edu) from the elee9sf(a)menudo.uh.edu remailer. This is so mail intended for me but sent to my old address still gets here. Furthermore, the elee7h5@rosebud remailer is locked - I can't log in anymore. But, the directory structure is preserved, the remailer still works last time I tried, and I mailed to the admin asking him to contact me about this about two weeks ago, and haven't heard back. Encryption: elee7h5@rosebud, elee6ue@rosebud, elee9sf@menudo support PGP encryption. Also elee9sf@menudo supports RIPEM. Caching: elee9sf@menudo caches messages, remailing in a random order at midnight. More precisely, it caches them in random order and mails out every midnight. So if you wrap your PGP encrypted message inside a RIPEM encryption, it will stay until midnight the first day to unwrap the RIPEM, and then will stay till midnight the next day to unwrap PGP to get the remailing request. Message padding: I'm experimenting with this, but not in production mode just yet. It's easy enough to pad so the messages waiting to be remaild are the same size, but I want to extend this so what leaves via sendmail or it's replacement is also the same size. Ownership: well, these are all school accounts so I don't have final authority over the machines. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJ47zYOA7OpLWtYzAQECcgP/ZuQ/zT5hJx3yIITTmq7RGLX5s4FUoHN0 cf0LXhNKZGIbINeI6wGxn1edCFrwrm9DujuAQpf0J+9yVgENlvU9VB2Z5BhorRQW zoFKMrEW6mwPHYR/ga7l0FKqG2WVLSo4DE37Tba6VnFY5vOEnt+KCkDaQXyNcOIc EbYcehaYafE= =irE+ -----END PGP SIGNATURE-----

1 0

Is the following digicash protocol possible?
by jamesd＠netcom.com 17 Dec '03

17 Dec '03

A question about offline digicash: Is it possible to arrange digicash as follows: If A, the original issuer, issues a unit of digicash to to B, and B gives it to C, and C gives it to D, and D, gives it to E, and E cashes it with A, -- and everyone colludes except C and D, it is impossible to prove that C got this unit from D. If A, the original issuer, issus a unit of digicash to to B, and B gives it to C, and C gives it to D, and D, gives it to E, and E cashes it with A, -- and C double spends it to D', who then gives it to E' who then attempts to cash it with A, -- then A will detect the double spending and rebuff the attempt, E' will complain to D', and D', with information supplied by E' and A, can then prove that C dishonorably double spent the money, without discovering that C gave the money to D, and hence without discovering that D gave the money to E. -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd(a)netcom.com

3 2