Re: $90 for high assurance _versus_ $349 for low assurance
At 9:24 PM + 3/11/05, Ian G wrote: Does anyone have a view on what low and high means in this context? Indeed, what does assurance mean? :-) By what market price, of course. Verisign is more well known to the average schmuck than godaddy is, and, apparently, the average schmuck forks over the ducats accordingly. The fact that they're currently fungible commodities, ungraded ones at that, only makes the pricing outcome more, um, interesting, if, for the moment, okay, not predictable, :-), but, what, apprehendable by common sense, at least in 20-20 ex post facto hindsight? Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: $90 for high assurance _versus_ $349 for low assurance
Does anyone have a view on what low and high means in this context? Indeed, what does assurance mean? Just last week I was trying to figure out what the difference was between a StarterSSL certificate for $35 (lists at $49 but you might as well sign up for the no-commitment reseller price) and a QuickSSL cert for $169. If you look at the bits in the cert, they're nearly identical, both signed by Geotrust's root. As far as the verification they do, QuickSSL sends an e-mail to the domain's contact address (WHOIS or one of the standard domain addresses like webmaster), and if someone clicks through the URL, it's verified. StarterSSL even though it costs less has a previous telephone step where you give them a phone number, they call you, and you have to punch in a code they show you and then record your name. Score so far: QuickSSL 0.001, StarterSSL 0.0015. Both have various documents available with impressive certifications from well-paid accountants, none of which mean anything I can tell. Under some circumstances they might pay back some amount to someone defrauded by a spoofed cert, but if anyone's figured out how to take advantage of this, I'd be amazed. Comodo, who sell an inferior variety of cert with a chained signature (inferior because less software supports it, not because it's any less secure) is slightly more demanding, although I stumped then with abuse.net which isn't incorporated, isn't a DBA, and isn't anything else other than me. I invented some abuse.net stationery and faxed them a letter assuring that I was in fact me, which satisfied them. Back when I had a cert from Thawte, they wanted DUNS numbers which I didn't have, not being incorporated nor doing enough business to get a business credit rating, so they were satisfied with a fax of my county business license, a document which, if I didn't have one, costs $25 to get a real one, or maybe 15 minutes in Photoshop to make a fake one good enough to fool a fax machine. I gather that the fancier certs do more intrusive checking, but I never heard of any that did anything that might make any actual difference, like getting business documents and then checking with the purported issuer to see if they were real or, perish forbid, visiting the nominal location of the business to see if anything is there. So the short answer to what's the difference between a ten dollar cert and a $350 cert is: $340. Next question? Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: comments wanted on gbde
-- I can see no faults in gbde other than that it is too clever by half. The implementor imagined various vaguely imagined complicated attacks, and put in all sorts of overly clever stuff to defeat them. Let us stick with the threat model where the bad guys kick down your door and yank your computer off your desk. If your cleaning lady is out to get you, it is much easier to create software that creates a false and misleading sense of security, than software that stops her. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 20zhgc+C6FrVnrDEgE+FUIJKA13Z121H8ddkFGw7 47zO1ZpoBAYKkTgHoq2eQeHRoHv2heZEvDQGnfFAX - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Colliding X.509 Certificates
Hi Joerg, My concern is not MD5, its SHA-1. I don't see that we can get rid of SHA-1 in certificates in the next 5 years: * None of the alternatives is widely implemented today. * For controlled environments like in-house applications you might be able to switch earlier (0-2 years). * In open environments like inter company S/MIME or public facing SSL servers it will take years before you can assume that people are able to verify non SHA-1 certs. * For CA certificates you'll have to add more years (not to speak about those CA certs with notAfter=2038). From this perspective it makes sense to think about operating a CA with a broken hash function, I believe. * Technically SHA-1 is broken today. * I don't fear that anybody might attack my CA based on the attack known today. * But given the progress in the last year I personally expect the attacks on SHA-1 to get more practical. It makes sense to do a risk analysis, based on a.o. * how critical is the particular application to the business * what threats are there (who might try something bad) * what's the user community (in-house or the entire world or something in between) and then accept a certain residual risk of continuing the use of 'broken' hash functions for some more time. At the same time it is wise to start deploying better hash functions. I hope the Microsofts and Suns and name your favourite software factory of this world are working on this right now. It's clear that this is going to take a long time and cost a lot of money. We're very lucky that the present attacks are still to a large extent theoretical in nature, and do not (yet) lead to realistic attack scenarios (at least we couldn't think of one, and we haven't seen anybody else coming up with one). The main lesson to be learnt here is that we have made our systems too dependent on a few cryptographic primitives only; much more flexibility is needed. One of these days some smart person may come up with a real attack on name your favorite cryptographic primitive, then you cannot afford two years to change your systems. So I still think that the message we should send into the world is to phase out MD5 now, and SHA-1 a.s.a.p. (NIST says: by 2010, that sounds very long to me). If you cannot do that for practical reasons, then that's your risk. When you accept that risk, that's fine with me. Apart from that I've never understood why there are CA certificates with such incredibly long lifetimes. That's simply asking for trouble. A relying party cannot find out from the certificate alone whether it has a twin sister or not. The fact that there is a random-looking serial number doesn't help you there. That is true, and its certainly not nice. But I think the real concern of the relying party is not specifically about certificates with the same hash, its about * the correctness of the contents (name of private key holder etc.) and * the existance of other certificates issued to same key but different name, which might be used to repudiate signatures, e.g. The relying party always needs to trust the CA on those two properties, as the CA can easily issue certs with incorrect conents, it doesn't need hash collisions for that. My question is: Can a CA prevent twin sisters from coming into existance by using my proposed procedure? With current knowledge the answer is: yes. Randomized serial numbers will be sufficient. And indeed: a CA doesn't need hash collisions to do real damage. Grtz, Benne = Technische Universiteit Eindhoven Coding Crypto Groep Faculteit Wiskunde en Informatica Den Dolech 2 Postbus 513 5600 MB Eindhoven kamer HG 9.84 www: http://www.win.tue.nl/~bdeweger = - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: I'll show you mine if you show me, er, mine
James A. Donald said: There seem to be a shitload of protocols, in addition to SPEKE and DH-EKE ... Can anyone suggest a well reviewed, unpatented, protocol that has the desired properties? Unpatented will be your biggest hurdle. I collaborated on the development of a strong password protocol with the explicit goal of having such a protocol that was not patented. For details, see: http://www.usenix.org/events/sec01/full_papers/kaufman/kaufman.pdf But while we got our employers to agree not to patent the algorithm, neither we nor they are willing to defend it against infringement claims by others. (It also has not been extensively reviewed. There is no particular motivation for anyone to do so since its performance is inferior to other schemes and its patent status is uncertain.) Basically, there is no way to establish that any technology is unpatented. The best you can do is hide behind someone with deeper pockets than you do who is doing the same thing. Like hiding behind IBM when using Linux. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ocf-linux-20050315 - Asynchronous Crypto support for linux (fwd from [EMAIL PROTECTED])
From: David McCullough [EMAIL PROTECTED] Subject: ocf-linux-20050315 - Asynchronous Crypto support for linux To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: Andrew Morton [EMAIL PROTECTED], James Morris [EMAIL PROTECTED], Herbert Xu [EMAIL PROTECTED] Date: Tue, 15 Mar 2005 23:36:44 +1000 Hi all, The latest release of ocf-linux (20050315) is available for download from the project page: http://ocf-linux.sourceforge.net/ This release includes the following changes: * Hifn PLL bug fixes * Makefile fixes for 2.6 builds * 2.6.11 and 2.4.29 patches * cleanups for x86 builds OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework (OCF). This port aims to bring full asynchronous HW/SW crypto acceleration to the Linux kernel and applications running under Linux. Results have shown improvements of up to 7 times that of software crypto for bulk crypto throughput using OpenSSL. At this point in time OCF-Linux provides acceleration for OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations with plans to include Random Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org ___ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpeb3Res97Sm.pgp Description: PGP signature
Re: Encryption plugins for gaim
Adam Fields wrote: Given what may or may not be recent ToS changes to the AIM service, I've recently been looking into encryption plugins for gaim. Specifically, I note gaim-otr, authored by Ian G, who's on this list. Just a quick note of clarification, there is a collision in the name Ian G. 4 letters does not a message digest make. Gaim-otr as I understand it is authored by Nikita Borisov and Ian Goldberg [EMAIL PROTECTED]. It can be acquired here: http://www.xelerance.com/mirror/otr/ and here are some other links: http://www.emergentchaos.com/archives/000715.html Just to confuse the issue I also am working on a private instant messaging service which is markedly different, in that I am taking a payment system and reworking it into an IM system: http://www.financialcryptography.com/mt/archives/000379.html But I haven't got around to a download yet. And it's not AIM compatible, as it works through its host payment system. Ian - would you care to share some insights on this? Is it ready for prime time or just a proof-of-concept? Any known issues? Over to Ian G. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: $90 for high assurance _versus_ $349 for low assurance
On Wed, Mar 16, 2005 at 02:23:49AM +1300, Peter Gutmann wrote: Certainly with UIXC it's not worth anything. What is UIXC? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Encryption plugins for gaim
On Mon, Mar 14, 2005 at 01:19:04AM -0500, Adam Fields wrote: Given what may or may not be recent ToS changes to the AIM service, I've recently been looking into encryption plugins for gaim. Specifically, I note gaim-otr, authored by Ian G, who's on this list. Ian - would you care to share some insights on this? Is it ready for prime time or just a proof-of-concept? Any known issues? If you want encryption with authentication, there's the gaim-encryption plugin. I get the feeling gaim-otr is for more specific circumstances. -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpfHgRbHTkPG.pgp Description: PGP signature
Crack in Computer Security Code Raises Red Flag
http://online.wsj.com/article_print/0,,SB111084838291579428,00.html The Wall Street Journal March 15, 2005 PAGE ONE Crack in Computer Security Code Raises Red Flag Obscure but Worrying Flaw Compromises 'Fingerprint' Widely Used on Internet By CHARLES FORELLE Staff Reporter of THE WALL STREET JOURNAL March 15, 2005; Page A1 With worries about online security already at a high pitch, the discovery of a crack in a widely used Internet encryption technique has raised another red flag among government agencies and computer-code experts. The technique, called a hash function, has been used for years by Web-site operators to scramble online transmissions containing credit-card information, Social Security numbers and other sensitive data. Hash functions are at work, for instance, for most of the millions of transactions that take place on the Internet every day. The system, involving an algorithm, or mathematical formula, was thought to be impenetrable. But last month, a team of researchers from Shandong University in eastern China began circulating a draft of a paper showing that a key hash function used in state-of-the-art encryption could be less resistant to an attack by hackers than had been thought. Hash functions generate digital fingerprints, or hashes, of documents or data. As with fingerprints, the uniqueness of the hash is what makes hash functions a great tool for verifying the authenticity of information. But the Chinese team found different pieces of data that yielded the same hash when team members used a hash algorithm called SHA-1 -- and their method generated the identical hash far more efficiently than experts thought possible. SHA-1 is a federal standard promulgated by the National Institute of Standards and Technology and used by the government and private sector for handling sensitive information. It is thought to be the most widely used hash function, and it is regarded as the state of the art. Cryptographers say exploiting the flaw for malevolent purposes doesn't seem practical, even using a lot of computer power. Hash functions are also often used in conjunction with other cryptographic techniques, which haven't shown any flaws. But if someone were to exploit the newfound flaw, the most immediate threat would be to applications involving authentication. A hacker theoretically could set up a dummy Web site that appears to have the security credentials of a trusted, secure site -- and then steal data that is shipped to this site by unsuspecting users. Despite what are believed to be remote chances of abuse, the discovery has set off alarms in the computer-security industry because it overturns a bedrock belief about a popular encryption system. Our heads have been spun around, says Jon Callas, chief technology officer at encryption supplier PGP Corp. of Palo Alto, Calif. Everything is now topsy-turvy. PGP has begun to replace SHA-1 in its programs. Another provider of widely used security systems, RSA Security Inc. of Bedford, Mass., is doing an inventory of its products to see how they use SHA-1 with an eye toward phasing it out. (RSA makes the popular SecurID cards used by many companies to ensure that only employees have remote access to computer networks.) The National Institute of Standards and Technology recommends not using SHA-1 in any new applications and is instructing federal agencies to develop plans for removing it from existing ones. The Chinese team hasn't published its paper on SHA-1, but the flaw is real, says Bruce Schneier, a cryptographer and chief technology officer of Counterpane Internet Security Inc., who has seen a draft of the paper. Academically, this is stunning work. The Chinese researchers haven't caused panic yet, says Avi Rubin, a computer-security expert at Johns Hopkins University. But it's definitely a wake-up call. The discovery follows recent research showing flaws in other hash functions. And it comes at a time when information-security concerns have been sharply heightened by problems not involving hash functions. Recent breaches at data aggregators ChoicePoint Inc. and Reed Elsevier PLC's LexisNexis exposed personal data on more than 100,000 Americans to identity thieves. And a poorly designed online system allowed scores of business-school applicants earlier this month to view decision letters ahead of time. Hash functions take a piece of data -- anything from an e-mail message to a giant database file -- and generate a short string of ones and zeros, 160 of them in SHA-1, that functions as the datum's unique fingerprint. Nothing else should generate the same hash, and a person in possession of only the hash can't figure out what the e-mail said or what the database contained. Those properties make hash functions well-suited to authentication -- they are used to make sure the Web site to which you send money actually belongs to, say, your bank or credit-card company -- not some rogue operator out for a scam.
