December 2003 - cypherpunks-legacy

Re: Edited Edupage, 24 March 1996
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

Perry E. Metzger wrote: > 2) I strongly hope that Netscape tries to move the product towards > standards based mechanisms like the IETF's RTP protocol, which are > in widespread use, Unfortunately RTP is not a crypto protocol, and does not have a standardized encrypted form. Therefore any encrypted protocol is necessarily proprietary and non standard, unless Phill Zimmerman has published a standard. If Netscape creates a standard for encrypting RTP, and publishes it, that will be a move towards a standard, not a move away from a standard. One mechanism for encrypting RTP would be to construct a shared secret key by DH exchange, or Rabin if one wished to dodge patents, construct a cryptographically strong pseudo random data stream from the key, using Ron's code, and for each RTP packet, encrypt using a block from that data stream as the packet key. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: What backs up digital money?
by Bill Stewart 17 Dec '03

17 Dec '03

At 03:25 PM 3/28/96 -0500, Black Unicorn <unicorn(a)schloss.li> wrote: [a bunch of mostly correct things, except for] >But instead of backing in gold, or some tangible asset, dcash is still >ultimately backed by the full faith and credit of the government who's >currency the dcash is denominated in. Well, after dealing with the full faith and credit of the issuing bank, you may acquire some pieces of paper which are backed by the dubious faith, credit, and reputation of some government. As you later say, >it is still just a second tier bearer instrument. >I think that the diet coke backed cash I tried to promote back when was >closer to a "currency" than d/ecash issued by a bank and drawable on >government currency. (Maybe this is why no one was interested?) I've used coffee-based currency, backed by my co-worker Joe. Worked fine, and excess profits usually got turned into bagels and donuts. >Real solid ecash, and the kind of cash I would like to see out there, >would be limited to a non-dilutable one time issuance and backed in some >precious commodity held on reserve. A closed-ended share of a stock of >gold, for instance. That would require no intermediation of a "currency" >based on the full faith and credit of an issuing sovereign. Most of my money is usually in banks, where it exists as bits in a ledger rather than as government-backed paper; my credit union at least has private insurance in addition to the government insurance, so there's someone honest backing the bank, even though it's only denominated in fiats. Digicash of various sorts may be able to get some political support if some bank wants to issue accounts denominated in ECUs, though ultimately the issue isn't whether it's backed by governments, gold, or insurance agents, but whether someone's willing to give you stuff for it when you want stuff. If you're buying physical stuff, you're probably buying from someone nearby, so it's usually useful to be able to _pay_ in local-flavored currency. In Europe, "local" may include the currencies of several nearby countries; in the US lower-48, that usually means US dollars, since Canadians will usually take them and Mexican pesos can be trusted to devalue rapidly. ObLinguaPunk: One cypherpunk-relevant use for speaking foreign languages is that you sometimes need to speak local-talk long enough to find an Internet connection when you've boogied overseas to retire on your digicash earnings or run your consulting business to make the big bucks before you go rent a cabin in Nevada from some Panamanian corporation that's owned by several Caribbean bank accounts.... #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 1995: Chat rooms, espresso, and Linux 1996: Exon, melatonin, and Java.

1 0

