December 2003 - cypherpunks-legacy

Re: Members of Parliament Problem
by Hal Finney 17 Dec '03

17 Dec '03

From: paul(a)fatmans.demon.co.uk > You could also have an arbitrated blind signature protocol whereby > trent shares a keypair with all users. bob encrypts his comment, M > with the key he shares with trent. On recieving it trent carries out > a blind signature on it and publishes it, as trent knows only bob has > the shared key, K he knows bob said M but as it is a blind sigature > and he is likely to be signing a lot of messages (trent is of course > a computer program) he doesn`t know which message came from bob. I don't quite follow how this would work. If Trent issues a blind signature, then that means (doesn't it?) that he doesn't see what he is signing. So how can he confirm that the message is actually from a member of the group when he doesn't see it? > Also Chaums group signatures could be used but unfortunately the > arbitrator can find out who said what, but does not normally know. > Also trent can forge digital signatures with this protocol. > Chaum further mentions protocols for this sort of thing that do not > even need an arbitrator but I don`t have the papers on this. Not all of Chaum's proposals in the original paper from Eurocrypt 91 have this property. Here is what he has, somewhat simplified. Z is the trusted party for those protocols which use one. 1) Each group member makes up a key which he will use for one signature. Z signs each key to certify that it is a member of the group. People don't re-use keys so that messages are unlinkable. Z can tell who sent which message since he knows the keys. 2) Z publishes an RSA modulus N, gives each group member a secret exponent si, and publishes v = the product of all the si. Members sign message m by producing m**si mod N. Then to confirm the signature they engage in a zero knowledge protocol to prove that the signature is of the proper form and that si divides v (without revealing si). Chaum gives a protocol for this. 3) Z again publishes an RSA modulus N, and each group member chooses his own RSA modulus Ni = pi * qi. To sign message m he produces m**pi mod N. He then proves in zero knowledge that the signature is of the proper form and that pi divides the product of all the Ni (without revealing pi). This is the same zero knowledge protocol as in (2) above. 4) Members agree on a large public prime p with generator g. Each member chooses a secret exponent si with public key ki = g**si mod p. (This is a standard discrete log cryptosystem setup.) To sign message m he produces m**si mod p. He must then prove in zero knowledge that the signature is of the proper form and that si is the private exponent corresponding to the public key of some group member, without revealing exactly which group member it is for. The protocol for this is not very efficient. It uses a cut and choose concept and has to be iterated multiple times. In methods 1, 2, and 3, Z can tell who made a signature. In method 2, Z can forge signatures for other members. Method 4 doesn't use a trusted party. Method number 4 is very similar to Chaum's original proposal for undeniable signatures, although the zero knowledge proof is very different since he doesn't want to reveal which particular key his exponent corresponds to. In the Eurocrypt 94 paper by Chen and Pederson they show a very nice protocol for proving that you know the exponent corresponding to one of a set of Diffie Hellman public keys. This is similar to the problem in (4) above. Given k1=g**s1, k2=g**s2, ..., you can prove that you know one of the si without revealing which one. The protocol is pretty simple and just requires one challenge and response, although the amount of data sent is proportional to the number of ki in the set. This could be used to prove group membership anonymously. If there were a list published of public keys of people on the cypherpunks list, you could prove you were on that list without revealing your identity. I think it could be made a signature protocol by having the challenge c depend on a hash of the message. But the authors don't do it that way, they do a more complicated protocol because they are seeking to achieve unconditional rather than cryptographic anonymity. Hal

2 1

Re: Remailer Abuse Solutions
by Hal Finney 17 Dec '03

17 Dec '03

From: Bryan Reece <reece(a)taz.nceye.net> > But what about Okamoto and Ohta's digital cash scheme published in > Crypto '91? It appears to be fully untraceable and transferable. Of > course, I haven't heard of anyone trying to use this scheme (has it > been broken?) This digital cash scheme has a big disadvantage which the authors try to play down. The problem is that all spending by a particular user is linkable. It can't be connected to his True Name but all of it is linked, in effect, to his nym. This is bad because it allows profiling and dossiers to be built up about nyms with interesting spending patterns, which could then be used to identify which ones should be candidates for intensive efforts to discover their identity. Most other digital cash schemes don't allow linkability of the payor's activities, which is a much better approach. Hal

1 0

Re: San Jose Mercury News declares encryption battle over
by Hal Finney 17 Dec '03

17 Dec '03

