Re: A mighty fortress is our PKI, Part II
On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol. An OCSPResponse does contain unauthenticated plaintext[*], but that plaintext says nothing about the status of the given certificates -- it only says whether the OCSP Responder was able to handle the request. If a Responder is not able to handle requests it should respond in some way, and it may well not be able to authenticate the error response, thus the status of the responder is unauthenticated, quite distinctly from the status of the certificate, which is authenticated. Obviously only successful responses are useful. I agree on this and but the implementation of OCSP has to deal with all non definitive (to take the wording of the RFC) answers. That's where the issue is. All the exception case, mentioned in 2.3, are all unauthenticated and it seems rather difficult to provide authenticated scheme for that part as you already mentioned in [*]. That's why malware authors are already adding fake entries of OCSP server in the host file... simple and efficient. I just wanted to raise the point that a model like PK-i relying on complex scheme for security will easily fail at the obvious as the attacker is often choosing the shortest/fastest path to reach his goal. [*] It's not generally possible to avoid unauthenticated plaintext completely in cryptographic protocols. The meaning of a given bit of unauthenticated plaintext must be taken into account when analyzing a cryptographic protocol. -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. OCSP is even better for an attacker. As the OCSP responses are unauthenticated[1], you can be easily fake the response with what ever the attacker likes. http://www.thoughtcrime.org/papers/ocsp-attack.pdf [1] Would be silly to run OCSP over SSL ;-) -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Fri, Sep 18, 2009 at 6:27 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Although the draft has expired, the concept lives on in various tools. For example DownThemAll for Firefox supports this. There was some discussion about including it into FF3, but then the draft was dropped and the FF support never appeared, does anyone know what happened? It was a SoC project within Mozilla but seeing the following discussion : https://bugzilla.mozilla.org/show_bug.cgi?id=377245 The state looks a bit unclear to me... (The cynic in me would say it's such a simple, straightforward, easy-to- implement idea, of course it'll never be adopted when there are things like EV certs to be pushed instead, but who knows...). mode type=cynic Right... When I see the EV audit process[1], it looks to me like PCI DSS without the technical aspect... /mode [1] http://cabforum.org/WebTrustAuditGuidelines.pdf -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance --that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Thu, Aug 27, 2009 at 11:57 PM, Brian Warner war...@lothar.com wrote: == Integrity == To start with integrity-checking, we could imagine a firefox plugin that validated a PyPI-style #md5= annotation on everything it loads. The rule would be that no action would be taken on the downloaded content until the hash was verified, and that a hash failure would be treated like a 404. Or maybe a slightly different error code, to indicate that the correct resource is unavailable and that it's a server-side problem, but it's because you got the wrong version of the document, rather than the document being missing altogether. On the same idea, there is an expired Internet-Draft called Link Fingerprints : http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/ I made some experiments around while used as Machine Tag/Triple Tag[1] : http://www.foo.be/cgi-bin/wiki.pl/MachineTagLinkFingerprint to have an extension with OpenPGP detached signature. Another potential use, it's to benefit from the number of users checking the integrity and contribute back the computed value into a tagging system like del.icio.us or any other collaborative bookmarking. I especially like the Firefox (or wget,curl) extension that could compute the hash value and check it against various contributed hashes. That could give a kind of confidence level regarding the integrity of the file and its corresponding URL/URI. Just some ideas, adulau [1] http://www.foo.be/cgi-bin/wiki.pl/MachineTag -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance --that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 cracked
On Tue, 15 Feb 2005, Steven M. Bellovin wrote: According to Bruce Schneier's blog (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), a team has found collisions in full SHA-1. It's probably not a practical threat today, since it takes 2^69 operations to do it and we haven't heard claims that NSA et al. have built massively parallel hash function collision finders, but it's an impressive achievement nevertheless -- especially since it comes just a week after NIST stated that there were no successful attacks on SHA-1. and what about HMAC-SHA1 ? Is it reducing the operation required by the same factor or as the structure of HMAC is so different that the attack is very unlikely to be practical ? -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=getsearch=0x44E6CBCD -- Knowledge can create problems, it is not through ignorance --that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