Re: Why Americans feel no compulsion to learn foreign languages
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:31 PM 3/28/96, Alan Horowitz wrote: >Certainly, I believe TCM's proposition that there is no "economic need" >for an American to learn a second language. > >On the other hand, I haven't seen any demonstration of the "value" of >learning history. Yet, who would argue that ignorance of history is a >good policy to follow? Bad analogy. Studying a combination of world history and one's nation's history is an obvious thing to do. And good bang for the buck. Choosing a language is a much harder proposition. No single language stands out for most Westerners, at least not nearly as much as it once did. (Or one of several "top pick" languages, e.g., German, French, and Spanish.) My last word on this language topic will be this: far from being a closed, ignorant, immigrant-hating, shit-eating nation, as some of the usual America bashers have intimated, the decline of language skills reflects a decline in the "ethnocentrism" of the past. A few decades ago, one studied German to be a scientist, one studied French to be cultured, one studied Latin for unexplained reasons (just a joke), and one studied Spanish if not one of the others. As immigrant waves entered the U.S., and as the anti-Westernism meme spread amongst educators, Latin faded out, then German, then French. (All are still taught, but not in the numbers once seen.) Given the explosion of languages--Yoruba, Talegu, Tagalog, Russian, Korean, and on and on--the role of French, German, and to some extent Spanish is less clear than ever. (Spanish is admittedly a growing language, but not in technical fields...just a fact.) So, I am not surprised that American students have no desire to learn one of these languages. They'll have to search to find people to practice with, which they won't (on average, not at the 2-sigma point). While I don't deny the niceness of knowing Russian or Korean, the effort needed to achieve reasonable proficiency (beyond the simple words Bill Frantz was talking about....this thread is about actually learning a language, not a handful of phrases!) is not worth, in my opinion and that apparently of many others, the effort. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Re: So, what crypto legislation (if any) is necessary?
by jim bell 17 Dec '03

17 Dec '03

At 03:46 PM 3/28/96 -0500, Black Unicorn wrote: >On Tue, 26 Mar 1996, Duncan Frissell wrote: > >> At 09:46 PM 3/25/96 -0500, Michael Froomkin wrote: >> >> >An interesting issue, likely to be addressed in future judicial >> >assistence treaties... >> > >> >> However, future judicial assistance treaties are meaningless if you store >> your keys anonymously (domestically or internationally) so that even the >> keeper doesn't know he has them or exactly where they are in his pile of keys. > >Given the significant contempt charges that can follow a refusal to >produce items (anonymous or not) this still depends on the absence of >initial detection. You clearly don't understand. You're making the ASSumption that the organization keeping the keys can produce them in a form that is "useful" to the cops. Escrowing encrypted keys makes them useless to subpoena, and in fact it helps the key owner because the escrow agent can (and, in fact, must!) be obligated to inform the key owner if his key is requested. You also seem to assume that "contempt charges" will be able to operate world-wide, which is a highly dubious proposition. (Read Froomkin's paragraph above CAREFULLY. He said "internationally.") And in any case, I consider it highly doubtful that anybody would contract with an escrow agent and identify himself by name. It would be a simple matter to operate "escrow agents," just glorified data-holders, who would receive data anonymously and send it out just as anonymously, to the person who can identify themselves via some sort of encrypted ID system. Even "detecting" such a transfer is useless because the cops won't be able to figure out what the data is, since it's encrypted in both directions while being transferred, in addition to being encrypted while being held, with a code the escrow agent doesn't know. In short, you need to comprehend what you're responding to before you express your opinions. You're living down to my expectations. >> In fact, I suppose that government operation of the identification system >> (drivers' licenses, passports, etc.) in general is also horribly inefficient >> and should be attacked on efficiency grounds. > >You might not like what you get in response. Streamlined and uniform >identity documents generated at birth and renewed with tax filings would >be the likeliest efficiency improvement. An inefficient government >identification system is to the advantage of the privacy seeker. You seem to be ASSuming that an "efficient identification system" is one that will ALSO operate to the benefit of the government, as opposed to the individual who wants to be identified for only limited purposes. I don't think so. Chaum's encrypted ID system described in the August 1992 Scientific American makes it clear that identification can occur without the ability to cross-reference databases. Chaum's system, if implemented with current microprocessor technology, would be extremely "efficient," at least from the standpoint of the amount of human effort involved. It would, however, be extremely hostile to the government. Jim Bell jimbell(a)pacifier.com

2 2

Re: Sun patch pulled
by Mark.Graff＠Eng.Sun.COM 17 Dec '03

17 Dec '03