>From the article <URL:http://www.sjmercury.com/business/compute/encrypt1115.htm>: > Under the plan computer makers could equip their machines, including > personal computers, with electronic ''locks'' of almost any strength. A > single computer model with strong built-in encryption could legally be > sold in both domestic and foreign markets. > > The key is that the encryption circuitry would be inactive in exported > machines, unless both buyer and seller obtained all legally required > licenses to turn it on. > > Domestic customers, and export buyers with a license, would get a special > key card to turn on the encryption, according to HP. Manufacturers would > thus be relieved of the burden of making different computers for export > than for domestic use. So it sounds like the idea is to build crypto around card tokens. I think HP has been pushing this for some time. The question is, will this somehow become the only way to get access to crypto? Unlike the earlier IBM/CIA announcement, this time Netscape and Microsoft have apparently been brought on board. That is a lot worse because these companies are where most people are going to get their crypto in the future. If they have open standards, we can make good crypto available. But if this announcement signals some kind of closing of the system so that only hardware tokens will be used, it could become a lot harder to make strong crypto available. There are also the economic questions about how much these key cards are going to cost, and whether they are going to be routinely supplied with computers or an extra cost item that consumers have to go out and buy. If the latter, a lot of people won't bother, and we'll just have that much larger a barrier to widespread use of crypto. It is certainly very disturbing to see these new moves. Obviously a great deal of behind the scenes negotiations and pressure has been occuring. You have to wonder why Netscape, for example, would forego the opportunity to differentiate themselves from rival Microsoft by positioning their product as the one which refuses to bow to government pressure on crypto. It's also not clear what the hardware manufacturers get out of this. Their sales overseas have never been blocked. There has been no demand for custom crypto hardware. I don't see how they have been harmed by an inability to ship computers with built-in encryption hardware. Granted there are some possible applications for such systems but I don't see the market demand which would drive this decision. Hal

7 7

PGP acquires PrivNet
by Hal Finney 17 Dec '03

17 Dec '03

The company I work for, PGP, Inc., announced yesterday that it had bought PrivNet, makers of Internet Fast Forward cookie-blocking software. More info is on the PGP web site at http://www.pgp.com/. Personally I have a passionate and irrational hatred of cookies so I am very glad to see this move! I can accept them if I'm browsing through an online store and they're being used to keep track of what I've bought, but so many sites these days are just snoopy as far as I can tell. Down with cookies! Hal

1 0

Re: Giving Kill Files a Workout...
by Alan Olsen 17 Dec '03

17 Dec '03

At 08:48 AM 11/16/96 -0800, Dale Thorn wrote: >Alan Olsen wrote: >> What a week! What is this? "Net Loon pig-pile on Cypherpunks day?" >> So far i have killfiled three people in the past two days. (That is the >> total number I filtered to trash before that date.) >> For those of you who are sick of wading through this mess, I am willing to >> show you what it will take to filter those of your choice to /dev/null or >> its local equivelent. (procmail can be your friend!) > >Thank you in advance for your filtering instructions (yawn). > >BTW, why would anyone give a shit whether you killfiled anyone or not? The point is not who or what I care to killfile. The idea is that it can be done by most people without a whole lot of hastle. There are a number of people who do not have experience in setting up procmail. I am offering to help them out in the hope that it will strain out some of the resultant noise from these "Freedom Knight" loons. (Or at least keep a number of people from dropping the list from the bogosity.) I suspect I am in a number of killfiles already... --- | "Remember: You can't have BSDM without BSD." - alan(a)ctrl-alt-del.com | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | alano(a)teleport.com |

1 0

Re: Validating SSNs
by Duncan Frissell 17 Dec '03

17 Dec '03

>Timothy C. May wrote: >> >> Indeed, I protected my privacy decades ago by discarding my issued SSN >> and substituting a different one. This "phony SSN" is what I use on my >> tax returns, my credit cards, and for my employers. >> >> Ha! None of them know that this is not my True Social Security Number! >> >> By this I protect my privacy. "The Iliad" and "The Odyssey" were not written by Homer but by another Greek of the same name. Old joke. Might I suggest though that you use varying SS numbers and varying names, addresses, and Dates of Birth so that you deny The Great Enemy a Key_field in the database of life. DCF

1 0

Re: Mirror of new export control regulations
by Duncan Frissell 17 Dec '03

17 Dec '03

At 09:10 PM 11/15/96 -0500, Alan Davidson wrote: > http://www.cdt.org/crypto/clipper311 > I'm holding out for Clipper '95 myself. DCF

