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
| 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,
|
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
* 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
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
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
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
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
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
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
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.,
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,
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
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
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
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
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
17 matches
Mail list logo
