>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
* 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 := tim
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
| > 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,
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 doc
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() a
silky wrote:
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 a
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 do
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*
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
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, th
[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 nota
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
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
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.
A
[EMAIL PROTECTED] wrote:
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 ?
What is "correct" depends on requirements and semantics, and
neither is well addressed in that paper nor in standards,
w.r.t. email and si
I had intended to stop posting, but with the request for history and a few
misguided postings later, please indulge me. I'll try not to be too long.
We've been talking about "collision" and "preimage" resistance at least
since 1989. We didn't use those terms (I'm not fond of "preimage"). We
me
On Dec 3, 2007, at 2:47 PM, William Allen Simpson wrote:
Dirk-Willem van Gulik wrote:
Keep in mind that the notary is still 'careful' -- effectively they
sign the hash -- rather than the document; and state either such
(e.g. in the case of some software/code where you do not hand over
Dirk-Willem van Gulik wrote:
>> Keep in mind that the notary is still 'careful' --
>> effectively they sign the hash -- rather than the
>> document; and state either such (e.g. in the case of
>> some software/code where you do not hand over the
>> actual code) or state that _a_ document was presen
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.
William Allen Simpson wrote:
This will be my last posting. You have refused several requests to stick
to the origina
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.",
Dirk-Willem van Gulik wrote:
Keep in mind that the notary is still 'careful' -- effectively they sign
the hash -- rather than the document; and state either such (e.g. in the
case of some software/code where you do not hand over the actual code)
or state that _a_ document was presented with sai
On Dec 2, 2007, at 3:09 AM, William Allen Simpson wrote:
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.
It is getting fairly common for notaries in for example t
I'd be interested in seeing
references to older work on chosen-prefix multicollisions.
This has been on the web since at least July.
http://www.cits.rub.de/MD5Collisions/
I'm sure it's not the only one either.
-
The Cryptogra
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 alwa
James A. Donald wrote:
A notary is a certifier. Have you ever seen a notary
read the stuff he notarizes, let alone generate it?
William Allen Simpson wrote:
Actually, I deal with notaries regularly. I've always had to
physically sign while watched by the notary. They always
read the stuff n
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
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, y
William Allen Simpson wrote:
[snip]
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.
Given what we know about
James A. Donald wrote:
>> A notary is a certifier. Have you ever seen a notary
>> read the stuff he notarizes, let alone generate it?
William Allen Simpson wrote:
> Actually, I deal with notaries regularly. I've always
> had to physically sign while watched by the notary.
> They always read the
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.w
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
James A. Donald wrote:
A notary is a certifier. Have you ever seen a notary
read the stuff he notarizes, let alone generate it?
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 id
Hi William,
> > 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 b
William Allen Simpson wrote:
> Apparently, you never read the original rationale for
> MD5. It still does what it was intended to do
MD5 was intended to identify the thing being hashed
uniquely. If it is possible to produce multiple
plausible human readable texts that say different things
y
James A. Donald wrote:
So the certifier is going to go through each thing he
certifies, to make sure there is nothing funny about it?
Yes.
The whole point of MD5 is to automate that stuff. If an
actual human has to go through it, and understand what
it means, and certify the *meaning* then t
> 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.
So the certifier is going to go through each thing he
certifies, to make sure there is nothing funny about it?
T
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 elect
William Allen Simpson wrote:
> Weger, B.M.M. de wrote:
>> See http://www.win.tue.nl/hashclash/Nostradamus if
>> you want to know the details of what this has to do
>> with cryptography.
>>
> It always bothers me as these things are announced,
> but are based on presumptions that have absolutely no
Weger, B.M.M. de wrote:
See http://www.win.tue.nl/hashclash/Nostradamus if you want to know
the details of what this has to do with cryptography.
It always bothers me as these things are announced, but are based on
presumptions that have absolutely no relevance in the real world
Therefore,
Weger, B.M.M. de wrote:
> We also announce two different Win32 executables that
> have identical MD5 hash values. This can be made to
> happen for any two executable files. This implies a
> vulnerability in software integrity protection and
> code signing schemes that still use MD5. See
> http://w
41 matches
Mail list logo
