Re: PlayStation 3 predicts next US president

2007-12-14 Thread John Levine
The financial industry has actually created its own system - I forget
the name, some like a Gold Bond Certification - that it requires for
certain high-importance transactions (e.g., a document asserting you
own some stock for which you've lost the certificates).

That's a medallion signature guarantee provided by a bank or similar
institution.  Unlike a notary, the guarantee means something, with
the institution accepting liability for forgery.

Not surprisingly, it's a rare bank bank who will do this for anyone who
isn't already a customer.  At my bank, the same person happens to be a
notary and the guarantee officer and she knows me, so she just asks which
stamp I want.

http://en.wikipedia.org/wiki/Medallion_signature_guarantee
http://www.sec.gov/answers/sigguar.htm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread Ed Gerck

Allen wrote:

William Allen Simpson wrote:
[snip]


The whole point of a notary is to bind a document to a person.  That the
person submitted two or more different documents at different times is
readily observable.  After all, the notary has the document(s)!


No, the notary does not have the documents *after* they are notarized, 
nor do they keep copies. Having been a notary I know this personally. 


Thanks, Allen. Interestingly, digital signatures do provide what
notaries can't provide in this case. Even though a digital signature
binds a document to a key, there are known legal frameworks that can
be used to bind the key to a person.

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread Leichter, Jerry
|  The whole point of a notary is to bind a document to a person.  That
|  the person submitted two or more different documents at different
|  times is readily observable.  After all, the notary has the
|  document(s)!
| 
| No, the notary does not have the documents *after* they are notarized,
| nor do they keep copies. Having been a notary I know this
| personally. When I stopped being a notary all I had to submit to the
| state was my seal and my record books.
| 
| If I had to testify about a document I would only be attesting that
| the person who presented themselves adequately proved, under the
| prudent businessman's standard, that they were the person that they
| said they were and that I saw them sign the document in
| question. That's it. No copies at all. What would anyone have to
| testify about if a legal battle arose after the notary either died or
| stopped being a notary?
| 
| Think for a minute about the burden on a notary if they had to have a
| copy of every document they notarized. What a juicy target they would
| make for thieves and industrial spies. No patent paperwork would be
| safe, no sales contract, no will, or other document. Just think how
| the safe and burglar alarm companies would thrive. Now ask yourself
| how much it costs to notarize a document. Would that pay for the
| copying and storage. I don't know what the current fees are in
| California but 20 years ago they were limited to $6.00 per person per
| document and an extra buck for each additional copy done at the same
| time. My average was about $14.00 per session. My insurance was
| $50/year.  Nowhere near enough to cover my liability if I was to
This whole discussion has an air of unreality about it.

Historically, notary publics date from an era when most people couldn't
read or write, and hardly anyone could afford a lawyer.  How does
someone who can't read a document and can perhaps only scrawl an X
enter into a contract?  In the old days, he took the written contract
to a notary public, who would read it to him, explain it, make sure
he understood it, then stamp his scrawled X.  The notary's stamp
asserted exactly the kind of thing that we discuss on this list as
missing from digital signatures:  That the particular person whose
X was attached (and who would be fully identified by the notary)
understood and assented to the contents of the contract.

Today, we assume that everyone can read, and where a contract is at all
complex, that everyone will have access to a lawyer.  (Of course, this
assumption is often invalid, but that's another story.)  The requirement
for a notary public's stamp is a faded vestige.  For certain important
documents, we still require that a notary sign off, but what exactly
that proves any more is rather vague.  Yes, in theory it binds a
signature to a particular person, with that signature being on a
particular document.  That latter is why the notary's stamp is a
physical stamp through the paper - hard(er) to fake.  Of course, most of
the time, the stamp is only applied to the last page of a multi-page
contract, so proves only that that last page was in the notary's hands -
replacing the early pages is no big deal.  I think I've seen notaries
initial every page, but I've also seen notaries who don't.

In practice, whenever I've needed to have a document notarized, a quick
look at some basic ID is about all that was involved.  It's quite easy
to get fake ID past a notary.  Given the trivial fee paid to a notary -
I think the limit is $2 in Connecticut - asking the notary to actually
add much of value is clearly a non-starter.

The financial industry has actually created its own system - I forget
the name, some like a Gold Bond Certification - that it requires for
certain high-importance transactions (e.g., a document asserting you
own some stock for which you've lost the certificates).  I've never
actually needed to get this - it's appeared as a requirement for
some alternative kinds of transactions on forms I've had to fill out
over the years - so I don't know exactly how it works.  However, it's
completely independent of the traditional notary public system, and
is run through commercial banks.

Trying to justify anything based on the current role of notary
publics - at least as it exists in the US - is a waste of time.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread James A. Donald

William Allen Simpson wrote:
 The whole point of a notary is to bind a document to a
 person.  That the person submitted two or more
 different documents at different times is readily
 observable.  After all, the notary has the
 document(s)!

The notary does not want to have the documents, or to
have the necessary apparatus to produce them on demand.
Actually existent notaries do not keep the documents.

Again, you are trying to invent a protocol that works
around the flaws in MD5.  No doubt a competent engineer
can create such a protocol, but a competent engineer
would much prefer not to have flaws he needs to work
around.

Further, there is a long history of cryptographic
disasters, such as WiFi, where supposedly competent
engineers set to working around flaws, and instead
created more and bigger flaws.  Even if someone really
is a competent engineer, and perfectly capable of
producing a protocol that works around the known flaws,
it is hard for anyone else to tell if he really is
competent enough to work around the flaws, or has
produced, like WiFi and so many Microsoft projects, an
even bigger hole than that which he was trying to fix.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread Florian Weimer
* William Allen Simpson:

 Assuming,
   Dp := any electronic document submitted by some person, converted to its
 canonical form
   Cp := a electronic certificate irrefutably identifying the other person
 submitting the document
   Cn := certificate of the notary
   Tn := timestamp of the notary
   S() := signature of the notary

   S( MD5(Tn || Dp || Cp || Cn) ).

 Of course, I'm sure the formula could be improved, and there are
 traditionally fields identifying the algorithms used, etc. -- or something
 else I've forgotten off the top of my head -- but please argue about the
 actual topic of this thread, instead of incessant strawmen.

The problem is not the outer MD5 (explicitly mentioned in your
description), but that Dp is typically (well, to the extent such
services have been deployed) some kind of hash.  This has got the
advantage that the timestamping service does not need to know the
contents of the document.  On the other hand, if the timestamping
service archives Dp and can reveal it in a dispute, evil twins can be
identified and analyzed -- which undermine the submitting party's claim
that it submitted the second document instead of the first.

Of course, this is actually cheating by substituting proven protocols
for fragile cryptography.  And the result is still open to
interpretation, but all evidence is.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-11 Thread Allen

William Allen Simpson wrote:
[snip]


The whole point of a notary is to bind a document to a person.  That the
person submitted two or more different documents at different times is
readily observable.  After all, the notary has the document(s)!


No, the notary does not have the documents *after* they are 
notarized, nor do they keep copies. Having been a notary I know 
this personally. When I stopped being a notary all I had to 
submit to the state was my seal and my record books.


If I had to testify about a document I would only be attesting 
that the person who presented themselves adequately proved, under 
the prudent businessman's standard, that they were the person 
that they said they were and that I saw them sign the document in 
question. That's it. No copies at all. What would anyone have to 
testify about if a legal battle arose after the notary either 
died or stopped being a notary?


Think for a minute about the burden on a notary if they had to 
have a copy of every document they notarized. What a juicy target 
 they would make for thieves and industrial spies. No patent 
paperwork would be safe, no sales contract, no will, or other 
document. Just think how the safe and burglar alarm companies 
would thrive. Now ask yourself how much it costs to notarize a 
document. Would that pay for the copying and storage. I don't 
know what the current fees are in California but 20 years ago 
they were limited to $6.00 per person per document and an extra 
buck for each additional copy done at the same time. My average 
was about $14.00 per session. My insurance was $50/year. Nowhere 
near enough to cover my liability if I was to retain a copy of 
the document.


Best,

Allen

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-11 Thread silky
On Dec 11, 2007 5:06 AM, Allen [EMAIL PROTECTED] wrote:
 What puzzles me in all this long and rather arcane discussion is
 why isn't the solution of using a double hash - MD5 *and* SHA
 whatever. The odds of find a double collision go way up.

 Some open source software people are already doing this. I've
 played around with the sample files that are out there and find
 an easy way to do this but I don't have either the horsepower or
 skill to be at all definitive.

 My gut tells me that using two processes that use different
 algorithms, even though compromised, will raise the bar so high
 that it would be secure for a long time.

 At my skill level and horsepower I can't find even a single way
 to do this with CRC32 and MD5. Granted, that certainly doesn't
 mean a whole lot.

Work has actually been done on this exact topic.

One link is here: http://cryptography.hyperlink.cz/2004/otherformats.html

I think there may be more; I'm not sure.


 But to take a real world example, a safety deposit box, the two
 keys have to work together to open the box. It really does not
 matter is one is a Yale and the other a combination, either one
 of which are easily compromised by themselves, but together you
 would have to find both at the same time to open the box, a lot
 tougher problem.

 Best,

 Allen


 Francois Grieu wrote:
  [EMAIL PROTECTED] wrote:
 
   Dp := any electronic document submitted by some person, converted to its
 canonical form
   Cp := a electronic certificate irrefutably identifying the other person
 submitting the document
   Cn := certificate of the notary
   Tn := timestamp of the notary
   S() := signature of the notary
 
   S( MD5(Tn || Dp || Cp || Cn) ).
 
  In this context, the only thing that guards agains an attack by
  some person is the faint hope that she can't predict the Tn
  that the notary will use for a Dp that she submits.
 
  That's because if Tn is known (including chosen) to some person,
  then (due to the weakness in MD5 we are talking about), she can
  generate Dp and Dp' such that
S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' || Cp || Cn) )
  whatever Cp, Cn and S() are.
 
  If Tn was hashed after Dp rather than before, poof goes security.
 
 
Francois Grieu
 
  -
  The Cryptography Mailing List
  Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]




-- 
mike
http://lets.coozi.com.au/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-10 Thread James A. Donald

William Allen Simpson wrote:
   The notary would never sign a hash generated by
   somebody else.  Instead, the notary generates its
   own document (from its own tuples), and signs its
   own document, documenting that some other document
   was submitted by some person before some
   particular time.

James A. Donald:
  And how does it identify this other document?

William Allen Simpson wrote:
 Sorry, obviously I incorrectly assumed that we're
 talking to somebody skilled in the art

 Reminding you that several of us have told you that a
 notary has the document in her possession; and binds
 the document to a person; and that we have rather a
 lot of experience in identifying documents (even for
 simple things like email), such as the PGP digital
 timestamping service.

 Assuming,
   Dp := any electronic document submitted by some
   person, converted to its
 canonical form
   Cp := a electronic certificate irrefutably
   identifying the other person
 submitting the document
   Cn := certificate of the notary Tn := timestamp of
   the notary S() := signature of the notary

   S( MD5(Tn || Dp || Cp || Cn) ).

Assuming that the attacker knows or can guess Tn, and
that the canonical form allows images, then the attack
still works.

The attacker can create several documents, D1, D2, D3,
D4, D5, such that MD5(Tn || D1 || Cp || Cn) is equal to
MD5(Tn || D2 || Cp || Cn), which is equal to MD5(Tn ||
D3 || Cp || Cn), etc.

He then gets the notary to sign MD5(Tn || D1 || Cp ||
Cn), and then uses  whichever of D1, D2, D3, D4, and D5
is convenient.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-10 Thread William Allen Simpson

Francois Grieu wrote:

That's because if Tn is known (including chosen) to some person,
then (due to the weakness in MD5 we are talking about), she can
generate Dp and Dp' such that
  S( MD5(Tn || Dp || Cp || Cn) ) = S( MD5(Tn || Dp' || Cp || Cn) )
whatever Cp, Cn and S() are.


First of all, the weakness in MD5 (computational feasibility over time)
that we are talking about is not (yet) a preimage or second preimage
attack.  Please don't extrapolate your argument.

Second of all, you need to read my messages more carefully.  No good
canonical format allows random hidden fields or images.

Third of all, that's not a weakness of a notary protocol -- it's a trap!
The whole point of a notary is to bind a document to a person.  That the
person submitted two or more different documents at different times is
readily observable.  After all, the notary has the document(s)!

Remember, the notary is not vouching for the validity of the content of
the document.  A notary only certifies that something was submitted by
some person at some time.  And that cannot be broken by making multiple
submissions, or submissions that themselves have the same hash.

That's one reason I'm much more interested in the attack on X.509.



If Tn was hashed after Dp rather than before, poof goes security.


But since it's not, that's a ridiculous strawman.  I was remembering PGP
off the top of my head.  Fairly certain that Kerberos does, too.  Not
everybody is naive!

And since the timestamp is predictable (within some range, although
picoseconds really aren't very predictable), the protocols that I've
designed include message identifiers, nonces, and sequence numbers, too.

As you may recall, I mentioned that there were other fields

He asked for an explanation about how a document is identified, he got
one.  Don't expect me to redesign an entire notary (or even a timestamp)
protocol on a Sunday evening for a mailing list  Really, there are
fairly secure standards already available.

However, the actual topic of this thread is code distribution.  In that
case, there is no other party certifying the documents.  The code
packager is also the certifier.  There is (as yet) no weakness in the
MD4 family (including MD5 and SHA1) that allows this attack by another
party.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-09 Thread James A. Donald

William Allen Simpson wrote:
 The notary would never sign a hash generated by
 somebody else.  Instead, the notary generates its own
 document (from its own tuples), and signs its own
 document, documenting that some other document was
 submitted by some person before some particular time.

And how does it identify this other document?

The notary is only safe from this flaw in MD5 if you
assume he is not using MD5 for its intended purpose.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-09 Thread William Allen Simpson

Personally, I thought this horse was well drubbed, but the moderator let
this message through, so he must think it important to continue

James A. Donald wrote:

William Allen Simpson wrote:
  The notary would never sign a hash generated by
  somebody else.  Instead, the notary generates its own
  document (from its own tuples), and signs its own
  document, documenting that some other document was
  submitted by some person before some particular time.

And how does it identify this other document?


Sorry, obviously I incorrectly assumed that we're talking to somebody
skilled in the art

Reminding you that several of us have told you that a notary has the
document in her possession; and binds the document to a person; and that
we have rather a lot of experience in identifying documents (even for
simple things like email), such as the PGP digital timestamping service.

Assuming,
  Dp := any electronic document submitted by some person, converted to its
canonical form
  Cp := a electronic certificate irrefutably identifying the other person
submitting the document
  Cn := certificate of the notary
  Tn := timestamp of the notary
  S() := signature of the notary

  S( MD5(Tn || Dp || Cp || Cn) ).

Of course, I'm sure the formula could be improved, and there are
traditionally fields identifying the algorithms used, etc. -- or something
else I've forgotten off the top of my head -- but please argue about the
actual topic of this thread, instead of incessant strawmen.



The notary is only safe from this flaw in MD5 if you


Another statement with no proof.  As the original poster admitted, there is
not a practical preimage or second preimage attack on MD5 (yet).


assume he is not using MD5 for its intended purpose.


As to its intended purpose, rather than making one up, I've always relied
upon the statement of the designer:

   ... The MD5
   algorithm is intended for digital signature applications, where a
   large file must be compressed in a secure manner before being
   encrypted with a private (secret) key under a public-key cryptosystem
   such as RSA.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-05 Thread dan

If on the one hand, the correct procedure is sign-encrypt-sign,
then why, on the other hand, is the parallel not sign-hash-sign ?

--dan

=

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps

Donald T. Davis, Defective Sign  Encrypt in S/MIME, PKCS#7, MOSS, PEM,
PGP, and XML., Proc. Usenix Tech. Conf. 2001 (Boston, Mass., June
25-30, 2001), pp. 65-78.(180 Kbytes) (PDF, 200 Kbytes) (HTML, 80 Kbytes)

Summary of the paper.

Abstract: 
Simple Sign  Encrypt, by itself, is not very secure. Cryptographers
know this well, but application programmers and standards authors still
tend to put too much trust in simple Sign-and-Encrypt. In fact, every
secure e-mail protocol, old and new, has codified naïve Sign 
Encrypt as acceptable security practice. S/MIME, PKCS#7, PGP, OpenPGP,
PEM, and MOSS all suffer from this flaw. Similarly, the secure document
protocols PKCS#7, XML- Signature, and XML-Encryption suffer from the
same flaw. Naïve Sign  Encrypt appears only in file-security and
mail-security applications, but this narrow scope is becoming more
important to the rapidly-growing class of commercial users. With file-
and mail-encryption seeing widespread use, and with flawed encryption in
play, we can expect widespread exposures.

In this paper, we analyze the naïve Sign  Encrypt flaw, we
review the defective sign/encrypt standards, and we describe a
comprehensive set of simple repairs. The various repairs all have a
common feature: when signing and encryption are combined, the inner
crypto layer must somehow depend on the outer layer, so as to reveal any
tampering with the outer layer.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-03 Thread William Allen Simpson

James A. Donald wrote:

 Not true.  Because they are notarizing a signature, not
a document, they  check my supporting identification,
but never read the document being signed.


This will be my last posting.  You have refused several requests to stick
to the original topic at hand.

Apparently, you have no actual experience with the legal system, or
are from such a different legal jurisdiction that your scenario is
somehow related to MD5 hashes of software and code distribution.

Because human beings often try to skirt the rules, there's a long
history of detailed notarization requirements.  How it works here:

(1) You prepare the document(s).  They are in the form prescribed by law
-- for example, Michigan Court Rule (MCR 2.114) SIGNATURES OF ATTORNEYS
AND PARTIES; VERIFICATION; EFFECT; SANCTIONS

(2) The clerk checks for the prescribed form and content.

(3) You sign and date the document(s) before the notary (using a pen
supplied by the notary, no disappearing ink allowed).

(4) The notary signs and dates their record of your signature, optionally
impressing the document(s) with an embossing stamp (making it physically
difficult to erase).

You have now attested to the content of the documents, and the notary has
attested to your signature (not the veracity of the documents).  Note
that we get both integrity and non-repudiation

The only acceptable computer parallel would require you to bring the
documents to the notary, using a digital format supplied by the notary,
generate the digital signature on the notary's equipment, and then the
notary indempotently certify your signature (on the same equipment).

In the real world, the emphasis is on binding a document to a person, and
vice versa.  Any digital system that does not tie the physical person to
the virtual document is not equivalent.

This is simply not equivalent to a site producing its own software and
generating a hash of its own content.  There should be no third party
involved as a certifier.



If they were to generate an MD5 hash of documents
prepared by someone else, then the attack described
(eight different human readable documents with the same
MD5 hash) works.


If a notary were to do that, they'd be looking at a fairly severe penalty.
By definition, such a notary was compromised.

But nothing like the prison sentence that you'd be facing for presenting
the false documents to the court.  And I'd be pushing the prosecutor for
consecutive sentences for all 8 fraudulent documents, with enhancements.

Nobody has given any examples of human readable documents that will
produce the same hash when re-typed into the system.  All those proposed
require an invisible component.  They are machine readable only.

That's why we, as security analysts, don't design or approve such systems.
We're not (supposed to be) fooled by parlor tricks.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-03 Thread William Allen Simpson

Weger, B.M.M. de wrote:

See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/
...
Our first chosen-prefix collision attack has complexity of about
2^50, as described in our EuroCrypt 2007 paper. This has been 
considerably improved since then. In the full paper that is in

preparation we'll give details of those improvements.


Much more interesting.  Looks like the death knell of X.509.  Why
didn't you say so earlier?

(It's a long known design flaw in X.509 that it doesn't provide
integrity for all its internal fields.)

Where are MD2, MD4, SHA1, and others on this continuum?

And based on the comments in the page above, the prefix is quite large!
Optimally, shouldn't it be = the internal chaining variables?  512 bits
for MDx.  So, the attacks need two values for comparison: the complexity
versus the length of the chosen prefix.

Let me know when you get the chosen prefix down to 64-bits, so I can say
I told you so to Bellovin again.  I was strongly against adding the
random IV field to IPsec

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-03 Thread Allen



William Allen Simpson wrote:

[snip]


Actually, I deal with notaries regularly.  I've always had to
physically sign while watched by the notary.  They always
read the stuff notarized, and my supporting identification,
because they are notarizing a signature (not a document).

And yes, they always generate the stamp or imprint they sign.
To do otherwise would be irresponsible (and illegal).


Having been a notary in the State of California (Shocked myself, 
got 100% on the test!) I can attest that the contents of the 
document are looked at, but only so that I could record what 
*type* of document I was notarizing, not the exact textual 
meaning of the content or whether it might or might not allege 
something that is untrue.


The description of the document in my log book was always 
relatively short as there was only space for about 20 words.


The requirements are simple, see that the document you are 
notarizing has as many pages it says it does so that the count 
can't be changed without arousing suspicion, and the the person 
who is signing the paper is identified by enough documentation 
that I could be assured, within the limits of my ability to give 
a superficial, not expert, less than ten minutes perusal of the 
identification documents presented match the person presenting 
them to the best of my ability to judge.


Best,

Allen

It always was a good faith certification, not a proof beyond 
challenge.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-02 Thread William Allen Simpson

James A. Donald wrote:

This attack does not require the certifier to be
compromised.


You are referring to a different page (that I did not reference).
Never-the-less, both attacks require the certifier to be compromised!



 The attack was to generate a multitude of predictions
for the US election, each of which has the same MD5
hash.  If the certifier certifies any one of these
predictions, the recipient can use the certificate for
any one of these predictions.


That's a mighty big if -- as in infinite improbability.  Therefore, a
parlor trick, not cryptography.

There are no circumstances in which any reputable certifier will ever
certify any of the multitude containing a hidden pdf image, especially
where generated by another party.

The attack requires the certifier to be compromised, either to certify
documents that the certifier did not generate, or to include the chosen
text (hidden image) in its documents in exactly the correct location.

While there are plenty of chosen text attacks in cryptography, this one
is highly impractical.  The image is hidden.  It will not appear, and thus
would not be accidentally copied by somebody (cut-and-paste).

The parlor trick demonstrates a weakness of the pdf format, not MD5.



This attack renders MD5 entirely worthless for any use
other than as an error check like CRC - and CRC does it
better and faster.


To be as weak as CRC, the strength would be 2**8.  I've seen no papers
that reduce MD5 complexity to 2**8.

Please present your proofs and actual vulnerabilities, including specific
examples of actual PPP CHAP compromised traffic -- and for extra credit,
actual compromise of netbsd and/or openbsd software distribution.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-02 Thread William Allen Simpson

Weger, B.M.M. de wrote:

The parlor trick demonstrates a weakness of the pdf format, not MD5.


I disagree. We could just as easy have put the collision blocks
in visible images.


Parlor trick.


... We could just as easy have used MS Word
documents, or any document format in which there is some way
of putting a few random blocks somewhere nicely.


Parlor trick.


... We say so on
the website. We did show this hiding of collisions for other data
formats, such as X.509 certificates


More interesting.  Where on your web site?  I've long abhorred the
X.509 format, and was a supporter of a more clean alternative.


... and for Win32 executables.


Parlor trick.

So far, all the things you mention require the certifier to be suborned.



Our real work is chosen-prefix collisions combined with
multi-collisions. This is crypto, it has not been done before,


Certainly it was done before!  We talked about it more than a decade ago.
We knew that what was computationally infeasible would become feasible.

Every protocol I've designed or formally reviewed is protected against the
chosen prefix attack.  (To qualify, where I had final say.  I've reviewed
badly designed protocols, such as IKE/ISAKMP.  And I've been overruled by
committee from time to time)

What *would* be crypto is the quantification of where MDx currently falls
on the computational spectrum.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: PlayStation 3 predicts next US president

2007-12-02 Thread Weger, B.M.M. de
Hi William,

  ... We say so on
  the website. We did show this hiding of collisions for other data 
  formats, such as X.509 certificates
 
 More interesting.  Where on your web site?  I've long abhorred the
 X.509 format, and was a supporter of a more clean alternative.

See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/

  Our real work is chosen-prefix collisions combined with 
  multi-collisions. This is crypto, it has not been done before,
 
 Certainly it was done before! 

I was referring to MD5. Apart from that, I'd be interested in
seeing references to older work on chosen-prefix multicollisions.

 What *would* be crypto is the quantification of where MDx 
 currently falls on the computational spectrum.

Our first chosen-prefix collision attack has complexity of about
2^50, as described in our EuroCrypt 2007 paper. This has been 
considerably improved since then. In the full paper that is in
preparation we'll give details of those improvements.

Grtz,
Benne

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]