1 0

RE: ideal secure personal computer system
by John Fricker 17 Dec '03

17 Dec '03

>Igor Chudov @ home (ichudov(a)algebra.com) said something about Re: ideal secure personal computer system on or about 11/16/96 7:41 AM > >Bill Frantz wrote: >> Protection against strangers walking up to your machine and using it is >> nice, and easy to do. Protection against viruses which install Trojan >> horses in your system would also be nice, but is very hard to do in systems >> where programs run with all the privileges of their users. Examples >> include (in alpha order): DOS, MacOS, Unix, and Windows (including NT). > >I wonder what are the operating systems where programs may be run with >_less_ privileges than the user who starts them? Is VMS one of such >systems? > >thanks > > - Igor. >End of message In WinNT a program may impersonate a user such as Guest. Also, trojan horses are ineffective in NT as typical users do not have write permission to system binaries. --j ----------------------------------- | John Fricker (jfricker(a)vertexgroup.com) | -random notes- | My PGP public key is available by sending mail with subject "send pgp key". | www.Program.com is a good programmer web site. -----------------------------------

1 0

Re: Why I shall never undescribe
by Sean Roach 17 Dec '03

17 Dec '03

At 08:50 AM 11/15/96 -0500, Alec wrote: >>From: Bovine Remailer <haystack(a)cow.net> >>To: cypherpunks(a)toad.com >> >>Foulmouthed Timothy May rehashes his lies like a rabid parrot >>choking on a stale mantra stuck in its poisonous beak. > >Where else today can one find such prose? Nay poetry! > >And they say poetry is dead! I thought they said that chivilry was dead.

2 1

Re: Remailer Abuse Solutions
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 1:38 PM 11/15/1996, Adam Back wrote: >Peter Hendrickson <ph(a)netcom.com> writes: >> However, if you restrict postings to an approved group of people, perhaps >> everybody on the mailing list, you can eliminate spam. How, then, do we >> allow anonymous postings to come through? Individual people on the list >> can receive the proposed post and forward it to the list if it is >> appropriate. They could even charge a fee for doing it. That's easy to >> do if there is a "paying" remailer which will handle the money for them. > Not necessarily a good idea. The post may be a hot potatoe, and the > forwarder may find themselves in legal trouble. (Say RC4 & RC2 source > code, NSA handbook, the results of the Mykotronic's dumpster diving > spree, etc). Exercising `editorial control' has landed some ISPs in > trouble, to the extent that some are specifically avoiding it for that > legal reason alone. Being _paid_ for forwarding the message may make > that even worse. Yes, this is the part of my proposal with which I felt least comfortable. Actually, not to flog a dead horse or anything, this is a perfect application for semi-anonymous authentication. Anybody on the list could forward the mail, but nobody need know exactly who sent it. > Howabout someone liberates skipjack and forwards it to you via > remailers with $50 for your trouble. Do you bite? I thought not, NSA > interviews, ITAR violation, etc. Well, there are ways to do this. For instance, you can send it to a bunch of other people anonymously at, say, a dollar each. It will get around quickly, albeit at greater inconvenience and a higher cost. But, for something this important that would be acceptable. > Ecash for email works better to stop spam sent directly to email > addresses where you don't cash the money as a curtesy, and your > software junks if it doesn't have valid ecash. Email spam itself is > getting mildly annoying lately, I get a couple a day average at the > moment. Except most people don't have e-cash accounts, software that handles e-cash, or the interest in keeping a site which is secure enough to handle e-cash. This is the feature of having the remailer operator deal with it. The technology can be introduced to the existing system with minimal hassle and cost. All you need is one remailer operator to do it. Incidentally, a similar idea can be used to handle flooding attacks on remailers. A bad person could take down a remailer by directing many encrypted packets to it that did not contain any payment. This is hard to solve, of course, because the mail all comes from other remailers. The solution is for the remailer itself to not accept mail from other machines that do not pay. The other remailers in the network make a payment themselves (out of money they already received) to make it worthwhile for the remailer to look inside the message and see if there is even more business. Does anybody know if military communications systems ever take this approach? I know that a highly redundant network is used when any part of it can be taken out. What is awkward about this is that everybody wants to send messages at the very same time the bandwidth is attenuated; i.e., during battle. I'm guessing that in practice everybody in the network - all of whom are basically trusted and identifiable - is ordered to send only urgent traffic. But, it would be neat if there was a way to budget bandwidth for every unit, just like we do for ammunition. Peter

1 0