Re: Flaws in OpenSSL FIPS Object Module
At 9:58 AM -0500 12/3/07, Perry E. Metzger wrote: I don't know if people have been following this, but it is interesting from the point of view of studying how the FIPS process does (or does not) interact with the underlying goal of producing assured systems. Another interesting part is that open-source systems are much more susceptible to being attacked by competitors (that is, having their validation suspended) than are closed-source systems. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Flaws in OpenSSL FIPS Object Module
I don't know if people have been following this, but it is interesting from the point of view of studying how the FIPS process does (or does not) interact with the underlying goal of producing assured systems. Begin Forwarded Message: Return-Path: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Date: Mon, 03 Dec 2007 09:05:37 -0500 From: Steve Marquess <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Fwd: Flaw in OpenSSL FIPS Object Module v1.1.1 - Update The vulnerability reported earlier (http://openssl.org/news/secadv_20071129.txt) cannot be patched in the usual way due to the requirements of the FIPS 140-2 validation program (the CMVP). Discussions on ways to craft a fix that will satisfy FIPS 140-2 with the least delay in approval have been underway for several days. The situation is complicated by the fact that there is a second bug in the FIPS 140-2 mandated continuous PRNG self-test. This other bug does not constitute a security vulnerability, but the CMVP understandably requires that both bugs be corrected at the same time. FIPS 140-2 has the concept of an algorithm boundary around each separate algorithm implementation in addition to the overall crypto module boundary. Changes to code inside an algorithm boundary require considerably more time and effort for approval. We can implement a workaround for the CVE-2007-5502 vulnerability outside of any algorithm boundary, but cannot do the same for the self-test bug. As a consequence approval of a new distribution will take longer. How long is hard to estimate, perhaps as little as a couple of weeks. In the meantime the CMVP has effectively revoked the current v1.1.1 validation (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733) by declaring the PRNG as non-compliant. Since essentially all cryptographic applications utilize a PRNG the entire v1.1.1 module is for all practical purposes revoked as well. This means vendors of software products using or based on the v1.1.1 PRNG will need to be patched or updated with the new v1.1.2 of the OpenSSL FIPS Object Module once that becomes available. It would be prudent to anticipate additional quasi-revocations of other validations for products derived from the v1.1.1 baseline. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Announcement Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
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 said hash. And that makes all the difference. The digital notary is not certifying the original document. You described the notary generating its own tuples (credentials as presented, the hash, a timestamp, and a notarized declaration that such was presented). There is no problem, and the described attack does not apply. Note that the notary bears no responsibility for presentation of false credentials. Here, in a case with which I'm personally familiar, somebody with the SAME NAME as his father got a new driver's license, signed it in the same fashion as his father, then went to banks and presented the driver's license and signature, causing all his father's deposits to be transferred to his wife's name, and adding his son to the house deed (and then mortgaging the house). It was certainly not the several notaries' fault that identical names were used. The "certificate" (same name driver's license and signature) appeared valid. All the cryptography in the world will not prevent false certification, where the underlying information is already compromised. To reiterate the topic at hand: trust is not transitive! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
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 the Netherlands to timestamp or otherwise attest that an (asset with) hash (e.g. MD5 an) was presented to them by a person or company with such and such credentials. E.g. NotarSign (diginotarl.nl) its email service will attest such in an automated fashion. Essentially what you are getting is a notarized statement containing the credentials as presented, the hash, a timestamp and a notarized (backed with an Appostille of the Hague if to be used internationally) declaration that such was presented. Note presentation of the asset is quite optional in this process. And for practical reasons it is quite common now in certain trade- environments to _not_ sent the actual document to NotarSign but just the statement with an MD5* and a https URL to the Purchase Order (where the biz. partner needs his x509 or a physical RSA token to pick it up) - to be forwarded to the trading partners. THIS is what makes this "tongue in cheek" example 'somewhat' relevant for day to day workflows for those who are still using MD5s. 'Somewhat' - as ultimately in this example it is hard to argue entirely accidental tampering. However - in some biz. sealed-bid processes the damage is done by that time. 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). 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 said hash. The _assumption_ that there is a 1:1 mapping is one left to the reader. Compare it to the passport/personalia -- the statement of fact usually says that a person appeared in front of the notary which presented... rather than Mr X submitted himself to... Dw. *) The above example falls somewhat apart as the current message contains an 'at&t 'sum', md5, SHA-256, SHA-512 and the length - and almost all ERP systems check all but the AT&T checksum. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: PlayStation 3 predicts next US president
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 Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
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
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 notarized, and my supporting identification, because they are notarizing a signature (not a document). But they don't read the document, let alone generate it. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Open-source PAL
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
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
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]