Folks, I am the person responsible at Sun for coordinating security-related patches. I got several copies of Wednesday's message about Sun's syslog/libc patches. There are plenty of disasters we can blame on ITAR, but the statement > Yup, that's right. The syslog hole that was so well publicized by > CERT will remain open indefinitely because the ITAR makes it illegal > for Sun to distribute the fix! is in fact 100% incorrect. I know; I was personally involved at every stage. I'm afraid the detailed explanation which follows is necessarily stultifying. But the key points are: 1. Our syslog patches (and in fact all of our security-related patches) are available to anyone who wants them, anywhere in the world, whether they are a Sun customer or not and whether they have a support contract or not. This has been Sun's policy since about 1990, and it hasn't changed. 2. We did make a change in February--it seems fairly routine to me, but you be the judge--but we weren't prodded by any government figure. We were just making sure that we complied with the letter of the law. That's no fun either, but it's a far cry from "gummint dweeb[s] whispering threats". 3. We didn't document the change very well, which surely contributed to the confusion. I expect we will update the README files to try to explain this better. OK, now before I lose you in the morass of detail that follows, please note this. Sun maintains an alias, "security-alert(a)sun.com", for questions about security issues, especially as they relate to patches and fixes. I'm the person who tends it (I got about 2,000 inquiries last year) and I will be glad to answer any questions like this in the future. (Please send them to the alias, not to me: it's got backup coverage and my personal e-mail doesn't). If this inquiry had gone to any of our Solution Centers, they would have come up with this answer, too, by the way. All right, Here We Go... SYSLOG/LIBC PATCHES Here is the list of patches currently available for libc to patch the syslog vulnerability. Note that, for some versions, there are both "U.S." and "international" versions. This distinction is the source of the confusion. I'll explain it later. PATCH # VERSION RELEASED --------- ----------- ------------ 100891-13 - SunOS 4.1.3 Oct 27, 1995 (International) 101558-07 - SunOS 4.1.3_U1 Oct 27, 1995 (International) 102545-04 - SunOS 4.1.4 Nov 16, 1995 (International) 100890-13 - SunOS 4.1.3 Feb 21, 1996 (US only) 101759-04 - SunOS 4.1.3_U1 Feb 21, 1996 (US only) 102544-04 - SunOS 4.1.4 Feb 21, 1996 (US only) 102903-01 - Solaris 2.3 Nov 2, 1995 101945-36 - Solaris 2.4 Jan 11, 1996 102905-01 - Solaris 2.4_x86 Nov 2, 1995 Notes: 1. The patches shown for 4.1.3 also apply to 4.1.3c. 2. Solaris 2.x (SunOS 5.x) systems are internationalized, so there's no distinction between "US-only" and "International" versions. To completely close the syslog family of attacks, you will need to install recent versions of the jumbo kernel patches (not shown) also. 3. No patches are necessary for SunOS 5.5 (Solaris 2.5) and later. The fixes made the release. "US-ONLY" VS. "INTERNATIONAL" VERSIONS OF THE C LIBRARY In SunOS 4.1.x (the BSD-based Unix), Sun maintained two separate versions of the C library. The so-called "domestic" version contained DES-based crypto routines, accessible via a public API. Since we interpreted ITAR to outlaw the exportation of such a library, we modified our build procedures to produce a less capable version which we could legally export. All this time, then, we have maintained two separate sets of patches, one which could legally be exported and one which could not. (I'm not going to get into details about the technical differences between the two.) With the advent of SunOS 5.x, we introduced new methods of handling both libraries and patches, and this problem went away. That's why there is only one version of the C library for each version of the OS. for many years, we called the library version which contain the forbidden-to-export stuff the "domestic" version, and the other the "international" version. When we made the latest change (described in the next section), we changed the wording from "domestic" to "U.S.-only". After all, the word "domestic" applies to every country from a certain point of view, doesn't it? The nomenclature is still not quite right. Here is an attempt at a precise statement. If your SunOS 4.1.x system has the "crypto kit", you can and should use the version of the C library dubbed "U.S.-only". If your system is not using the "crypto kit" --whether or not you or it resides in the U.S.--you can and should be running the "international" version. The crypto kit costs extra, so if you're not sure, you're probably running the "international" version. Most of our customers are. The folks at your local Solution Center can probably explain this better than I can. I encourage you to contact them for more details on this part, or help in determining which software you are running. WHAT CHANGED IN FEBRUARY The change we made in February was to stop the practice of making the "U.S.-only" version freely available through our world-wide patch database. It is, after all, "world-wide"; so, after one of our periodic reviews of patch practices the responsible manager made the policy change. We removed the library code from the latest versions of the 4.1.x patches, and updated the README files to explain the change. I don't know for certain whether this was in response to any particular warning from the U.S. government. I'm assured by the person who made the decision that it wasn't. Anyway, the only impact of this change on our customers is that 4.1.x customers who do have the "crypto kit" installed on their systems now have to go through the Solution Centers to get C library patches. (I guess a second impact is that folks who aren't licensed to have the crypto kit can't get the "U.S.-only" library version--but they're not entitled to have it, and in theory couldn't make use of it anyway.) I can understand why the original poster found this difficult to figure out by him- (or her-) self, I guess. Anyway, the README file does say, right near the top, Please contact your Sun Solution Center or other SunSoft authorized service provider (ASP) in the U.S. to obtain a copy of the actual patch. ... and that's what several of our affected customers have done, since. We certainly apologize for any confusion. -mg- Mark Graff Sun Security Coordinator mark.graff(a)sun.com security-alert(a)sun.com p.s. I'll include this explanation in my next Sun Security Bulletin. (If you want a free subscription, BTW, just send a message to security-alert(a)sun.com with the subject "SUBSCRIBE CWS your-mail-address". p.p.s (If anyone wants to discuss this further with me, please pursue it privately. I didn't pop my head up over the parapet to get drawn into a big public ITAR debate.) From: cpunk(a)remail.ecafe.org (ECafe Anonymous Remailer) To: cypherpunks(a)toad.com Subject: Sun patch pulled (was Re: HP & Export of DCE) Date: Wed, 27 Mar 1996 23:16:56 GMT I noticed that Sun's latest libc patch (101759-04) is empty. Previous versions contained the complete U.S. version of libc, including the tres-dangerous DES and crypt functions. In the current rev only the README remains, presumably because: EXPORT INFORMATION: This patch includes code which performs cryptographic functions, which are subject to U.S. export control, and must not be exported outside the U.S. without prior approval of the U.S. government. Prior export approval must be obtained by the user of this patch. So, you might ask, what fixes is Sun not distributing??? (Rev 04) 1190985 gethostbyname() can trash an existing open file descriptor. 1182835 portmapper silently fails with version mismatch by PC-NFS client 1219835 Syslog(3) can be abused to gain root access on 4.X systems. Yup, that's right. The syslog hole that was so well publicized by CERT will remain open indefinitely because the ITAR makes it illegal for Sun to distribute the fix! So did HP and Sun spontaneously, simultaneously develop crypto awareness, or is some gummint dweeb whispering threats in their ear?

