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: Open-source PAL

2007-12-03 Thread Steven M. Bellovin
On Thu, 29 Nov 2007 16:05:00 -0500
Tim Dierks [EMAIL PROTECTED] wrote:

 A random thought that's been kicking around in my head: if someone
 were looking for a project, an open-source permissive action link (
 http://www.cs.columbia.edu/~smb/nsam-160/pal.html is a good link,
 thank you Mr. Bellovin) seems like it might be a great public
 resource: I suspect it's something that some nuclear states could use
 some education on, but even if the US is willing to share technology,
 the recipient may not really trust the source.
 
 As such, an open-source PAL technology might substantially improve
 global safety.
 
I don't think it would be fruitful.  Have a look at page 2 of
http://www.nytimes.com/2007/11/18/washington/18nuke.html -- it notdes
that The system hinges on what is essentially a switch in the firing
circuit that requires the would-be user to enter a numeric code that
starts a timer for the weapon?s arming and detonation.  I don't think
that that's quite correct -- it permits arming; PALs are not in the
firing circuit, I believe -- but this section is more interesting:
Delicate design details involve how to bury the link deep inside a
weapon to keep terrorists or enemies from disabling the safeguard.
In other words, it's easy to have a circuit that keeps the bomb from
arming; the hard part is doing so with high assurance against attacks,
and that's very design-dependent.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
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]