RE: Using signature-only certs to authenticate key exchanges
Enzo, My apologies for being unclear. Since I am not an attorney licensed to practice law in Hong Kong, I of course cannot speak to the legalities of using a cert/key with a signature-only key usage restriction for encryption purposes. Though I suspect even an attorney meeting the above qualifications could not answer with certainty which consequences the manufacturer of signature-only devices might face should such devices be used for encryption purposes. As a data point, to the best of my knowledge, the use of signature-only keys for encryption purposes has not been tested in any court of law anywhere on the planet. Which tends to mean that any claims as to what the consequences of doing so would be are speculative at best. (Long rant why relying on an application outside one's control to enforce key usage is bound to fail omitted). --Lucky Green [EMAIL PROTECTED] "Anytime you decrypt: that's against the law". Jack Valenti, President, Motion Picture Association of America in a sworn deposition, 2000-06-06 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Enzo Michelangeli Sent: Wednesday, August 16, 2000 16:40 To: Cryptography@C2. Net Subject: Re: Using signature-only certs to authenticate key exchanges Lucky (and Bill, in another message), My question was about the legal meaning, or, better, prevalent legal interpretation, of "signature-only key". I know how authenticated key exchange mechanisms work, and, on the other hand, Ron Rivest has shown that at least in principle there are other ways of achieving confidentiality by relying only on authentication primitives. This is not a purely academic issue. For example, in Hong Kong the import of cryptographic devices is exempted from import licensing (not a big hurdle, but an annoying bureaucratic procedure nevertheless) if they are "only used for authentication or digital signature": http://www.info.gov.hk/tid/faq/strategic1.htm#q23 This effectively exempts things like signature-only smartcards and similar tokens. Cheers -- Enzo - Original Message - From: "Lucky Green" [EMAIL PROTECTED] To: "Cryptography@C2. Net" [EMAIL PROTECTED] Sent: Wednesday, August 16, 2000 4:00 PM Subject: RE: Using signature-only certs to authenticate key exchanges Enzo, Many applications that employ certs ignore key usage restrictions. This isn't your fault or the fault of the CA. It simply reflects a 'broken' implementation. IANAL, but I fail to see how you or your customers could be held responsible for applications that use certs in ways other than the cert was intended to be used by the issuer. [...]
RE: Using signature-only certs to authenticate key exchanges
Enzo, Many applications that employ certs ignore key usage restrictions. This isn't your fault or the fault of the CA. It simply reflects a 'broken' implementation. IANAL, but I fail to see how you or your customers could be held responsible for applications that use certs in ways other than the cert was intended to be used by the issuer. --Lucky Green [EMAIL PROTECTED] "Anytime you decrypt: that's against the law". Jack Valenti, President, Motion Picture Association of America in a sworn deposition, 2000-06-06 -Original Message- From: owner-c [mailto:[EMAIL PROTECTED]]On Behalf Of Enzo Michelangeli Sent: Monday, August 14, 2000 20:03 To: [EMAIL PROTECTED] Subject: Using signature-only certs to authenticate key exchanges If I use a signature-only cert to authenticate a D-H key exchange (e.g., in IPSEC, or SSL with ephemeral DH ciphersuites) am I in violation of any licensing condition and/or, when applicable, export regulation? I'm asking because MS seems to suggest that for Win2K's IPSEC stack a signature-only cert would suffice: http://www.microsoft.com/WINDOWS2000/library/planning/security/ips ecsteps.as p [...] Here are the requirements for the certificate to be used for IPSec: Certificate stored in computer account (machine store) Certificate contains an RSA public key that has a corresponding private key that can be used for RSA signatures. Used within certificate validity period The root certificate authority is trusted A valid certificate authority chain can be constructed by the CAPI module [...] Cheers -- Enzo
RE: Clinton signs bill to count wiretaps that encounter encryption
Arnold wrote: It will be interesting to see what the reports say. But it is worth noting that according to http://www.uscourts.gov/wiretap99/contents.html there were 1350 wiretaps approved by state and federal judges in the US in 1999. 72% were for drug cases. Over the last 10 years, wiretaps have accounted for an average of less than 2500 convictions per year. Hence wiretaps convict only a tiny fraction of the US prison population, which is now over 1.3 million. While it is a popular myth that the USG counts wiretaps, the USG does not in fact do so. The USG counts wiretap orders. There is a significant difference between the number of wiretap orders issued and the number of wiretaps performed. I am not even talking about the wiretaps that are being performed without court order typically showing up at trials as a "confidential informant" source. Wiretap orders can, and virtually almost always do, cover multiple phone lines. At a minimum, a wiretap order will cover a person's home and work numbers. Even if you work at a small office, that's likely to be several lines at least. But wiretap orders can and do go beyond that. The glimpse at wiretap reality the cases in LA have afforded the public show that judges will issue wiretap orders for entire cellular providers. One wiretap order listed in the official statistics may well correspond to several hundred, or even thousands, of wiretaps. Statistics are good thing, but they need to be read carefully. --Lucky
RE: MS on NSA_KEY in Windows
Sergio Tabanelli wrote: [About OffloadModExpo] [...] 4. In any case in my opinion it is completely unacceptable that a system administrator can access userss private keys without the user knowledge and assent. I don't see a way to prevent an admin from gaining access to a user's keys under the NT security model. But all this aside, there is a sound reason why a software crypto implementation would want to offer OffloadModExpo: hardware acceleration. Modular exponentiation is a painfully CPU-intensive task. The market for modexp accelerators is pretty sizable and growing. Most sites that make heavy use of SSL that I am aware of are either employing hardware crypto accelerators or are planning to do so in the very near future. It makes perfect sense for a crypto library to be able to call out to a modular exponentiation accelerator if such an accelerator happens to be installed. --Lucky
DeCSS defense briefs
The EFF has made available for download the briefs filed in opposition to the preliminary injunction requested by the DVD Copy Control Association in the DeCSS case. The plaintiff has until the 12th to file their response. The PI hearing will be held on the 14th. http://www.eff.org/pub/Intellectual_property/DVD/ This is a very important case that touches on free speech, the right to reverse engineer for the purpose of interoperability, and other principles long recognized by US and non-US law. For more information on DeCSS itself, see http://www.opendvd.org See you in San Jose, --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
An excellent DeCSS site
For those of you that follow the DeCSS case, there is an excellent site that offers not only all legal documents, but also features relevant press clippings and additional information on copyright and IP issues. Lot's of background material is available as well. http://www.virtualrecordings.com/mp3.htm --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
DeCSS Court Hearing Report
claimer: I am not an attorney licensed to practice law in the State of California. The preceding represents my personal opinion and should not be considered legal advice]. --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
RE: cracking GSM A5/1
Real-Time Cryptanalysis of GSM's A5/1 on a PC Alex Biryukov and Adi Shamir At last! Congratulations are in order. Way to go, Alex and Adi! Between the COMP128 and A5/2 work of our group and Alex and Adi's break of A5/1, my motivation for finishing that software radio-based GSM interception station has just increased greatly. Not that I wasn't motivated to begin with. :-) Even counting the almost 200 GB of drive space that seem to be required by this new attack, we still should come in well under the USD 10,000 target figure. We tested the code the came out of my reverse engineering against official test vectors, so I am confident that Alex and Adi's caveat that the attack will only work if the A5/1 code is correct won't be an issue. It will be interesting to see the actual attack. Our 15 milliseconds attack against A5/2 only works because several properties of the cipher come together just right. I wonder if the same holds true for the new attack against A5/1... We live in interesting times, --Lucky
RE: New Yorker article on NSA surveillance, crypto regs
Dave Emery wrote: I certainly humbly defer to your expertise on the subject. I was aware that A5/2 was very weak, though not aware that a 5 cycle result had been found, and fully expect that (as indicated by the Shamir announcement) that there probably is a similar very fast solution to a5/1. And one supposes NSA has long ago derived these results in house though some talented outsiders have yet to find a really cheap A5/1 crack that would trivialize the required compute, meaning that finding such is not totally trivial. Your observation that you didn't know about the 5 clock cycle attack on A5/2 is noted. Our group really needs to sit down and write our long overdue GSM crypto paper. Other than better funding, the NSA has the advantage over us "outsiders" in that the NSA or their European counterparts designed A5/1 and A5/2. They didn't have to find a compromise. They had the luxury of being able to engineer it in. Our 5 clock cycles attack against A5/2 only works because several properties of the cipher come together just right. Chance? Many doubt it. We can only wait and see if similar "fortunate coincidences" play a role in the new attack against A5/1. As you say, we shall simply have to wait and see what kind of crack is most effective and how low the cracking cost goes. Shamir's recent letter hints at cracking time and resources comparable with those required to demodulate the call and follow the protocol - or less... I am delighted that Biryukov and Shamir found a sub-second attack on A5/1. Our group had an attack of just a tad under 2^40 based on Golic's paper, but I just knew there had to be a much better attack. It didn't appear that we would find that attack. I had tried to get others interested in cryptanalyzing A5/1, but most cryptanalysts are busy working on the AES candidates. For a while there, I thought that we might have to wait until AES is chosen before A5/1 would receive some serious attention. I am glad that it didn't take that long, since some 250 million GSM users worldwide currently rely on the supposed voice privacy features of GSM. Other than perhaps DES, GSM's COMP128, A5/1, and A5/2 are by far the most widely used cryptographic algorithms in the world. [On the GSM interception station project]. Have you actually written the code and tried it ? How well did it work ? And in particular have you actually cracked real A5/1 even with a 2^45 or so workfactor ? The project is still underway. It is a complex project and I don't expect it to be fully completed before 2Q2000. I am confident that the project will succeed, but I'd rather not go into more detail at this time. Watch this space. ;-) --Lucky
RE: New Yorker article on NSA surveillance, crypto regs
Dave Emery wrote: And much of the worlds wireless phone plant is GSM, which is almost always encrypted, which must add significantly to NSAs burden intercepting it, even if they can break keys very quickly... Being rather familiar with GSM crypto, allow me to say this: most GSM voice traffic globally is encrypted using A5/2. We know how to break A5/2 in five clock cycles on an ASIC. For an agency that operates interception satellites costing USD 1.5 billion each featuring antennas over twice the size of a football field, adding 5 lousy clock cycles for the cryptanalysis to the many clock cycles required to demodulate a GSM call can not be considered to be significant. Immaterial would be a better term. A5/1 likely requires more clock cycles. How many clock cycles we don't know and won't know until the cryptographic community takes a serious look at A5/1. But I from what I know about A5/1, it won't be a showstopper by any standard. I know how to build a GSM interception station using off-the-shelf hardware and a PII running Linux for a total cost of well below USD 10k. Give me a couple of billions of dollars, peanuts for the NSA, and I hereby guarantee you that I can take that system down to a single chip and some RF hardware. --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
RE: Freedom/Pipenet Security
Anon wrote: The information that "traffic shaping" (link padding?) will be turned off in the initial release is especially disappointing. Without this technology Freedom provides little more privacy than anonymizer.com, or one of the hundreds of free web proxies listed at http://www.ijs.co.nz/proxies.htm and http://proxys4all.cgi.net/. No doubt the same cypherpunks who make excuses for ZKS's lack of open source because of potential protocol instability (when they are already issuing Release Candidate versions!) will explain why the absence of link padding is nothing to worry about. It will be interesting to see how long ZKS continues to get a free pass from cypherpunks. I wouldn't fully agree that ZKS received a free pass from Cypherpunks, but I readily admit that ZKS received a "presumption of security absent final specs and evidence to the contrary" due to the fact that Ian Goldberg is their Chief Scientist. Ian, unlike all but a few, is certainly capable of designing a secure anon IP system and has built up the impeccable personal credentials to not ever have given anyone even a hint of doubt that anything with Ian's name on it is anything but secure. Therefore, Freedom received the benefit of the doubt. This was a reasonable course of action to take at the time. However, I must agree with Anon that the time for doubt is over. Freedom's present pseudonymous email system is massively insecure and subject to compromise by even a moderately competent script-kiddy attacker. Freedom email nyms allow for easy confirmation of the identity of a suspected nym user. This attack does not require the powers of the NSA, but can be accomplished by the average Bugtraq or Cypherpunks reader. At present, the use of Freedom nym email for anything significantly more sensitive than you would find comfortable discussing via your Hotmail account must be discouraged. I want a secure infrastructure as much, probably more so, than the next guy and therefore don't relish these findings. But undeniably, given the facts, these findings are the truth. Unfortunately, Freedom security holes do not stop there. Freedom, as a feature, does not provide for anonymous IP. It provides for pseudonymous IP. The exit node (AIP) knows the nym of the user making an outgoing connection. If this user has been so unfortunate as to have set up a reply block, as the default sign-up script will prompt him to do, he too will fall to the same attack Freedom email nyms are subject to. Now one may assert that the thread model for most users is not a corrupted Freedom server, but a corrupted target host. Sure, Raytheon may first subpoena Yahoo, but they will just as quickly subpoena the exit hop you chose in Freedom to access Yahoo. This task completed, they will know your Freedom nym. All that's left to do is a trivial attack against your POP server and your identity has been revealed. Your sole prayer for maintaining privacy is that your opponent will only resort to subpoenas, not hacks. YMMV, but I wouldn't want to bet any significant amount of money on the rigidity of this thin piece of straw. Sadly, the core architecture of the Freedom IP network as presently fielded appears to be insecure even disregarding the fatal email nym-based attacks. Absent link padding, an attacker with access to your modem link, your ISP's router, or you ISP's Postmaster (that is to say any attacker that bothers to subscribe to Bugtraq or knows how to access http://www.rootshell.com) will be able to correlate your activities to those of your Freedom nym. At this point, it seems that the best we can hope with respect to Freedom security is for ZKS to fix the truck-size security holes by version 1.1 and that nobody with any sensitive information will use Freedom until that time. --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
Freedom/Pipenet Security [was: RE: Two Observations on the IETFPlenary Wiretap Vote]
[Huge cc: list trimmed] Adam Shostack wrote: Freedom isn't a pipenet, its a mix. Pipenet resists certain classes of attack better, like having big chunks of the internet shut down. Over the years, using Wei Dai's term Pipenet (or Pipe-net, as it was spelled originally) has firmly been established as denotating an anonymous IP network that uses constant or otherwise data independent "pipes" between the nodes of the network. Since Freedom uses link padding, I would consider Freedom a Pipenet. It has been the recognition that data-independent traffic flows are a necessary design component of a secure anonymous IP network, especially between the end-user and the first network node, that sets Pipenet designs apart from naive implementations such as the first generation Onion Routers and Crowds. The reader can see a good visualization of the problem on the OR homepage at http://www.onion-router.net/Vis.html Know that this visualization was produced by a group that for the longest disputed that padding was in fact a necessity. But the data was clear enough to even convince them. Designs that lack the link padding property fall to a number of attacks that provide for trivial confirmation of a particular user's identity. Which makes such designs of limited, if any, interest to most Cypherpunks. Just as cryptanalysis of a cipher must, contrary to most people's intuition, typically assume known plaintext, perhaps equally contrary to intuition, attacks on anonymous IP networks must typically assume that the set of network users that possesses the required knowledge to make educated contributions to a webchat on biological agent feedstock DNA synthesis is mostly known to the watchers. At this point, determining the identity of the chatter becomes a matter of confirmation, which can be trivially obtained absent link padding. Given Internet caching devices such as the petabyte 100,000 drive RAID array operated by an US agency, the necessary analysis could probably be performed even after the fact. Coincidentally, the pseudonymous email system included in Freedom suffers from this very, fatal, flaw. Now of course ZKS is aware of it and, as I understand, in the process of replacing the fundamentally insecurable reply block-based architecture. (Though I can't help but wish they would act faster. After all, I informed them of the problem over a year ago). Until the current architecture is replaced, using Freedom pseudonymous email for communications with even mid-level security requirements would be folly. To give a practical example, I have a fairly good hunch as to the true identity of the recent poster to this list using the nym "[EMAIL PROTECTED]". Confirming the identity by sending a few emails and watching the mailspool of the suspect would not be a particular challenging exercise. No TLA thread model needs to be assumed. I probably could perform the attack myself, for zero budget, and from the comfort of my living room. [Sidebar for recent additions to the mailing lists: adding noise, aka cover traffic, would not prevent such an attack. It would simply require an increase in the sample size]. --Lucky Green [EMAIL PROTECTED] "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram
TIPEM compatible lib?
I am looking for a TIPEM 2.x API compatible free crypto library. Any pointers? Thanks, --Lucky Green [EMAIL PROTECTED]
RE: Smart Cards with Chips encouraged
Fisher International has been shipping their Smarty smartcard reader in a floppy for years. The Smarty was an evolution of Fisher's SafeBoot token, also in a floppy form factor. I received a free SafeBoot kit at the 1994 or 1995 RSA conference. --Lucky Green [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Hettinga Sent: Monday, September 20, 1999 07:27 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Digital Bearer Settlement List Subject: IP: Smart Cards with Chips encouraged I remember Ian, Adam, someone else and I talking about the card-in-a-floppy thing at CFP '96. Soulda, woulda, coulda, and all that... Cheers, RAH --- begin forwarded text From: [EMAIL PROTECTED] Date: Mon, 20 Sep 1999 08:50:44 -0500 To: [EMAIL PROTECTED] Subject: IP: Smart Cards with Chips encouraged Cc: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Source: New York Times http://www.nytimes.com/library/tech/99/09/cyber/commerce/20commerce.html September 20, 1999 By BOB TEDESCHI New Hardware Could Help Web Merchants Cut Fraud Credit card companies love the Internet, since they pocket a share of most e-commerce transactions. But like everything in the world of revolving credit, that love has limits. Stolen cards used to make purchases online, in particular, cost credit card issuers millions each year -- pushing the price of doing business on the Web higher for banks, merchants and, ultimately, users. So even as the major credit card companies and the banks that issue those cards explore ways to build Internet market share, they are also looking for creative ways to limit fraud. The recent launch of the American Express blue card, which comes with an embedded computer chip, is an example of both efforts. Since the card's chip can access a user's personal information, it will eliminate the hassle of typing in that data in every Web purchase -- and, American Express hopes, encourage people to use its card. At the same time, the chip limits the fraud by guaranteeing the shopper's identity and offering greater protection to the buyer's information during the transaction. The key to these features is a piece of computer hardware that, until now, has been foreign to the desktop: a credit card reading device. Starting in November, blue card owners will be able to obtain such a device, which they will be able to plug into their PC's, enabling them to swipe the card at home much like a sales clerk would at a retail store. Other credit card issuers are exploring similar technologies. One company that makes a card-reading device for personal computers, UTM Systems, recently announced that four major U.S. banks affiliated with both Visa and Mastercard International will begin distributing its system free to consumers before the end of the year. UTM's founder and chief executive, Robert Lee, declined to name the banks, but said they served "well over 10 million customers." The device, which costs the card issuers $6 a unit, is simple. When a user is ready to make an online purchase, the credit or debit card is placed in the UTM card reader, which is inserted into a floppy disk drive. A small window then appears on screen, asks for a personal identification number and sends the encrypted information to the retail site. When the transaction is complete, the window disappears. David Robertson, president of the Nilson Report, a credit card industry newsletter, predicted that credit card companies would be aggressive in spreading such technologies. "American Express is the first, but you'll see everyone start to do this by the end of the first quarter of next year," he said. "It's inevitable." From the standpoint of fraud prevention, card issuers have great incentive to promote the devices, he said. Issuers lose roughly 8 cents for every $100 in online sales to fraudulent card use -- "slightly higher than the market at large, but it's growing," Robertson said. "The industry has been fabulously successful at pushing fraud down in general," he added. "But that just highlights the liability associated with the Internet." Which is not to say that Visa, American Express and Mastercard are stepping lightly into the electronic frontier. Each has begun major Internet-related advertising efforts, of which Visa's is the most aggressive. According to the Nilson Report, 59 percent of Internet credit card purchases are made with Visa, 28 percent with Mastercard and 12 percent with American Express. Off line, Visa has a 51 percent share, compared with 25 percent for Mastercard and 17 percent for American Express. In part, the success of PC-based credit card readers hinges on how secure consumers feel about credit card transactions on the Web. While such devices in fact provide users more security than typ
RE: Why did White House change its mind on crypto?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of P.J. Ponder Sent: Friday, September 17, 1999 16:22 To: Greg Broiles Cc: [EMAIL PROTECTED] Subject: Re: Why did White House change its mind on crypto? Would the courts allow the prosecution to admit evidence without recognizing the right of cross examination of witnesses or examination of evidence and its provenance? I helped defend a case in law school (as a clerk; I couldn't practice yet) that involved a wiretap, and the FBI and US Attorney's Office had to give us copies of the tapes, and the phone records, and everything. That was twenty years ago, but I don't think things have changed that much. Then again, I have never been involved with a case where secret government information gathering was an issue bearing on a significant piece of evidence. Your argument is straight to the point. Since you are unfamiliar with the operations of the current FISA court, you obviously can't be blamed for not being aware of the fact that there is an US court in operation today that conducts its proceedings quite differently from the way proceedings were conducted back when you were in law school. Under existing FISA court rules, the defense is not afforded the opportunity to cross examine prosecution witnesses about evidence presented by the prosecution deemed sensitive for national security reasons. The current CESA proposal simply is an attempt to extend this well-established practice to other courts of law. I am afraid that "things" have changed vastly more in the last 20 years than you may be aware of. Just a hunch, --Lucky
RE: more re Encryption Technology Limits Eased
Declan wrote: [Various quality information elided] What I found most interesting was what Attorney General Reno said about the government's cryptanalysis abilities. When asked if she can break strong, 64 bit equivalent crypto, she said, "We have carefully looked at this and think it's possible," and declined to add details. Sure. With an n-billion dollar budget, breaking 64 bits is real-time. In addition, the USG has been leaning heavily on hardware manufacturers to add backdoors to the underlying hardware. God only knows what they worked out with some OS vendors. Anybody exploring this gets leaned on even harder. Just ask a certain Australian university professor how things went for him after he began talking about some very curious, very complex, very undocumented instruction he discovered in late-model CPU's. Instructions that will put the processor into a mode that makes OS protections irrelevant. I could give a few more examples, but I am under informal NDA on them. I am working on demonstrating some of the claims. [The problem here is that I have limited time and resources. The feds and manufacturers can spend millions on inserting backdoors. There is no budget and no paying constituency for exposing these backdoors. So the fight is between millions of dollars and hundreds of engineers vs. a few of us and our spare time. Which makes it impossible to expose all the backdoors that exist]. And when one finds such a backdoor, even some of the more clueful won't believe it is a deliberate backdoor without an accompanying video tape recording of the NSA rep discussing the insertion of the backdoor with the manufacturer. "NSAKEY"? "Oh, no, that couldn't possibly be the NSA's key. It is just a backup key with an unfortunate name". If well-known crypto experts are that trusting, what would convince the public or the press? What I found most interesting about today's announcement was not that it was largely content-free with respect to crypto export regulations and the fifth or sixth such content-free "crypto deregulation" announcement that I can remember causing the exact same predictable reactions by the press and the less operationally savvy. No, what I find interesting is that so far everybody missed the one paragraph in the announcement that actually offered new information about the USG's insidious objectives. I presume this oversight on part of the analysts is due to the fact that most readers didn't understand what the paragraph I am referring to was saying. Or perhaps they were too psyched about the "crypto deregulation" lead-in to read to the end of the document. " Protect sensitive investigative techniques and industry trade secrets from unnecessary disclosure in litigation or criminal trials involving encryption, consistent with fully protecting defendants' rights to a fair trial." Having just read the proposed bill, what this paragraph refers to is that under the proposed bill, LE will be able to enter evidence gathered by means of factory-installed backdoors, intrusion, and other means without needing to disclose to the defense or the Jury how this evidence was obtained. All it takes is for the prosecutor to convince the judge (in the absence of the defendant and his counsel) that disclosing the means of obtaining the evidence would endanger future investigations or national security. Shouldn't be too tough, given how effective The Briefing has been in the past. Suddenly, we have legal situation in which a defendant is no longer allowed to even *mention* in the court room that the plaintext evidence presented by the prosecution may be questionable. "Officer, would you please explain to the Jury how you determined that the random gibberish on the defendant's hard drive decrypts to "I sold 5 kg of cocaine"? "Counsel, you are out of order! Members of the Jury, you will ignore the question". This from an attorney I bounced my analysis off: "They want to be protected from being forced to reveal holes or techniques as part of criminal or civil trials - e.g., defense attorneys can't cross-examine prosecution witnesses about the source of their evidence, it will simply appear before the jury without explanation or authentication. An LEO will appear and announce that "the defendant sent this message, which says he wanted to do terrible things" without disclosing whether the message (which had been sent encrypted) was turned into plaintext by the feds because they'd compromised the local machine, or by compromising the software at the manufacturer, or by a brute-force crack, or [...] whatever." That's the real, and only, news in today's announcement. Under the Whitehouse proposal, FISA-court rules will apply to any trial involving decrypted evidence or any other evidence obtained by means of backdoors or system compromises. If that isn't scary to supporters of a society based on the rule of law, then I don't know what is. --Lucky
NSA key in MSFT Crypto API
Andrew Fernandes tonight published the results of his reverse engineering of Microsoft's Crypto API (CAPI). [This builds on work done by Nicko van Someren from nCipher]. Background: MSFT CAPI comes pre-installed with two keys used to check the validity of a Cryptographic Service Provider (CSP). The holder of either key can install operating system security services without user authorization. The first key is used by MSFT to sign their own security services modules. The identity of the second key holder until now been unknown. That is to say until MSFT forgot to strip the binary of NT4 SP5 off debugging symbols. Perhaps not surprisingly, the debugging symbol for the second key is... _NSAKEY, For more information and a program to remove the NSA's key from your copy of Windows 95, 98, NT, 2000, see http://www.cryptonym.com/hottopics/msft-nsa.html Note that Windows 2000 includes not just two keys, but three keys that can sign modules that will control security services on your copy of Windows. Word has it that the third key belongs to the FBI. So far, there has been no independent confirmation of this rumor. --Lucky Green [EMAIL PROTECTED]
RE: NSA key in MSFT Crypto API
On Fri, 3 Sep 1999, Tim Dierks wrote: Even if the key belongs to the NSA, I suspect that the NSA just wanted to be able to load classified Crypto Service Providers into Windows and didn't want to have to send said classified software to Microsoft for approval, so they got the key installed so they could approve software in house. Classified crypto is done in secure hardware. Any hypothetical CSP's the NSA needs to install on their own machines would not contain classified algorithms. Hence the NSA could submit them to Microsoft for signing. I am afraid the NSAKEY in CAPI has a different purpose than allowing the NSA to secure their own communications. -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
RE: US Urges Ban of Internet Crypto
Of course the German government will submit to US demands. Understand that at present, crypto isn't an immediate thread to USG's interests, despite the claims to the contrary by both crypto advocates and the government. The US and its allies have made certain that virtually every piece of mass-market infrastructure has a tappable section built in. Do a search on "crypto" at the ETSI standards documents homepage and you'll realize just how severely the communication infrastructure has been corrupted. Other examples abound. At present, the crypto strategy of the USG centers on a lot of persuasion (with limited success), expert navigation of the political process (with significantly better success, see the rubber-stamping of Wassenaar by virtually all European delegates), and comparatively little open intimidation. As crypto becomes more of a real-life problem to information gathering, the US and other governments starting to clue in as to what crypto means to their very existence will lead to the deployment of bigger guns. It may take a decade or more, but the governments will succeed in outlawing the use of strong crypto in mass market products that don't provide tappable communication link segments. Most of you probably know the following, but just in case somebody doesn't, tappable segments include all communications involving at least one heavily-regulated party. If one was to doubt that the German government will become a stalwart supporter of domestic crypto controls, just imaging what will happen once the US representative shows the German Economics Minister the video tape of the Minister and the 6 year old. Oh, you didn't know about the Economics Minister butt-fucking a 6 year old boy while the boy was forced to suck off the Chancellor? Well, chances are neither do the Minister or the Chancellor, but both most definitely know what will happen once that tape hits the media. They also know that nobody but a few extremists would ever believe that somebody faked the tape. Consequently, the German government will lick the boot that kicked them. When it comes down to pure survival, there are no rules. The truth is, which is what Cypherpunks had been about since the beginning, that widespread use of strong crypto is fundamentally incompatible with majority rule, the operations of modern democracies, and the long-term requirements of maintaining a nation state. Either strong crypto has to go or the above forms of government have to go. There are no alternatives. I know that, most old-timers in the field know that, and perhaps most importantly, the more forward-looking governments know that. Case in point, the US government is painfully aware of that fact. Which is why it has been pushing so hard to implement CALEA and GAK. Ideally on a global basis. In the medium term, which most likely includes the lifetime of the readers of this post, the above mentioned facts will cause strong crypto to not become widely deployed for general purpose end-to-end encryption. [Before a reader replies with an argument based on a claim that strong crypto is in the process of becoming ubiquitous, please take a look at your phone. Does it perform 3DES encryption? Do the phones of the majority of people you call perform 3DES encryption? Alternatively, you could take a look your email client. Does it support strong crypto? Great! Now what percentage of emails you send *and receive* each day use strong crypto? If your answer is 95% or higher, you might have a point, if it wasn't for the fact that the Minister hasn't been shown the video tape just yet]. They will not. Especially the ministry of economy is well aware that the US spies on the german industry, that strong crypto is the only protection against it, and that an open-source development model for security infrastructure is the only one providing a high enough confidence in the security of a product (and providing a Wassenaar-loophole though the public domain exemption on it's way, which they also are very aware of). Andreas -- "We show that all proposed quantum bit commitment schemes are insecure because the sender, Alice, can almost always cheat successfully by using an Einstein-Podolsky-Rosen type of attack and delaying her measurement until she opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )
RE: Wireless Networking Encryption...
Ricochet is too slow. I don't consider something that does well below 56kpbs a LAN product. --Lucky Green [EMAIL PROTECTED] -Original Message- From: Mike Brodhead [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 22, 1999 16:39 To: Lucky Green Cc: K. M. Ellis; Thomas P. Hallaran; [EMAIL PROTECTED] Subject: Re: Wireless Networking Encryption... BTW, if anybody ever finds a strong-crypto wireless LAN solution let me know. [To save time: yes, I am aware of IPSEC, SSL, etc. No, that's not what you might want to take a look at Ricochet from Metricom. http://www.metricom.com/individuals/description.htm while their main line of business is as a wireless ISP, they also claim to be able to sell you a point-to-point service. their hype states that they use RC4, but they don't mention a keylength. since it's a domestic-only product, i wouldn't be surprised to see 128 bits. then again, the same document contains the sentence "You can't find better security" which is a pretty bad sign. if you are able to find out more of their crypto details, please share them. --mkb --- Michael Kennedy Brodhead Security - Design - Development [EMAIL PROTECTED]
RE: Wireless Networking Encryption...
Well, if it is made by Lucent, then we are probably talking about WaveLAN. WaveLAN's used to offer a 56 bit DES chip option, but Lucent recently "upgraded" the crypto used to 40 bit RC4. Even issued a big press release about their new security features... BTW, if anybody ever finds a strong-crypto wireless LAN solution let me know. [To save time: yes, I am aware of IPSEC, SSL, etc. No, that's not what I am looking for. So please don't send me bunch of email suggesting it. I want the strong crypto built into the wireless LAN hardware]. Big thanks, --Lucky Green [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of K. M. Ellis Sent: Wednesday, July 21, 1999 11:59 To: Thomas P. Hallaran Cc: [EMAIL PROTECTED] Subject: Re: Wirelss Networking Encryption... Apple currently uses 56-bit DES in other password protected systems, such as the Users Groups Preferences file and for the Appleshare IP Web File Server application. I'd suspect that they use DES. A lot of their market share is overseas, so they're probably worried about crypto export law compliance. On 21 Jul 1999, Thomas P. Hallaran wrote: Apple computer just released a new wireless networking product, The "airport". This is from apple's web site: "Q. What kind of security does AirPort provide? A. AirPort offers password access control and encryption to deliver security equivalent to that of a physical network cable. Users are required to enter a password to log on to the AirPort network--and, optionally, an additional password for access to any other computer on the network. When transmitting information, AirPort uses 40-bit encryption to scramble data, rendering it useless to eavesdroppers." The product was actually developed by lucent tech. I wonder what kind of encryption is employed...? anyone know? - K. Ellis -- KB3CWP -- [EMAIL PROTECTED] - Meddle not in the affairs of sysadmins, for they are quick to anger and have not need for subtlety. - http://www.tux.org/~protozoa ---
RE: sendmail patch for smtps (SSL-SMTP)?
From: Enzo Michelangeli [mailto:[EMAIL PROTECTED]] Actually, the "simple wrapping" has been deprecated also for POP3 and IMAP, essentially to save port numbers and simplify the firewall setup. There are IETF drafts about using the "STARTTLS" mechanism also for those protocols: they can be found searching the draft pages at www.ietf.org . Ouch. Seems somebody is busy making certain that one won't be able to use standard US distributions of these implementations much longer to trivially implement the secure protocols by adding a wrapper. This is very bad news, indeed. As for simplifying the firewall setup, I would question that forcing a secure and an insecure service to run on the same port adds to the security of a site. Thanks for the info, --Lucky
sendmail patch for smtps (SSL-SMTP)?
Can somebody please point me to a patch for sendmail to enable smtps? In the interest of saving time and bandwidth: No, just installing an SSL wrapper/port redirector in front of SMTP will not work. Unlike pops and imaps, smtps involves more than just wrapping SMTP in SSL and running the service on a new port. And yes, I am looking specifically for a patch for sendmail, not other MTA's. Thanks, --Lucky Green [EMAIL PROTECTED] PGP 5.x encrypted email preferred
Disabling weak crypto in Outlook/MSIE?
Does anybody here know how to permanently disable weak crypto in MSFT Outlook 2000 (S/MIME) and IE 5 (SSL/TLS)? I'd go for a Registry hack if that's all there is... Thanks, --Lucky Green [EMAIL PROTECTED] PGP 5.x encrypted email preferred
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
IMNSHO, DES or RC4-40 have no business being in any IETF standard. If that means there won't be an IETF standard, fine. And if that means that deployment of a known insecure technology will be slowed due to lack of standatization, better still. Considering the alternative, a "security" architecture designed to be be weak that will remain around for backwards capability for decades, no TLS today wold be much better for the future of the Internet than TLS with DES. The inclusion of weak ciphers in TLS is really just a symptom of a much more severe problem: the IETF is no longer under the control of the geeks. Sound engineering is being replaced by "feel good" politics. 128 times XOR, 128 bit IDEA, who cares how good the tech is. As long as we can tell the customer we are standards compliant. [I know Jeff does not fall into this category. He has done an admirable job. Perhaps nobody can forever hold back the tide of politcial control over engineering]. --Lucky On Fri, 25 Jun 1999, Jeffrey I. Schiller wrote: Actually for the TLS crowd, going to DES is a step up. I presume that the TLS WG is planning to use DES to replace the RC4 40 bit cipher that was used for export compliance. Normally we would not profile a weak cipher for use in export applications. We made an exception for TLS/SSL because it was already widely deployed and it didn't make sense to have this battle (the export control vs. strong security) hold up the standardization process for it. An interesting issue here is should we remove RC4 40 from TLS as a "price" for adding DES or should we require that both be removed before the next TLS document is published as a Proposed or Draft Standard. I would be interested in hearing people's opinions on this (though given the recipient list on this message, I have a pretty good idea what I am likely to hear!). -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
OpenSSL is a library. It should support whatever the standard supports and whatever users and/or authors of the lib desire to be in the lib. That may include broken or null-ciphers. But the user should have to take positive action to get at the broken ciphers. I believe by default, OpenSSL should ship with the weak ciphers disabled. And there should be a clear warning: "Not secure, don't fool yourself, do not use, etc]". Offering ROT-13 in a library you one maintains is one thing. Making broken crypto an Internet security standard is another matter entirely. Doing so is bad engineering, bad for the Internet as a whole, and ultimately worse for security purposes than no crypto at all. (Reader: see other posts on this topic if the last statement doesn't make sense to you). --Lucky On Fri, 25 Jun 1999, Jeffrey I. Schiller wrote: Ben Laurie wrote: OpenSSL has them disabled by default. But I am torn on this question: these new ciphersuites give greater strength than existing ones when interopping with export stuff. Is it sensible to refuse to add stronger ciphersuites? If it isn't, because they are crap, should we (the OpenSSL team) disable _all_ export ciphersuites? Speaking as a user of OpenSSL... Today I can accept RC4-40 connection on my servers from export browsers. -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
A5/1 FAQ
The A5/1 release at this month's Cypherpunks meeting brought up a few questions from the attendees. Since I suspect others might have the same questions, I'll answer them below. o A5 is an LFSR-based stream cipher. It takes a 64 bit key and a 22 bit frame number. Ross Anderson's variant was mostly correct. o All GSM keygen implementations we looked at set the last 10 bits of the key to zero. That doesn't mean there may not be GSM providers that use the full 64 bit keyspace. It simply means we have yet to find one that does. As a first approximation, the attacker knows 10 bits of the key. o During about the first 1/10th of a call the vocoder will encode silence. A very rough estimate is 13000 bps * 0.1 s = 1300 bits of known plaintext. Clearly, the cryptanalyst has a lot to work with here. o I would love to read some well-founded estimates on how fast this algorithm could be made to run on a Pentium class CPU and a low-cost FPGA. Just so we all know what the upper bounds for a brute force attack are. Not that I believe brute force to be the most efficient means of attack. o I am pretty sure we know how to find A5/2. It mostly requires some simple hardware work that we have not had time to implement. Stay tuned. (I don't make a dime of exposing the incompetence of the GSM designers or how intelligence agencies have subverted GSM's security to the detriment of over 100 million users worldwide. This project only gets cycles when I have some spare time. Claims by members of the GSM MOU that our work is funded by suitcases full of cash from GSM's competition notwithstanding. My apologies if things have been a bit slow in progressing for a while. o offers from websites with export controls in place to host the code are appreciated. I will email the algorithm to anybody I personally know to be an US citizen. The rest has to wait until nature takes it course. Which, if history is any guide, won't be very long. Have fun, -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
RE: Starium announces STU-III for the masses
Starium is selling hardware. The protocol for their current generation devices, of which I own one, has been public for years. I am not surprised that Eric is continuing this tradition for their next generation boxes. However, releasing protocol specifications is not synonymous with releasing a compatible software implementation. If you want to have a compatible software implementation, somebody would have to write it from the protocol specification. Which may be easier said than done, for technical reasons that I explained to the Harmless Little Project folks over a year ago. See the HLP mailing list archive at https://www.cypherpunks.to/hll/list/threads.html Eric is doing all the right things, his design just doesn't lend itself to software emulation very well, which is fine, since ease of software emulation, unlike it was for the HLP, is not a design criterion for Eric's devices. --Lucky On Thu, 29 Apr 1999, Bill Stewart wrote: At 09:05 AM 4/29/99 -0400, Trei, Peter wrote: I asked Eric if the protocols will be published, so that compatible software implementations can be created. He said yes. Great! BTW, this sounds rather like the Harmless Little Project, which appears to be moribund. HLP proposed designing a Harmless Little Board that you could build for about $100, with a compatible software implementation. While that appears not to have happened, there are a number of $5 full-duplex sound cards, $20 28.8k modems, and cheap DSP and CPU chips around that designing a board to sell in that price range should be reasonable assuming you can sell enough volume. I'm glad it's actually being done! Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
bind with DNSSEC finally released
Seems bind 8.2 with the long-awaited secure DNS fully integrated has finally been released. Say goodbye to DNS spoofing. Since the included crypto is meant to be used for authentication only and the licensing agreement prohibits the use of the said crypto for non-authentication purposes, the distribution is freely exportable. :-) Install bind 8.2 on your DNS server today and permanently fix one of the largest and longest-standing security holes on the Internet. ftp://ftp.isc.org/isc/bind/src/8.2/ --Lucky Green [EMAIL PROTECTED] PGP 5.x encrypted email preferred
New keys for Lucky Green
I tried this a few months ago, at which time the key server mysteriously refused to store my new keys. So let's try it again. The following keys for Lucky Green, shamrock@[netcom.com,cypherpunks.to] have been revoked for administrative reasons: 0x113219E1 0xB663B0FD 0xB7F2BC05 Please use the new keys below. Note that the keys are email address specific. (Now if PGP allowed the user to revoke individual email addresses on keys, I wouldn't have to go through this exercise...) [EMAIL PROTECTED] 0x375AD924 [EMAIL PROTECTED] 0xD0D4AEC7 DSS/DH 0xBCA6DBD1 RSA If you signed my keys in the past (or would like to sign them now), please contact me with your phone number and a good time to call. If I signed your keys with one of my revoked keys, please also contact me so I can re-sign your keys. All keys and revocation certificates are attached below. Thanks, --Lucky Green [EMAIL PROTECTED] PGP 5.x encrypted email preferred -BEGIN PGP PUBLIC KEY BLOCK- Version: PGP 6.0.2 mQGiBDWQiBgRBADJwLlQtkItsKyuamvqoxyPANvikC1nt7Ek2WxiNWNpr6nRS7Ot qodDu7o+dhq6LvJWnL/opLilpjsSMPmBuAIrbPV8JPS+V2E+BbVflO3VlH/Qo3LE RkztVcSIqJ3QoLsPCeYYLjc5ZFXHOal+2MMwSO6nwc38+y2on1t0TWiyaQCg/yA0 Pxsau8z+Spra2RRSnOR9VisD/jDGqzuViNY7cmPt4KejV0n1NFMbaTUv7i26rMOO LqoRnud5M0ZcPAm8RTBhHvdFaLHm6AbpzCgQDeD99qWMjBwYhUcrelh6w99nVSvh jpSQT+m8EiLz00rR3UH8kRqQ9ipEI7EEW1FAO1peilss5Je2kUq6TMrBSYpGbA/2 rwurBADH6RJGjHM5KwMCkIStYVROYThLyJcQkApGGXkFMUIsy6lYdPp31O7J4uSM bUz0mBQb9/grcwAq96bbyi1JUw7WJRn3xaGGd4xvTCxVEiUdu3xMxpL+Jf6lkQW+ T3DQeB6AovLSJqOQv+qckV/qX6eWrSP9dY8LBFbjZCqwWjZ7f4kARgQgEQIABgUC NZCMmwAKCRAkB52TETIZ4VOSAKCYUAwYJpU89NRvvbghnEyCWw3wigCgk9E9C17P zrSV9WwHc1qH5BQirPO0IUx1Y2t5IEdyZWVuIDxzaGFtcm9ja0BuZXRjb20uY29t PokAUAQQEQIAEAUCNZCIGAUJAPvOgAMLAgEACgkQJAedkxEyGeFaBQCgzZy7Svxu pzKzK5B32EmZBKNNFn4AoP06vAH36OBeGCH7QWZk2hPX1jVBiQBGBBARAgAGBQI1 kInSAAoJEIlxn6e2Y7D9S/EAn2pBIvYLPMeiJ18pv85EohnwR0s7AKCZcLM861uR isP4BxgO1TG8v+OPvbkCDQQ1kIkcEAgA03r+Ikq3akOWRNVaVLrHV08LE/QYUDWi aG0SLDyl6twSJe7a6ixVi0HrccP9djDjbHiQbFnnm22oP/eFr3FMypt9Kdf8sg8t 6PIKP8cAYGONx9ekdcNuopGm/Dag0fLHRprP4uwDsxfXX3o/lvT9wuqeXwQulSoP TlOjcWhmP1fDbD5oz7teWcKjgUI/GlkHNaNuZtIkd8cXsBn196b6xdydCCdzA2wz qg4ZVkT7B4J5/IJGiCSD5vqk6oyUH2/X608n0yYTkCbv6FZBR0JMOIX/PqLMS9VG qaNBzrWg05xQgTr4oaWPH+f+VcpkWjmrpjEL+w+e4PfPtOsl/XmyEwACAggA0ccR gHdvLXUivrGz3Y/MX/Y+tMIAga5Ia9FaRDgYb18fkg+tBWlv5ZolpUOoMd6CwJsO hDyE9hH3+zwVSJAQTk6/tHRzoiNvrCLd0+p0vBLaXQp2vL3Vud0yTlG8Xr/LlAkB SA7zthYy1pUpSmLJCJjLRBH4o/RD/aNaVX3NyxL4cIEHQ+IL0uOUGgJ8cY3mQXU9 TaL9jVT51aeXY3gaNgH48EQG1HZYn3e40ee2QhfPvRDGHvJ8aoRUMlw+llFw97Qx mXNuaw8e8AuW1IBL65YUdh0Lb+XHagj3FR6ugKlhYMJnH/TVwpT7XGivLz/URQ1g x2djMPFfOvPnaiKJq4kATAQYEQIADAUCNZCJHAUJAPvOgAAKCRAkB52TETIZ4RRc AJ4ymFHTeHgk8XBQUzSz0wMxBRGI6QCgtT9ZYrM0kex6Fb9ednlnr0Obsy2ZAaIE NDUowREEAPMTDdtd5Ya3u7tVxg9i2JeY6wSSA3jwEHYNsLj4jSh6lI2XrBuO3YnX b3iwVrgc6nGgenWf7EJw/lKlc9Zb3gL/6/d4qWOaP6fVqZaeySZchRymyEVPOfdu DK8kWS76SYhkCVWjuq8IpvwC+yPN6yEqVQQiYBPOczyKLaBEU7d3AKD/t16VwzPk 6ZSL2MxARQUJl8NC8wP+MP7zW6JmCGnULVZGm6mzATbcwsgaYV/IcHOXOWZ3cgPw /rBXm/WmorcSUaLMUZsUgF2ugFzaa7SnHugxTAN5WkvHD1RiAyRrQtNdkQkEkYWR PzOFwbueVkYM87ji4gbKvyu5LhPpOSAg3Kn86/vd9ZsAJ1FPHuyu8qyrr0l6WscE ANl5H069Tgxy2+qlXCmPDhBzR5fEhtL9JsUZyge7J7RNc4AJy4j3I4rPaDOBYkeZ /cxatDmny9V2M2HDzqWngQnCdSPsfbmst9hq1wPv5Uv1TkG9uJhmCLrFKnG9sADK G8IohpgJ6HeGJe+wleOYNKybPylIbOn62L5VFrdcZ4XRtCVMdWNreSBHcmVlbiA8 c2hhbXJvY2tAY3lwaGVycHVua3MudG8+iQCVAwUQNDWlpgSQkem38rwFAQFYgQP/ Z9J+5wuGqTR9XuHjMHBFYTcxiUV0bHvZBFxnox+ncJKqAQSGzvZlTE+eW9+Gz5oa lrV9/h6Xgfxa3B9BSEI2bn3ixSByXaUFCGRB6hKnVJUX+I56lQo8ykhE9sZlF2Jf 8cTrPVbWMK6iNVBtXKv2gtYpIfItUeWJnPfSjm0y9HyJAD8DBRA0NaXSiXGfp7Zj sP0RAkWqAJ9EM/ckLF8pw9JGHy7nl/msyJuNDgCfVXk/0CiDJkECNYL4coK8yfSv NqOJAEsEEBECAAsFAjQ1KMEECwMBAgAKCRD11D08N1rZJAV/AKC9x2mNM6sJLOlO jRcxadr/BsEw6QCfRTJB9Eq4htQSRTTzlQundXG6FWyJARUDBRA0Qee3/fukxZQk WWEBAZz3B/9OU9Lh7UXaVWwDReX5ITNPPZfdUQbfzFBF4nGqiAxIK3rxa+wdizzW Tv4djE7169W8gR4BBBaxDMQgbzTdUitHiqWlMqiKPBhWh8qETdA4rTSSiU/zERZF sUD8aS88jVaBMTsXP5su5qGdShfrEE0RZw7Rny2f+L0UUd/RQU9juowSLxzD2o34 /istRD0GzehVX9+uizYEPpQFB7aUz4m/Y2YiB2VJOfUICW5jW4sNCEUuWosDCm0n 2l0aD6nrFyLeeyMtPsySOojpihPmGDAl4GGPd0PjKkbnf3CxIQGxWuz7K2K+D3Vx 2fo2VR4tVPFfyfz/vDvTufWBFdSh8DeJiQBGBBARAgAGBQI04FtxAAoJEIZ6Ge3m AqlzZ0kAnAuOvnTAFLqhyuXRgWxODOGtnOv+AKClSRNN5g9g8cdsG05ztPKlFlI6 XokBFQMFEDTC3Lxems3hxKju8QEBynIH/iG0orwTqrJYylnAhlXzCixSv6UyEaqq kjxU18hIWwC7iXbiSFjVTxoHFiU978iYt0fGQ5AxJROyPENplaQZZjM/IlysFLa6 yZOnckhD2oGhCytGcdBYqnnYPUq2AADh13rtaGaZmtCFlADaZHLfzkfS7qxPlq34 R6+JNU8f6DTbPtljwaXES8lzMKdGnBsDovHH4bEFq/ax+1RkIf2KW6HlPxUso5ai pZ2TvbTTfrzXwhk8q87Rh+uDyUl4h+AXSbU8px+5CtQfBg544MpU7yulkHmfix7O XAWpeG4Fm0p0/MUttxyBvIUN8u5HVnhCqNDD0Md9KJvXXwEE3Z2/reiJAEYEEBEC AAYFAjTFBLoACgkQYVtoHyxUyPo9dwCfSVkt2vcVKXu1P15qH3jrbghYA9IAn3bA iCtfGEVMkN4ZKB718Byb+amTiQA/AwUQNPX7FNZgKT/Hvj9iEQKytwCeJ7ZNuUaN riO2DZE8d4RQZhrvLyMAnjbNeuwETjYksR/k5wOcaii09xOCiQA/AwUQNV+1q657 ghv7r15EEQIakQCfWtHgJI6n4ry84F+SUCIG2Cfg48QAnRE8ALOjw3peOPCGD8y0 iOmDoR5tiQBGBBARAgAGBQI1G6EeAAoJECnxUHVGkUBmsC8AoNEMK7J/AQNf+HDm
DigiCash Update, part II
As some of you may be aware of, I am involved with an effort to acquire DigiCash. Allow me therefore to suggest that now is not a good time to attempt to purchase a patent license directly from DigiCash. You would most likely be paying too much. DigiCash has for months now attempted to find a buyer for the company's assets. Due to the expectations on the value of the assets, and differences between this and the offers they've received, the board has turned down these offers, including the first offer by my group. Ultimately, the differences between some of the high expectations the board has, and the actual offers they are receiving will be worked out between higher offers and lower expectations. Until then, DigiCash operates on a post-bankruptcy filing bridge loan. This loan won't last forever. Ultimately, DigiCash will be sold. But nobody wants to wait forever. Not you, not me, not the DigiCash board. The faster DigiCash gets sold to our group, the faster the technology will become available to all interested parties under low cost (and in many cases free) licensing terms. Even if DigiCash should now be willing to sell licenses to generate cash flow or reorganize in some new plan and forestall the inevitable sales of assets a little bit longer, the current DigiCash is unlikely to make the licenses available for as low of a cost as our group will make them available after an acquisition of DigiCash. We are in a position to offer potentially significant cost minimization to any prospective licensee of DigiCash IP. With every additional party committing to our effort, we can reduce the cost per license. Scott of course would be amiss of his fiduciary duty would he not attempt to maximize the financial return to DigiCash. We have no such constraint. I have a lot of respect for Scott and he is trying to do what is best for the DigiCash shareholders and debtholders (As he should). We on the other hand are more focused on what is best for the technology, to ensure it is deployed widely and in all it's various potential uses. The more serious parties join our effort, the faster will we be able to make another bid and the faster the DigiCash board will review and hopefully approve our next offer. Ultimately, everybody will be happy. The creditors will be happy since they get their money, the current executive group at DigiCash will be happy to move on having successfully found a palatable deal, and the licensees will be happy, since they will be able to obtain the IP and options for support and technology development instead of being held in limbo with the present DigiCash situation. And of course the developer community will be happy, since the patents will be available to all, not just to the few to which DigiCash might license the patents to improve their unfortunate cash flow situation. This broad availability will allow the market to validate the technology. No single player, or even small group of players, can make eCash a success. Only an aggressive push by many large, small and medium sized players who are all deploying eCash and blinded private payment systems can. This is one of the many reasons our group has the support of several of the larger banks in the world, banking software/EDI vendors, credit card clearing houses, personal financial/cryptography software vendors, global media corporations, and other players that are required to make eCash and other DigiCash IP derived technologies ubiquitous. Feel free to contact DigiCash directly if you must. We certainly encourage people who are interested in exclusive ownership of the DigiCash IP, and are not interested in opening up the patents or technology to deal directly with them since this is contrary to our goal. But if you are interested in any one part, one use or application or even in all of the parts in a non-exclusive way please make sure to email me first as I believe it will benefit everyone for a lot less money. --Lucky Green [EMAIL PROTECTED] I will soon revoke my PGP key 0x375AD924 for administrative reasons.