1 0

java security
by rollo＠artvark.com 17 Dec '03

17 Dec '03

>Based on recent events, as soon as you implement anything in Java you are >making the creation of a secure ANYTHING a highly uncertain venture. You >have just made it MUCH MORE difficult to ensure security, not less, >given the current state of the Java art. I will be spending a fair part of my time over the next few months investigating java security, especially from the point of view of trying to break it. I'd like to hear from coderpunks/cypherpunks having ideas about how to break it, especially if you don't have the time/energy to pursue the idea to fruition yourself. Rollo Silver | e-mail: rollo(a)artvark.com | Artvark | Home page: http://www.artvark.com/artvark/ | PO Box 219 | Voice: 505-586-0197 | San Cristobal, NM 87564 USA | Compuserve 71174,1453 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=

1 0

Account ID Controls
by Duncan Frissell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- We are informed that the primary method of social control in the future will be account access control. Bank account, credit account, phone account, internet account, all of these accounts are supposed (or proposed) to be restricted to True Persons (or other entities reliably linked to True Persons). The Powers That Be will then be able to track Bad Guys via their account activity and use denial of service as a punishment. Of course, these controls will only work if the accounts are not anonymous. Which leads us to the ads recently appearing in the New York Daily News. Electronics Communications Corp (800) NYNEX 31 offers a no credit check cellular phone. You call them up, supply name, address and phone number and they overnight you a phone C.O.D. for $243.56. This includes one hour of talk time. The ongoing cost is $24.99/month and $36.00/hour (60 cents a minute) for airtime (payable in advance). You own the phone and your service contract is renewed on a month-to-month basis as you pay the bill. I wonder if they will ship to accomodation addesses? If the authorities can't keep cellphone service out of the hands of the unidentified anonymous hordes, it's hard to believe that they will be able to keep any other kind account out of those hands. DCF "When phones are outlawed, only the outlaws will have phones." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMVxA4oVO4r4sgSPhAQEo2gQAo/1Is0hIMeQtRLii3rzl+s5+ZDPRbhSa m1Zjk/kuaNdhzLej0r671AsWov131KMCcRvEM9QlxuLJnYWDiwXpEnaY3/terI+B 4H+s7T5uxzjnKyGVthOqW+bDSt2yur61j9BJULUiQJKNO/PiSHAXaqqkA5HxgFpq 875rXZMEEbk= =/DJs -----END PGP SIGNATURE-----

