Re: SHA-1 cracked

2005-02-17 Thread Alexandre Dulaunoy
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]


Re: Bringing Tahoe ideas to HTTP

2009-09-17 Thread Alexandre Dulaunoy
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: Bringing Tahoe ideas to HTTP

2009-09-18 Thread Alexandre Dulaunoy
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: A mighty fortress is our PKI, Part II

2010-07-28 Thread Alexandre Dulaunoy
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: A mighty fortress is our PKI, Part II

2010-07-29 Thread Alexandre Dulaunoy
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