Re: Russia Intercepts US Military Communications?
Eric Rescorla wrote: Sent: Monday, March 31, 2003 23:42 To: John Gilmore Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Russia Intercepts US Military Communications? John Gilmore [EMAIL PROTECTED] writes: Remember, the cypherpunks ... secured any Web traffic Credit where it's due. Netscape was responsible for this. Just for the record, SSLv1 first saw significant review, if it was not first posted to, the Cypherpunks mailing list. Those who participated in the list at the time may remember Mark Andreessen, a Cypherpunks newbie in those days, proudly posting his new crypto protocol. The protocol received the customary reception security protocols designed by crypto newbies tend to receive: it was torn to shreds immediately. SSLv2 rapidly superceded SSLv1. SSLv2 in turn was implemented throughout Netscape's products by the Weinstein brothers, which during those days were very active participants in both the Cypherpunks mailing list and Cypherpunks meetings. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Microsoft: Palladium will not limit what you can run
AARG!, having burned the nym with the moderator of this list and who is therefore now posting via the Hermes remailer commented on Microsoft, which similarly burned the Palladium name, claims: Hopefully this will shed light on the frequent claims that Palladium will limit what programs people can run, or take over root on your computer, and similar statements by people who ought to know better. It is too much to expect these experts to publicly revise their opinions, but perhaps going forward they can begin gradually to bring their claims into line with reality. Part of me wonders if it worth my time to reply to this post, but what the heck, I'll take it. So let's talk about reality. It is true, at least for the moment, that Intel's La Grande initiative, which provides the hardware foundation for Palladium, just locks pages in memory that are designate as such by the application. It if further true that Palladium, as the aforementioned OS component, just designates certain blobs of data to be inaccessible to the user who has Ring 0 privileges. Whether Palladium takes over root on a computer or merely prevents the legitimate purchaser of a PC who otherwise has required privileges from performing certain actions on the PC that he legally owns with the data he lawfully created may be a matter of philosophical debate. For conciseness and clarity it suffices to say that the owner of a PC will not have root privileges on a PC on which Palladium is active and in force. No Microsoft press release can possibly alter this fact, since this restriction is fundamental to Palladium having any value at all to any entities. As Microsoft's John Manferdelli wrote: How these new programs are built - and what they will require of the user - are questions for the application developer to answer. What John means is that Palladium in and by itself will not limit what applications you can run. Which is mostly true for the first phase. But if, in addition to Palladium, you would like to run application by vendors concerned about law-abiding, but undesirable, information flow, then you will find that the applications that you would like to run in addition to the above won't perform as expected. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Matt wrote quoting John: Do you really, honestly believe that none of the people designing a secure communication system for the shuttle were even remotely acquainted with the basic principles of the subject? [...] Apparently some folks skipped class the day Kerchhoffs' Principle was covered. One wonders what other shuttle systems were designed with comparable disregard of basic principles. Matt, Based on my experience, I would not be unreasonable to believe that such a disregard to basic security principles indeed took place. Case in point: In July of 1997, only days after the Mars Pathfinder mission and its Sojourner Rover successfully landed on Mars, I innocently inquired on the Cypherpunks mailing list if any subscribers happened to know if and how NASA authenticates the command uplink to what at the time was arguably the coolest RC toy in the solar system. A few days after my initial post, which yielded no substantial replies on the mailing list, I receive a call by a well-known security expert who at that time functioned as an advisor to the office of the President of the United States. Apparently, my original inquiry had been copied and forwarded several times. By the time my inquiry had reached the office of the President, just as in a children's' game of telephone, my question of are they using any decent crypto had turned in to hackers ready to take over Mars Rover. With Sojourner being the U.S. Government's PR darling of the day, the office of the President decided to dispatch the FBI to interdict me from engaging in such a nefarious deed. It was only through chance that the aforementioned advisor got wind of this releasing of the hounds and convinced the decision makers that I was just a harmless researcher who asked an innocent question rather than a threat to national PR objectives. Word has it that the folks in DC were buzzing with fear of what would happen to NASA's image if hackers were to take the Mars Rover for a spin. Needless to say and regardless of anyone's intent, such concern would be entirely unfounded if the uplink were securely authenticated. Which I believes represents an answer to my initial question as to whether the uplink is securely authenticated. Presumably NASA did a better job with the shuttle, but I would not be surprised in the least if all shuttles shared the same key. [Remind me to some time recount the tale of my discussing key management with the chief-cryptographer for a battlefield communication system considerably younger than the shuttle fleet. Appalling does not being to describe it]. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: EU Privacy Authorities Seek Changes in Microsoft 'Passport'
Rich Salz wrote: Liberty is architected to be federated, unlike Passport. The Liberty Alliance was stillborn to begin with. Not that it made any practical difference, but the Liberty Alliance received an additional bullet through the head the day that RSA Security, a key participant in the Liberty Alliance, announced that they would also support Microsoft Passport. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: PGPfreeware 8.0: Not so good news for crypto newcomers
Nicko wrote: I think this comes down to a classic time/money tradeoff. PGP 8.0 Personal edition is currently priced at $39. Even as an experienced Unix and PGP user I think that the GUI on PGP 8.0 will save me an hour of effort over the lifetime of the product, which means it saves me money in the long run. I found PGP 8.0 to be well-designed and easy to use. If all one has is time, the calculation might turn out different, but if one values ones time and likes to use PGP without hassles, I would recommend spending the money on a copy. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RSA's RC5-64 Secret Key Challenge has been solved.
John wrote: After getting that getting started, though, I suggest beginning a brute-force attack on the GSM cellphone encryption algorithm. That's in use in hundreds of millions of devices worldwide, protecting (or failing to protect) the privacy of billions of phone calls a day. According to the GSM Association's website there are currently 732 million GSM users world-wide. Still, I suspect that unlike RC5 and DES, GSM's two voice privacy algorithms A5/1 and A5/2 might not be the best candidates for brute force distributed key searches since the algorithms were badly designed, are fundamentally broken, and thus are subject to very efficient cryptanalytical attacks with work factors well below the 64-bit key space nominally utilized by GSM. A5/2, the weaker of the two algorithms, can be broken in real-time on a single, low-end, Pentium class computer. A5/1, the stronger of the two algorithms, falls to a near real-time attack on computing hardware far from bleeding edge, but the attack as published requires a 2^48 preprocessing stage. That table could be generated by a distributed effort. http://cryptome.org/a51-bsw.htm Unfortunately, the greatest challenge in publicly demonstrating the insecurity of GSM and other civilian wireless communication protocols lies not in breaking the compromised crypto, but in obtaining the required RF and signal processing equipment. Full-featured equipment is priced with governmental customers in mind and difficult to obtain. Commercial-grade interception hardware usually lacks cryptanalytical features. Software defined radios would be well-suited to task, but those who expended the effort of writing software-defined cellular telephony modules so far understandably chose to sell the fruits of their labor to paying customers rather than releasing the code as Open Source. Until the required equipment becomes readily available to the public, the interested parties likely will continue to make the same outrageous claims they made in the past, such as that GSM is secure against eavesdroppers irrespective of how weak the ciphers have been shown to be since the GSM signal itself cannot be intercepted... Lastly, while a publicly available A5/1 precomputation table would likely be of interest to researchers, myself included, anybody considering creating that table may wish to inquire with competent legal counsel as to the legality of performing this research in the U.S. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Challenge to TCPA/Palladium detractors
Anonymous wrote: Matt Crawford replied: Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Utilizing Palladium against software piracy
I would like to again thank the Palladium team, in particular Peter Biddle, for participating in yesterday's panel at the USENIX Security conference on Palladium and TCPA. Unfortunately I do not have the time at the moment to write up the many valuable and informative points made during the panel discussion. I will, however, highlight one such issue: As Peter pointed out, while the Palladium effort was started to meet the content protection requirements of digital video content providers, he also pointed out that Microsoft and its Palladium group have so far been unable to determine a method in which Palladium could be utilized to assist in the efforts against application software piracy. As Peter mentioned, the Palladium team on several occasions had to tell the Microsoft's anti-piracy group that Palladium is unsuitable to assist in software (as distinct from content) licensing and anti-piracy efforts. Since Microsoft is not aware of a method to utilize the Palladium environment in the enforcement of software licenses, Peter argued, Microsoft does not intend to and will not utilize Palladium to assist in the enforcement of software licensing. I, on the other hand, am able to think of several methods in which Palladium or operating systems built on top of TCPA can be used to assist in the enforcement of software licenses and the fight against software piracy. I therefore, over the course of the night, wrote - and my patent agent filed with the USPTO earlier today - an application for an US Patent covering numerous methods by which software applications can be protected against software piracy on a platform offering the features that are slated to be provided by Palladium. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
Enzo wrote quoting Lucky: The cert shows as being issued by Equifax because Geotrust purchased Equifax's root embedded in major browsers since MSIE 5 on the secondary market. (Geotrust purchased more than just the root). This raises an interesting legal issue. Should any loss from a mis-issued cert arise to a party who trusted the Equifax brand name shown in the cert chain, but doesn't know (or want to know) anything about Geotrust, who would be liable? (Yeah, I know, any liability is usually disclaimed away, but I mean: which one of the two is supposed to represent the trusted thirt party?) I suspect that until there is more case law related to digital certificates, this question will be very challenging to answer. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
RJ Harvey wrote: Thanks for the tip! I just got a new cert from Geotrust, and it was such an amazing contrast to those I've gotten from Verisign and Thawte! They apparently take the verification info from the whois data on the site, and you really can do the process from start to finish in 10 minutes or so. I believe that Geotrust has come up with an excellent new model to make money out of the CA business with minimum hassle to the customer while reducing Geotrust's vetting costs down to next to zero. Their introduction of this new model was one of the more interesting news at this year's otherwise rather bland RSA Conference. The cert shows that it's issued by Equifax, however. The cert shows as being issued by Equifax because Geotrust purchased Equifax's root embedded in major browsers since MSIE 5 on the secondary market. (Geotrust purchased more than just the root). --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
James wrote: On 11 Jul 2002 at 1:22, Lucky Green wrote: Trusted roots have long been bought and sold on the secondary market as any other commodity. For surprisingly low amounts, you too can own a trusted root that comes pre-installed in 95% of all web browsers deployed. How much, typically? I'd rather not state the exact figures. A search of SEC filings may or may not turn up further details. And who actually owns these numerous trusted roots? I am not sure I understand the question. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
TPM cost constraint [was: RE: Revenge of the WAVEoid]
Bill wrote: At 10:07 PM 06/26/2002 -0700, Lucky Green wrote: An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. Compared to the cost of rewriting Windows to have a infrastructure that can support real security? Maybe, but I'm inclined to doubt it, especially since most of the functions that an off-CPU security co-processor can successfully perform are low enough performance that they could be done on a PCI or PCMCIA card, without requiring motherboard space. Upon re-reading the paragraph I wrote, I can see how the text might have been ambiguous. I was trying to express that there was a cost constraint on the part. Adding the cost of an EMBASSY or SEE environment to the purchase of every new PC is more than the market for bare-bones or even mid-range PC's will bear. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Wild and Crazy: Interview with Palladium's Mario Juarez
pasward writes: In other words, when the MB is fried because of some freak electrical surge, I'm screwed, because I can't put the HD into another machine and get the data off it? You will probably need to re-install the OS from CDROM on the new machine. Which shouldn't be a big problem, since chances are that you didn't do a large amount of customization on the 3DES encrypted OS binary, anyway. As for your application data, you typically should be able to go back to the application vendor, assuming your maintenance license is current, to have the vendor re-bind your data file encryption keys to the new TPM. I am not aware of any such plans for non-user generated data, such as purchased entertainment content, but then requiring the user to repurchase such data when changing motherboards is not incompatible with the content providers' business models. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Two additional TCPA/Palladium plays
to a court order, as might be given if the author of the document were to distribute DeCSS v3 or Scientology scriptures in the future DRM protected format. All that is required to perform such an administrative invalidation of a document is either a sample copy of the document from which one can obtain its globally unique ID, the serial number of the application that created the document, or the public key of the person who licensed the application. (Other ways to exist but are omitted in the interest of brevity). --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Revenge of the WAVEoids: Palladium Clues May Lie In AMD Motherboard Design
Bob wrote quoting Mark Hachman: The whitepaper can not be considered a roadmap to the design of a Palladium-enabled PC, although it is one practical solution. The whitepaper was written at around the time the Trusted Computing Platform Association (TCPA) was formed in the fall of 2000; both Wave and AMD belong to the TCPA. And, while Palladium uses some form of CPU-level processing of security algorithms, the AMD-Wave whitepaper's example seems wholly tied to an off-chip security processor, the EMBASSY. An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. I am not asserting that security solutions that require special-purpose CPU functionality are not in the queue, they very much are, but not in the first phase. This level of functionality has been deferred to a second phase in which security processing functionality can be moved into the core CPU, since a second CPU-like part is unjustifiable from a cost perspective. Given the length of CPU design cycles and the massive cost of architecting new functionality into a processor as complex as a modern CPU, we may or may not see this functionality shipping. Much depends on how well phase 1 of the TCPA effort fares. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: DRMs vs internet privacy (Re: Ross's TCPA paper)
Adam Back wrote: I don't mean that you would necessarily have to correlate your viewing habits with your TrueName for DRM systems. Though that is mostly (exclusively?) the case for current deployed (or at least implemented with a view of attempting commercial deployment) copy-mark (fingerprint) systems, there are a number of approaches which have been suggested, or could be used to have viewing privacy. The TCPA specs were carefully designed to permit the user to obtain multiple certificates from multiple CA's and thus, if, and that's a big if, the CA's don't collude and furthermore indeed discard the true name identities of the customer, utilize multiple separate identities for various online applications. I.e., the user could have one cert for their True Name, one used to enable Microsoft Office, and one to authenticate the user to other online services. It is very much the intent of the TCPA to permit the use of pseudonymous credentials for many, if not most, applications. Otherwise, the TCPA's carefully planned attempts at winning over the online liberty groups would have been doomed from the start. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Ross's TCPA paper
David wrote: It's not clear that enabling anti-competitive behavior is good for society. After all, there's a reason we have anti-trust law. Ross Anderson's point -- and it seems to me it's one worth considering -- is that, if there are potentially harmful effects that come with the beneficial effects, maybe we should think about them in advance. I fully agree that the TCPA's efforts offer potentially beneficial effects. Assuming the TPM has not been compromised, the TPM should enable to detect if interested parties have replaced you NIC with the rarer, but not unheard of, variant that ships out the contents of your operating RAM via DMA and IP padding outside the abilities of your OS to detect. However, enabling platform security, as much as might be stressed otherwise by the stakeholders, has never been the motive behind the TCPA. The motive has been DRM. Does this mean that one should ignore the benefits that TCPA might bring? Of course not. But it does mean that one should carefully weigh the benefits against the risks. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Ross's TCPA paper
Mike wrote quoting Lucky: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. I don't see how they expect this to work. We've already got cheap rip off motherboards, who's gonna stop cheap rip off TPM's that ain't really T? I think it moves the game into a smaller field where the players all have some bucks to begin with, but somebody will create a TPM that looks like the real thing, but runs cypherpunk code just fine. I agree with your assertion that TPM's can't prevent DRM from being broken. Nor is this the intent of introducing TPM's. The vendors have realized that they have to raise the technical bar only so high to keep those most inclined to break their systems (i.e. 16-year old Norwegians) from doing so. Those that have the knowledge and resources to break TCPA systems either won't have the time because they are engaged in gainful employment, won't be willing to take the risk, because they have accumulated sufficient material possessions to be unwilling to risk losing their possessions, not to mention their freedom, in litigation, or will break the security for their own gain, but won't release the crack to the public. Criminal enterprise falls into the latter category. The content vendors, which in this case includes the operating system and application vendors, dislike, but can live with, major criminal enterprise being the only other party to have unfettered access, since criminal enterprise is just another competitor in the market place. Most business models can survive another competitor. Where business models threaten to collapse is when the marginal cost of an illegal copy goes to zero and the public at large can obtain your goods without payment. I don't know if the TCPA's efforts will prevent this, but in the process of trying to achieve this objective, the average computers users, and even many advanced computer users, will find themselves in a new relationship with their PC: that of a pure consumer, with only the choices available to them the what the 180 TCPA's members digital signatures permit. Cloning TPM's is difficult, though not impossible. Note that all TPM's unique initial internal device keys are signed at time of manufacture by a derivative of the TCPA master key. Unless you are one of the well-known chipset or BIOS manufacturers, you can't get your TPM products signed. It is theoretically possible, though far from easy, to clone an entire TPM, keys and all. However, the moment those fake TPM's show up in the market place, their keys will simply be listed in the next CRL update. And if your OS and TPM's miss a few CRL updates, your commercial OS and all your applications will stop working. As might in the future your video card, your PCI cards, your hard drive, and your peripherals. You can try to hack around the code in the OS or firmware that performs the checks, as long as you are willing to operate your machine permanently off the Net from then on, because your system will fail the remote integrity checks, but given that this and other security relevant code inside the OS and applications are 3DES encrypted and are only decrypted inside the TPM, you can't just read the object code from disk, but get to first microprobe the decrypted op codes off the bus before taking a debugger to the code. Not a trivial task at today's PC bus speeds. Nor can you get too aggressive with the hacks, since your Fritz may simply flush the keys and leave you with a bunch of 3DES encrypted op codes and no corresponding decryption keys. Reverse engineering turns pretty dim at that point. None of these obstacles are impossible to overcome, but not by Joe Computer User, not by even the most talented 16-year old hacker, and not even by many folks in the field. Sure, I know some that could overcome it, but they may not be willing to do the time for what by then will be a crime. Come to think of it, doing so already is a crime. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Ross's TCPA paper
Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Secure mail relays [was:RE: DOJ proposes US data-rentention law. ]
John wrote quoting Lucky: Locate the button in your MUA that's labeled Use secure connection or something to that effect, search the docs for your MTA for the words STARTTLS, relaying, and potentially SASL, don't use your ISP's smtp server, encourage those that you are communicating with to do the same, and the email data retention laws will be of no bother to you. However, your ISP will cut you off for spamming, by which they mean sending emails toward their destination without going via the ISP's wiretap point, I mean mail relay machine. All you anti-spam bastards wanted ways to control what people are allowed to send you, regardless of the cost in broken protocols, savaged freedoms, and user inconvenience. OK, now you have a bunch of controls, stop whining when they are used to control YOU! (Of course, the spam hasn't stopped coming in anyway, so you get the worst of both worlds.) I share John's dislike for the (thoroughly ineffective, except in making the lives of legitimate users more difficult) anti-spam zealots and anybody else upstream from me that deems it necessary or even acceptable to do anything other than to forward raw IP packets addressed to my IP address unmodified. In fact, I cautioned various anti-spam activists back around 1994/95 where their objectives would lead, but it was to no avail. An experience that John is undoubtedly familiar with. Nonetheless, I would not run an open relay today simply due to the fact that I want the postmaster alias to remain useful for submitting reports of actual mail sub-system problems on my system. And, yes, because I would loath to see cypherpunks.to's very pleasing 100Mbps upstream connection cut. Fortunately, what I am suggesting can be accomplished without running an open relay on port 25, which /will/ cause you pain. I am limiting relaying on port 25 smtp to authorized users by using Cyrus-SASL, which integrates cleanly with postfix + TLS as the MTA. Since Outlook only provides the plaintext variant of SASL authentication, my MTA is configured to not offer smtp AUTH as an option until after the TLS connection has been established to prevent eavesdroppers from capturing the relaying authentication password. Since more and more misguided ISP's are flat out blocking outgoing connections to port 25 from inside their network, I have postfix listening at a higher port number in addition to port 25, just as many hosts today are running sshd on several ports to help compensate for similarly misguided corporate firewall policies. One probably could get away without using SASL just by running the smtpd on a non-standard port, since AFAIK spammers only try port 25, at least at the moment, but enabling SASL was so easy with postfix that I saw little reason not to do so. Besides, it was the more esthetically pleasing solution. John (off the Internet for months now, getting email via uucp, since Verio cut off my T1 for running an open relay, i.e. a box that would accept email like what Lucky proposes) UUCP, eh? Well, having just watched my ISP's primary upstream provider essentially melt down and the replacement likely to do so soon, I had myself briefly considered retrieving my old UUCP books from storage just in case the need should suddenly arise. :-) Hmm, I wonder where one gets an UUCP link nowadays. Guess I should take a look at the current maps. (The following offer is specifically for John: let me know if you'd like a relay and I'll gladly give you an UID/PW for my not-quite-open mail relay. I have little doubt that any and all traffic in and out of that particular machine has been logged since it first came online 7 years ago. I don't care, since any significant traffic is encrypted. YMMV. Oh, and yes, cypherpunks.to of course supports IPSec under both IPv4 and IPv6 in addition to higher-level encryption protocols such as smtp's STARTTLS). --Lucky strong crypto sure has become amazingly inexpensive and easy to use Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Ross's TCPA paper
I recently had a chance to read Ross Anderson's paper on the activities of the TCPA at http://www.cl.cam.ac.uk/ftp/users/rja14/.temp/toulouse.pdf I must confess that after reading the paper I am quite relieved to finally have solid confirmation that at least one other person has realized (outside the authors and proponents of the bill) that the Hollings bill, while failing to mention TCPA anywhere in the text of the bill, was written with the specific technology provided by the TCPA in mind for the purpose of mandating the inclusion of this technology in all future general-purpose computing platforms, now that the technology has been tested, is ready to ship, and the BIOS vendors are on side. Perhaps the Hollings Consumer Broadband and Digital Television Promotion Act bill would be more accurately termed the TCPA Enablement Act. BTW, the module that Ross calls a Fritz in his paper after the author of the bill, long had a name: it is called a Trusted Platform Module (TPM). Granted, in the context of the TCPA and the Hollings bill, the term trusted is used somewhat differently than the customers of future motherboards, which are all slated to include a TPM, might expect: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. The public and the media now need to somehow, preferably soon, arrive at the next stage of realization: the involvement in the TCPA by many companies who's CEO's wrote the widely distributed open letter to the movie studios, telling the studios, or more precisely -- given that it was an open letter -- telling the public, that mandating DRM's in general-purpose computing platforms may not be a good idea, is indicative of one of two possible scenarios: 1) the CEO's of said computer companies are utterly unaware of a major strategic initiative their staff has been diligently executing for about 3 years, in the case of the principals in the TCPA, such as Intel, Compaq, HP, and Microsoft, several years longer. 2) the CEO's wrote this open letter as part of a deliberate good cop, bad cop ploy, feigning opposition to DRM in general computing platforms to pull the wool over the public's eye for hopefully long enough to achieve widespread deployment of the mother of all DRM solution in the market place. I do not know which of the two potential scenarios holds true. However, I believe public debate regarding the massive change in the way users will interact with their future computers due to the efforts of the TCPA and the Hollings bill would be greatly aided by attempts to establish which of the two scenarios is the fact the case. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: DOJ proposes US data-rentention law.
ji wrote: Under this proposed law, will ISPs have to scan *all* SMTP traffic and record the envelope, or only the traffic for which they actually do SMTP forwarding? If the latter is the case, we can simply go back to the original end-to-end SMTP delivery model; no POP/IMAP or any of that stuff. If the former is the case, well, so long as they don't outlaw crypto, ISPs can't sniff SMTP going over IPsec, now, can they? IPSec is one solution, though I believe an easier way to deal with the recent email data retention proposals in the US (and already existing legislation in the EU) is the following: Locate the button in your MUA that's labeled Use secure connection or something to that effect, search the docs for your MTA for the words STARTTLS, relaying, and potentially SASL, don't use your ISP's smtp server, encourage those that you are communicating with to do the same, and the email data retention laws will be of no bother to you. Anybody that's using postfix as their MTA is welcome to contact me for more detailed instructions, though the above general instructions will work for any decent modern MUA/MTA. Check my mail headers for an example of what I mean. --Lucky tap as much of my 3DES encrypted traffic as you desire Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Shortcut digital signature verification failure
Bill wrote: I have been thinking about how to limit denial of service attacks on a server which will have to verify signatures on certain transactions. It seems that an attacker can just send random (or even not so random) data for the signature and force the server to perform extensive processing just to reject the transaction. If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. This might result in a better balance between the resources needed by the attacker and those needed by the server. Neat idea. So neat in fact that RSA Security has a patent on it. :-) Sorry, I don't have the patent number handy. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Lucky's 1024-bit post [was: RE: objectivity and factoring analysis]
Enzo wrote: Further to Lucky's comments: in the last few days I have discussed keysize issues with a few people on a couple of mailing lists, and I have encountered a hostility to large keysizes of which, frankly, I don't understand the reasons. On the client side at least, performance is not an issue: PGP 7.0.3 with my new 4096-bit PGP key appears to be as snappy as it was with 1024-bit keys, and the table at http://www.mccune.cc/PGPpage2.htm#Speed looks quite reassuring. In particular, none of the naysayers explained me clearly why it should be reasonable to use 256-bit ciphers like AES with 1024-bit PK keypairs. Allow me to shed at least some light on the strange phenomenon that you experienced for I have experienced the same phenomenon and was able to glean at least a few of the reasons why application authors and maintainers have proven so reluctant to increase RSA key sizes or mandate minimum key sizes in their applications. 1) Very, very few applications, and no cryptographic libraries that I am aware of, that currently employ RSA perform any kind of sanity check on the size of the keys. The current release version of various programs that I looked at will happily accept a 4-bit RSA client key that anyone could factor in their head. VeriSign not too long ago signed a 384-bit SSL server key that may readers of this list could break with the old computers in their home. Such certificate signing practices, or their lack thereof, are nothing short of irresponsible. I have not tested the following hypothesis and am not willing to spend the required $125 on the experiment, but I would not be in the least surprised if many public CA's would readily sign a certificate for a 4-bit RSA key. C.f. the being caught with one's pants down observation in my previous post. If somebody want to perform this experiment, better do it quick, since the CA vendors read this mailing list. :-) There are some positive examples: as a result of my original post, the next release version of OpenSSH will enforce a 768-bit minimum size on the key. I have not been following the discussion that lead to the determination of this figure and therefore don't know on which cryptological results the OpenSSH designers based that number. However, I note that even those experts that I am aware of which assert that 1024-bit keys are sufficient for the type of long-term use SSH client keys are frequently employed for do not appear to claim that 768-bit keys should be considered secure today. Unfortunately, the OpenSSH designers have chosen to not expose the minimum key size requirement via the sshd configuration file, though at least there now there will be a known spot in the source that can easily be patched to a value the server operator might consider to be more in line with current key size recommendations. I thank the OpenSSH team for at least providing an easy hook to make the desired changes in the source, though of course I would like to see both a larger default and a corresponding option in the config file. Still, hats off to the OpenSSH team for moving implementing sanity checks that few other vendors have bothered to implement. Some other deployed applications either use libraries that can't go higher than 1024-bits or have the key sizes and structures hard coded all over the source, making a chance expensive and uneconomical absent severe customer pressure on the vendor. A much cheaper solution than rewriting good chunks of the core crypto processing code (or worse, having to upgrade hardware that is limited to 1024-bits) is putting out a press release stating why the customer doesn't need keys larger than 1024-bits, which some claim is one of the many reason why there is so much resistance to moving to larger keys. I am not quite ready to subscribe to such cynical a view point, but I heard that view point voiced by several crypto old-timers in private conversations more than once. 2) One frequently voiced argument against increasing key sizes is the resultant decrease in performance. Yes, it is absolutely true that increasing the size of an RSA key leads to a decrease in performance. However, larger keys decrease performance less than naive experiments may seem to indicate. For many applications, generating a 2048-bit key and comparing the performance with that of a 1024-bit key will lead to numbers that differ widely, much more so than can be attributed to the larger key size. The reason for this phenomenon is that RSA algorithm performance is highly dependent on optimizations that are both key size and processor specific. The same optimization strategy that will give you blazingly fast performance with a 1024-bit key will absolute kill performance with a 4096-bit key, for which a different optimization strategy is needed. Similarly, optimizations are highly processor specific. An optimization designed specifically for a Pentium III processor will run slower on a Pentium IV than your basic
Lucky's 1024-bit post [was: RE: objectivity and factoring analysis]
Anonymous wrote (quoting Adam): Adam Back wrote: The mocking tone of recent posts about Lucky's call seems quite misplaced given the checkered bias and questionable authority of the above conflicting claims we've seen quoted. No, Lucky made a few big mistakes. First, he invoked Ian Goldberg's name as a source of the estimate, which was wrong. Second, he presented Nicko's estimate as being more authoritative than it actually was, as Nicko makes clear here. And third, he fostered panic by precipitously revoking his key and widely promulgating his sky is falling message. Rather than continuing with guesses by those that were not present at the time as to my motivations and objectives behind my post, allow me to establish the facts and thought processes that lead to my original post. Prior to the panel at FC, I held the belief that 1024-bit RSA keys could not be factored in an operationally significant timeframe irrespective of the budget of the attacker. I know that this belief was held by many, if not most, of the implementers of cryptographic production systems and believe that it was held by many, if not most, cryptographers. In some sense, if this belief had not been held so widely, current debate would not be as heated. So let's look at the supposed mistakes Anonymous asserts I made: 1) As is the case with many panel discussions, and in many cases the reason for choosing a panel format rather than an individual presenter, the panelists, Ian Goldberg and Nicko van Someren, were selected to represent subject matter experts in different areas of relevance to the subject to be discussed: Ian's role was to help determine the mathematical impact and correctness of Bernstein's proposal: are the mathematical assumptions correct? Did the author make a mathematical error in the paper? Ian did not identify errors in the math, though cautioned that the interconnections required by an actual device would represent a challenge of significant engineering impact. (Which, as Nicko addressed in his previous posts to this list, he too considered to be the limiting factor on performance). Having thus established, as well as it could been established at the time, that the paper that triggered the discussion appeared to not contain mathematical errors, Nicko, as the subject matter expert in building cryptographic hardware implementations, presented what the math meant from an engineering perspective. In particular, can a device be built based on the mathematical assumptions, how much would it cost to build such a device, and what would the device's operating characteristics be? It is correct that Nicko presented estimates that literally were being refined during the panel session. Naturally, I would not have even considered posting such hasty generated estimates to a widely-read mailing list. (More on that later). Interestingly enough, the reaction to the estimates from the attendees at the conference, which contained many well-known cryptographers, was quite different from what I would have expected. Nobody stood up, and FC is a conference quite amenable to open discussion, that they found the suggestion that 1024-bit RSA could be broken by a well-resourced attacker in operationally significant times to be unrealistic. The most vocal comment in the ensuing discussion came from Yvo Desmedt, who pointed out that no expert in the field should be surprised by these results, since it was pointed out in Beth, Frisch, and Simmons Public-Key Cryptography: State of the Art and Future Directions, LNCS 578, published in back 1992, ten years ago, that 1024-bit keys would be suitable for protection against a national adversary for about another 10 years: until about 2002. As it so happens, this the year 2002. Given how panels are assembled and the role they fulfill, I thought it would be understood that when one writes that certain results came out of a panel that this does not imply that each panelist performed the same calculations. But rather that that the information gained from a panel (Ian: math appears to be correct, Nicko: if the math is correct, these are the engineering implications of the math) are based on the combined input from the panelists. My apologies if this process of a panel was not understood by all readers and some readers therefore interpreted my post to indicate that both Ian and Nicko performed parallel engineering estimates. 2) Immediately after the panel, a reporter for the Financial Times in attendance approached me, inquiring if these estimates had already been published in the media. I told him that I was not aware of any such publications and that this was the first time I had heard these estimates. He informed me that he intended to publish this information in a matter of days. I don't know if he wrote the article or not; I am not a Financial Times subscriber. It was not until at least a week after FC that I contacted Nicko inquiring if he still believed that his
PGP key server changes [was: RE: 1024-bit RSA keys in danger of compromise]
Enzo wrote: Hmmm... I see that the new 4096-bit super-duper key, besides its own (which doesn't prove much), only bears the signatures of the now revoked -as potentially compromised- old keys 0x375AD924 and 0xEEE8CFF3, plus 0x06757D2D (which turns out to be a 1024-bit DSA key) and 0x50C0FEA7 (a lowly 2048-bit RSA legacy key)... Are you really our Lucky, or the NSA proving our worst fears founded? ;-) Oh, the curse of having to revoke a key that accumulated years of WOT signatures... My new pub key has since acquired a few signatures. You can always get the latest version of my key by fingering [EMAIL PROTECTED] or via LDAP from ldap://pgp.surfnet.nl:11370 (also known as europe.keys.pgp.com, though this alias may not last much longer given that it seems that the canonical PGP keyserver at keyserver.pgp.com appears to already have ceased operations in the wake of NAI placing PGP into maintenance mode. At least I have been unable to connect to that server for several days now. YMMV). No, my new key will not interoperate with PGP 1.0, Bass-O-Matic, or similarly outdated versions of PGP. Readers of this post are discouraged from contacting me to inform me of this fact. I an well aware of it and couldn't care less. Few, if any, programs that I use today would run on the Macintosh DUO 230 on which I generated my first 1024-bit PGP key back when I was an alpha tester for PGP 2.0. Thanks to Moore's Law, my first-ever 1024-bit key took a hell of a lot longer to generate on what was then a brand new machine than it took to generate my new 4096-bit PGP key on the old K6-333 that I used a few days ago to generated not only my new PGP key, but various 4096-bit SSH keys for good measure. My suggestion would be to use the time saved by not sending me such an email to upgrade your version of PGP instead. The key has been tested to work fine with the current release versions of PGP for Windows and Mac as well as GnuPG for UNIX and I presume Windows, though I haven't tested GnuPG on Windows. Those of you that know me are very much encouraged to contact me to verify the fingerprint of my new key. If you have my personal mobile phone number, just call. If you don't, email me for the number. Since I would rather not post it to a public mailing list. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
1024-bit RSA keys in danger of compromise
is not surprising, since many vendor offerings fail to support larger keys. In light of the above, I reluctantly revoked all my personal 1024-bit PGP keys and the large web-of-trust that these keys have acquired over time. The keys should be considered compromised. The revoked keys and my new keys are attached below. --Lucky Green -BEGIN PGP PUBLIC KEY BLOCK- Version: PGP 7.1 Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x! mQGiBDQ1KMERBADzEw3bXeWGt7u7VcYPYtiXmOsEkgN48BB2DbC4+I0oepSNl6wb jt2J1294sFa4HOpxoHp1n+xCcP5SpXPWW94C/+v3eKljmj+n1amWnskmXIUcpshF Tzn3bgyvJFku+kmIZAlVo7qvCKb8AvsjzeshKlUEImATznM8ii2gRFO3dwCg/7de lcMz5OmUi9jMQEUFCZfDQvMD/jD+81uiZghp1C1WRpupswE23MLIGmFfyHBzlzlm d3ID8P6wV5v1pqK3ElGizFGbFIBdroBc2mu0px7oMUwDeVpLxw9UYgMka0LTXZEJ BJGFkT8zhcG7nlZGDPO44uIGyr8ruS4T6TkgINyp/Ov73fWbACdRTx7srvKsq69J elrHBADZeR9OvU4MctvqpVwpjw4Qc0eXxIbS/SbFGcoHuye0TXOACcuI9yOKz2gz gWJHmf3MWrQ5p8vVdjNhw86lp4EJwnUj7H25rLfYatcD7+VL9U5BvbiYZgi6xSpx vbAAyhvCKIaYCeh3hiXvsJXjmDSsmz8pSGzp+ti+VRa3XGeF0YkAPwMFIDydCmH1 1D08N1rZJBECe5gAn26wiRQO+uM1208FjQLL+xQNue/JAJ46zNHyIaExnFCrQtt/ VFZUSdWpIrQlTHVja3kgR3JlZW4gPHNoYW1yb2NrQGN5cGhlcnB1bmtzLnRvPokA SwQQEQIACwUCNDUowQQLAwECAAoJEPXUPTw3WtkkBX8AoL3HaY0zqwks6U6NFzFp 2v8GwTDpAJ9FMkH0SriG1BJFNPOVC6d1cboVbIkAlQMFEDQ1paYEkJHpt/K8BQEB WIED/2fSfucLhqk0fV7h4zBwRWE3MYlFdGx72QRcZ6Mfp3CSqgEEhs72ZUxPnlvf hs+aGpa1ff4el4H8WtwfQUhCNm594sUgcl2lBQhkQeoSp1SVF/iOepUKPMpIRPbG ZRdiX/HE6z1W1jCuojVQbVyr9oLWKSHyLVHliZz30o5tMvR8iQA/AwUQNDWl0olx n6e2Y7D9EQJFqgCfRDP3JCxfKcPSRh8u55f5rMibjQ4An1V5P9AogyZBAjWC+HKC vMn0rzajiQEVAwUQNEHnt/37pMWUJFlhAQGc9wf/TlPS4e1F2lVsA0Xl+SEzTz2X 3VEG38xQReJxqogMSCt68WvsHYs81k7+HYxO9evVvIEeAQQWsQzEIG803VIrR4ql pTKoijwYVofKhE3QOK00kolP8xEWRbFA/GkvPI1WgTE7Fz+bLuahnUoX6xBNEWcO 0Z8tn/i9FFHf0UFPY7qMEi8cw9qN+P4rLUQ9Bs3oVV/fros2BD6UBQe2lM+Jv2Nm IgdlSTn1CAluY1uLDQhFLlqLAwptJ9pdGg+p6xci3nsjLT7MkjqI6YoT5hgwJeBh j3dD4ypG539wsSEBsVrs+ytivg91cdn6NlUeLVTxX8n8/7w707n1gRXUofA3iYkA RgQQEQIABgUCNOBbcQAKCRCGehnt5gKpc2dJAJwLjr50wBS6ocrl0YFsTgzhrZzr /gCgpUkTTeYPYPHHbBtOc7TypRZSOl6JARUDBRA0wty8XprN4cSo7vEBAcpyB/4h tKK8E6qyWMpZwIZV8wosUr+lMhGqqpI8VNfISFsAu4l24khY1U8aBxYlPe/ImLdH xkOQMSUTsjxDaZWkGWYzPyJcrBS2usmTp3JIQ9qBoQsrRnHQWKp52D1KtgAA4dd6 7WhmmZrQhZQA2mRy385H0u6sT5at+EeviTVPH+g02z7ZY8GlxEvJczCnRpwbA6Lx x+GxBav2sftUZCH9iluh5T8VLKOWoqWdk720036818IZPKvO0Yfrg8lJeIfgF0m1 PKcfuQrUHwYOeODKVO8rpZB5n4sezlwFqXhuBZtKdPzFLbccgbyFDfLuR1Z4QqjQ w9DHfSib118BBN2dv63oiQBGBBARAgAGBQI0xQS6AAoJEGFbaB8sVMj6PXcAn0lZ Ldr3FSl7tT9eah94624IWAPSAJ92wIgrXxhFTJDeGSge9fAcm/mpk4kAPwMFEDT1 +xTWYCk/x74/YhECsrcAnie2TblGja4jtg2RPHeEUGYa7y8jAJ42zXrsBE42JLEf 5OcDnGootPcTgokAPwMFEDVftauue4Ib+69eRBECGpEAn1rR4CSOp+K8vOBfklAi Btgn4OPEAJ0RPACzo8N6Xjjwhg/MtIjpg6EebYkARgQQEQIABgUCNRuhHgAKCRAp 8VB1RpFAZrAvAKDRDCuyfwEDX/hw5j5ioRYlBknAxQCfSwhtJhuuGujC9JRGlqvS okMLspKJAD8DBRA1Y0wlkDMY9wUOyroRAvDGAKD2B/c3lnzfj1aV9huaqqF474TL YgCfcQINLij356NxHq0OU8cXayEwD52JAD8DBRA2EbdDmSJEz0fGxfIRApqRAKDd r6BiqhpZx7+vh/15ClpqboXs5gCZAdzptsQAeHRj9AXVYboBx1QJIbeJAEYEEBEC AAYFAjYGicUACgkQOIzbrnpVcCs19ACgjb0l85Y6RnJImZBJEoge2USBKK8AoJEi 9THemQUsJ9232updxqxwd//DiQBGBBARAgAGBQI2yjkzAAoJEK4MVGrDPt/e/1UA oLA8CTyTSE3T1zXqvB+MS1V0oGJOAJ42jnAYzerUu6f+jvO4XxFuTLjWlIkARgQQ EQIABgUCNso45AAKCRDsTU6t8w7FhYyMAJ4+BYgbjKdrUttYVdHpuGwytjWpAQCf fraiFg4BkzhbL7loY6QV5XixgnaJAD8DBRA2yjkxUBC7hzYSSRERAlkvAJ9iLEzd yPN3NK75IIvMPbgkrxny/ACgr3diRwaFSzdVb0wfmgOQDQ6yrzWJAEYEEBECAAYF AjbKOksACgkQzzXiXv7LrOU3BQCg8tCANqzZZgF2mNZS3iUWfq4CNnIAn1XC9FgT YfyoWdUy9W8KMnJIX7+5iQBGBBARAgAGBQI2yjsUAAoJEMxx1GBG2NPI5roAn2rx ir0baADJuidtj78J4tGs2u+vAJ99h7uQttdoZhkZgqyU612a/zZ6qIkARgQQEQIA BgUCNujeXwAKCRCFB8S80NSux0UDAKCNcl2wY39t+e+Ru9W9jXwI1zOHMwCg9CUk uK8s9N+H2ANkfoCxqkHweUWJARUDBRA26N6D01ThYrym29EBARv/B/4sTLmY3ZCq IWzW+3ghraqeobKcsSsPfC21jUyo99ia/sBQ28uSC5HJHcNonPbDLvjYcV3Evehp in9Rj+HGnug955Lu19PR62viQVqOkljbdIDIaI/ccxSNoEGQRk2lOBapDsqnla6A rcPjiNuCpOM7GHr/vGXlwCktpumFPUGWVZ8SPS9dX2VhNEwmhgpjNcAph2gwz82r U1vvJd2T5wmiGzzDNMpR+7bqcx7KSXGUcT90m22UXmRg0MG6q4ruuOYl3wQtFMY2 P4uHeq/qKAzwIH60drJ0enUo/uyc87cC61znqrKY6/cQnKdBXoqPR69atH6o+UGi 9c7OloyC/LejiQBGBBARAgAGBQI26FWWAAoJEOa/zS8QgaN8omMAoIOBsS3N7Ffp 4p1KkdtPMt1xnPCnAJ9bBqHH21Ibn4/4gaMe96i7eR+f5YkAlQMFEDbpKeGkUJAs CdPmTQEBkVYD/R/f29x2zgFkjnZhlHBzFZko14BA92RlNBHZhSUXMEaNnFeETkK9 XXNOv18kRo37Jj58+lHEFLuaoxFqcmnbKLcG4SzWT2ODOq2GRr/GFoh3AIU8frli vXwsiMxoaDItSpPt+P8ugc1OqL6WTjJ4PSmZ+9jO0Q7AQE74lDxVWtUEiQCVAwUQ NukqAvLlZUzmDiptAQFoBgP7BexRJFpnxYjlDTTPCq5yksQEaY+rtCDzWrR8UyYO BntBjuUVLdaTFqOoxGANoVeFaOyqeswMAs8OsOaXZPGKdlyc4DoF686AJGVuxaDE BnzgNQbdNzSFwrXTsB5V+p0zjTONKH1kvgpVDsTTZFbPSAA1DNKzISNV0ZLrY2JA hi6JAJUDBRA26W5jsLFxg026EJEBAZRzA/94bfWO8ssa0IEXVsCV+3T2p2mtB2mn tmBSMwj2LporcgCjzMgHVGXu67mDvwq39L+OipyDxD26ZnriGMSuQFHp8+qVp85T anNDDV/fjel+KPBdlNKVSQrUPE3qt37b4rAjheb7AjzIAWnpXfmRqG/HQs156aKw jhrH4q6zOJaXMYkARgQQEQIABgUCNwl7AQAKCRA+KCIzXT7WF6g/AKD+sUQk15WT YzXvJYvLaPvvTA18iQCg0/x6ccyEefE9bJGg+MxqEAgjcG6JAEYEEBECAAYFAjdv IVwACgkQz7+ehp5P1tkrlgCffrtHn9POJgk7DBIuyxnigAwNOfwAoINEWxH+idpP FwuKbcvFcWkUut+IiQBGBBARAgAGBQI3ziltAAoJEFIOUY03oJw44fMAn0gJE/a7 Cq
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
Philip, If we can at all fit it into the schedule, IFCA will attempt to offer a colloquium on this topic at FC. Based on the countless calls inquiring about this issue that I received just in the last few days, the customers of financial cryptography are quite concerned about the Bernstein paper, albeit the paper raises a number of open issues that still would need to be investigated before one should assert that the sky is falling. See you all at FC, --Lucky, IFCA President - Original Message - From: Phillip H. Zakas [EMAIL PROTECTED] To: 'bear' [EMAIL PROTECTED] Cc: 'Eugene Leitl' [EMAIL PROTECTED]; 'Cryptography List' [EMAIL PROTECTED] Sent: Monday, February 25, 2002 12:25 PM Subject: RE: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd) -Original Message- From: bear [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 2:49 PM On Thu, 21 Feb 2002, Phillip H. Zakas wrote: On Tue, 5 Feb 2002, Eugene Leitl wrote: But at Crypto last August, Dan Bernstein announced a new design for a machine dedicated to NFS using asymptotically fast algorithms and optimising memory, CPU power and amount of parallelism to minimize Bear Responds: I really want to read this paper; if we don't get to see the actual mathematics, claims like this look incredibly like someone is spreading FUD. Is it available anywhere? The paper is located here: http://cr.yp.to/papers.html I've not evaluated yet but I'm interested in hearing if he received his grant to try it out. Holy shit. The math works. Bernstein has found ways of using additional hardware to eliminate redundancies and inefficiencies which appear in any linear implementation of the Number Field Sieve. We just never noticed that they were inefficiencies and redundancies because we kept thinking in terms of linear implementations. This is probably the biggest news in crypto in the last decade. I'm astonished that it hasn't been louder. It does seem doable and for not very much money. Is anyone attending the Intl. Financial Cryptography Association meeting in Bermuda from March 11-15th? Perhaps we could arrange an informal get-together for this list. Phillip - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP GPG compatibility
On Sat, 9 Feb 2002, Russell Nelson wrote: X-UID: 139934 Werner Koch writes: Things would get much better if a PGP 2 version with support for CAST5 would get more into use. [ etc. ] I know that you're working hard, Werner, but I believe that the recent few years have destroyed the PGP brandname. I think the only worthwhile way forward is to create a cryptographic email standard de novo, which is free of export, trademark, and patent problems. I believe such a standard already exists. It is called S/MIME. Best of all, this email encryption standard is supported out-of-the-box by the overwhelming majority of deployed MUA's in the world. -- Lucky Green [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
FW: FreeSWAN Release 1.93 ships!
While I am too far from the process to offer comment to the contents of the post below, the last paragraph of the post in some bizarre way did help crystallize a thought that I knew had been nagging in the back of my mind for months, perhaps as much of a year, but that I just could not quite bring to the foreground. FreeS/WAN occupies a position very rarely found in efficient markets, such as open source software. While the position is rarely encountered, it can nonetheless exist: I believe that FreeS/WAN is a natural monopoly. Natural monopolies are usually only found in extremely small markets. The economic textbook example is a power company on an island of 50 people. The market size is simply too small to sustain the overhead of two companies, no matter how efficient both companies may become. Therefore, the market doesn't attract competitors, even absent any regulatory market distortions. (Hence the natural in natural monopoly :-) But for whatever reasons, FreeS/WAN has been holding such a natural monopoly position in by far the largest market in which I have ever seen such a beast. I find this fascinating. I wonder if economists will some day study the case to determine what factors brought it about. [I presume somebody other than the FreeS/WAN project may have written a few lines of Linux open source IPSec code, but they aren't competitors in that market any more than a guy walking around with a charged car battery offering service would be a competitor to the power company in the island example]. --Lucky, who simply had to share this revelation. Back to writing Mixmaster remailer code. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Anonymous Sent: Monday, December 10, 2001 7:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FreeSWAN Release 1.93 ships! On Sunday 09 December 2001 07:32 pm, Lucky Green [EMAIL PROTECTED] wrote: The big question is: will FreeS/WAN latest release after some 4 or 5 years of development finally both compile and install cleanly on current versions of Red Hat Linux, FreeS/WAN's purported target platform? The latest releases of both Suse and Mandrake are both able to install kernels with Freeswan already integrated. It's a little newer addition to Mandrake, so you may want to use Suse. Suse makes it easy to set up encrypted file systems and other nice features. The major problem that holds back the development of FreeS/WAN is with its management. [Management that cares more about sitting on its pulpit, than getting useful software into the hands of people.] Unless things have changed recently, they still won't accept contributions from the US. This makes no sense. GPG is shipping with every Linux distribution I know of, and the German's take contributions from the US. The primary kernel developers have been willing to integrate crypto into the kernel since the crypto regs were lowered. It's the policy of no US contributions that's holding back Linux IPSEC. IMHO: If Freeswan had never been created, an alternate, more mature implementation would already exist in the mainline Linux kernel. --Anonymous - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