1 0

Re: java security
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 08:44 PM 03/29/96 -0700, rollo(a)artvark.com (Rollo Silver) wrote: >I'd like to hear from coderpunks/cypherpunks having ideas about how to >break it, especially if you don't have the time/energy to pursue the idea >to fruition yourself. I wonder if it's possible to _subvert_ Java. That is, have site "A" send along some modifications to a Java class, so that when the user logs into site "B" (which calls that class), Nasty Things Happen. What site "A" does raises no alarm flags _until_ site "B" trips the trigger - making it look like site "B" is the Bad Guy. (WARNING! CDA Violation!) Hell, you might even be able to spread the modifications around some, so that it's even less obvious where they were done. Maybe even use the technique to modify Java itself, thus disabling security controls. Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMVv4Y8VrTvyYOzAZAQEt3wP+JBpJtTLoBLuMSqWpl6b8qSsIiIVXi6fh 9JiK9xfOEptPljW1Ca/KhHNmX8wHpUyR8U8vU4XZKraAAqcGiPlHO4ojuaJfa87I LgkKGuSlsmaA7VSIZc7NkjH87B+IRhMgk5IkAE15StGyDAh9ugEm1e8X0PZjcDV0 HgokmdQMppA= =XHYT -----END PGP SIGNATURE----- ------------------------------------------------------------- "Giving money and power to government is like giving whiskey and car keys to teenage boys." P. J. O'Rourke (b. 1947), U.S. journalist. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> http://www.shellback.com/personal/merriman/index.htm

1 0

Re: So, what crypto legislation (if any) is necessary?
by jim bell 17 Dec '03

17 Dec '03

At 05:49 AM 3/29/96 -0500, Black Unicorn wrote: >On Thu, 28 Mar 1996, jim bell wrote: > >> Escrowing encrypted keys makes them useless to subpoena, and in >> fact it helps the key owner because the escrow agent can (and, in fact, >> must!) be obligated to inform the key owner if his key is requested. > >I thought I would take the time to let everyone know that this is >baseless as well. Most jurisdictions forbid third parties to reveal >prosecution inquries to the principal for which they are holding >documents or other information. A VERY few have laws on the books that >require this disclosure. Switzerland is no longer one of them. As usual, Unicorn is FOS. Not entirely in his facts, but in his conclusions. To "forbit third parties to reveal prosecution inquiries" is an obvious violation of freedom of speech, and in fact is PRIOR RESTRAINT. Maybe Unicorn can't see what's wrong with that, but I can. It is unclear whether this has ever been tested in court, or whether that test occurred recently. Now, in practice I recognize that in the past large organizations which are subpoenaed usually comply with requests to keep an inquiry secret, but one of the effects of the "crypto revolution" and the "net revolution" is clearly to decentralize information power from the places it used to be carefully kept (IBM, ATT, etc) and is now distributing it among many more, far smaller organizations which are much closer to the people the prosecutors might be inclined to target. (for example, your friendly neighborhood ISP). Furthermore, the development of good encryption will allow a willing ISP (for example) to send an encrypted (and possibly semi-anonymous) message to the target of the investigation (or possibly a public USENET area, unaddressed), containing a pre-arranged alarm code to be sent to the target of the investigation, in such a way that any other people (for example, the brainless cops) won't know. The target will be assured (though encryption and signing, or prior arrangement) that the message could only have originated from the contractor (ISP) but the target (and nobody else, as well) will not be able to prove this knowledge to a third party. For example, if I ask my ISP to send me an anonymous, encrypted message with the word, "Rosebud" in it to me if he receives any requests to tap my connection, he can do so with no fear of being discovered, because no third party can decrypt the message, know who is is from, or know the real meaning of the word, "Rosebud" in the context of an encrypted, anonymized message. Further, since the whole thing is by pre-arrangement, even I cannot prove (to the satisfaction of a third party) that the message really meant what I would interpret it to mean. The message is useful to me, as a warning, but it could never turn around and "bite" the ISP. The end result is that your foolish opinion of what the law allows will simply become irrelevant: The government cannot mandate what it cannot enforce, and it cannot enforce what it cannot detect. You may ask, "Why would the operator of a small ISP want to take even a minor risk informing the target of the investigation?" There are a number of obvious answers: 1. He's promised his customer to do so. 2. It's in the contract. 3. And the ever-popular, "He's afraid of getting killed, or his ISP business torched, if word later leaks out that he failed to inform his customer of an investigation." Don't underestimate the significance of such a risk to those people. Destruction of even a full phone switch would not have fazed ATT in the 1960's, but a small ISP depends on valuable equipment at (presumably) a single location. Getting a person mad at them for failing to anonymously inform them of an inquiry would NOT be the best tactic for these small-time operators. >Even if a judge was convinced by the defense not to levy heavy fines >against a third party who pleaded that he or she was simply unable to >comply, informing the principal would literally assure such fines would >be imposed regardless. Again, you assume that informing "the principal" would be detectable. Your wishful thinking is palpable. I really wish you'd be able to distinguish what "the law" could do, given limitless knowledge of the actions of the population, and the REAL WORLD, in which those judges and prosecutors and cops are limited in what they can do by what they can know. This is critical, because we are rapidly approaching a time in which what these people know will be dramatically limited by many of the technologies regularly discussed on Cypherpunks. >Criminal charges of obstruction could easily attach. Bullets could easily fly. You repeatedly state what might, hypothetically, happen, but you don't back it up with a realistic assessment of what actually would _likely_ happen. > Obstruction in connection with narcotics cases or other major >felonies are generally extraditable offenses as well. Someday, obstruction of the Constitution by government agents will be a death-penalty crime. >Once again Mr. Bell pulls legal analysis out of his rectum rather than >basing it in fact or research. > >With Mr. Bell as a defense attorney, who needs prosecutors? If I intended to limit myself to the tools of the court room (that's the enemy's playpen, BTW) I would probably be just as ineffective as the next defense attorney. I've frequently found that the question of who wins in any confrontation is strongly affected by whether I allow myself to be lured into the home territory of the other. This is actually more a psychological battle than a physical one. You obviously believe that the cops and judges can frequently win, if they are able to control the location of the battle; this is true, but it ignores the fact that "the legal system" is generally an 8-hour-per-day, 40-hour-per week system. Going outside the system and attacking directly bypasses all the rules and restrictions which are set up to allow THEM to win. This may sound unfair to people brainwashed to believe that the court system is and should be the final arbiter, but I suggest that long ago they lost whatever moral authority they once might have had. Every time you talk about them fining or prosecuting some third party for not cooperating, you demolish your own claims. Jim Bell jimbell(a)pacifier.com

2 1

Blind signatures
by Asgaard 17 Dec '03

17 Dec '03

Perry said: > "How does blinding work" ... > are fine things to talk about but Yeah, how does it really work? Could you explain it in 'kitchen modular arithmetics' to us groupies? Asgaard

1 0