RTFA: http://news.yahoo.com/s/ap/20071026/ap_on_go_ca_st…

A team of specially trained investigators will hunker down in an Army office north of Detroit on Monday to begin poring over hundreds of Iraq war contracts in search for rigged awards.

This team of 10 auditors, criminal investigators and acquisition experts are starting with a sampling of the roughly 6,000 contracts worth $2.8 billion issued by an Army office in Kuwait that service officials have identified as a hub of corruption.

RTFA: http://www.win.tue.nl/hashclash/TargetCollidingCer…

Our construction requires that the two colliding certificates are generated simultaneously. Al- though each resulting certificate by itself is completely unsuspicious, the fraud becomes apparent when the two certificates are put alongside, as may happen during a fraud analysis. An attacker can generate one of the certificates for a targeted person, the other one for himself, and attempt to use his own credentials to convince an external and generally trusted CA to sign the second one.
If successful, the attacker can then distribute the first certificate, which will be trusted by relying parties, e.g. to encrypt messages for the targeted person. The attacker however is in control of the corresponding private key, and can thus decrypt confidential information embedded in intercepted messages meant for the targeted person. Or the attacker can masquerade as the targeted person while signing messages, which will be trusted by anyone trusting the CA. In this scenario it does not matter whether the two certificates have different public keys (as in our example) or identical ones (in which case the colliding blocks would have to be hidden somewhere else in the certificate).
A problem is, however, that the CA will register the attacker’s identity. As soon as a dispute arises, the two certificates will be produced and revealed as colliding, and the attacker will be identified. Another problem is that the attacker must have sufficient control over the CA to predict all fields appearing before the public key, such as the serial number and the validity periods. It has frequently been suggested that this is an effective countermeasure against colliding certificate constructions in practice, but there is no consensus how hard it is to make accurate predictions.
When this condition of sufficient control over the CA by the attacker is satisfied, colliding certificates based on chosen-prefix collisions are a bigger threat than those based on random collisions. Obviously, the attack becomes effectively impossible if the CA adds a sufficient amount of fresh randomness to the certificate fields before the public key, such as in the serial number (as some already do, though probably for different reasons). This randomness is to be generated after the approval of the certification request. On the other hand, in general a relying party cannot verify this randomness. In our opinion, trustworthiness of certificates should not crucially depend on such
secondary and circumstantial aspects. On the contrary, CAs should use a trustworthy hash function that meets the design criteria. Unfortunately, this is no longer the case for MD5, or SHA-1. We stress that our construction (we prefer this wording to ‘attack’) is not a preimage attack.
As far as we know, existing certificates cannot be forged by chosen-prefix collisions if they have not been especially crafted for that purpose. However, a relying party cannot distinguish any given trustworthy certificate from a certificate that has been crafted by our method to violate PKI principles. Therefore we repeat, with more urgency, our recommendation that MD5 is no longer used in new X.509 certificates. Similar work [1] is in development for the SHA-1 hash function, so we feel that a renewed assessment of the use of SHA-1 in certificate generation is also appropriate.

Wow! I know this paper was distributed 8 months ago, but holy shit! In case you don’t know about X.509, it’s the standard that the entire SSL trust infrastructure is built on. X.509 describes what fields need to appear an an SSL certificate, and it’s in relying on these SSL certificates that a web browser (e.g. IE) decides if a secure (HTTPS) connection is forged or not.

So today, I was attempting to validate the SSL certificates involved in a particular communication. I visited https://www.verisign.com to see how their signing chain looked, because I assumed this would be a good example. On Verisign’s site, the chain starts with a Generation One (G1 - a Verisign marketing term, I think) Public Primary Certificate Authority (PCA). Some PCAs (around 100, at the moment) are trusted enough that they ship directly with web browsers. The private keys that correspond to those public PCAs are well-guarded. Verisign has a bunch of these public/private PCA key pairs, and one is used to start the chain that secures verisign.com. I already had it, since it came with Opera.

The next item in the chain was a G5 PCA, which was directly signed by the G1 PCA. Although the G5 PCA isn’t shipped with Opera, it is trusted because the G1 PCA is trusted; the G1 PCA extends trust through its signature on the G5 PCA.

The G5 PCA was used to sign another CA that appears to be used only for SSL certificates. The trust from the G1 PCA, which flows through the G5 PCA, extends to the SSL CA. Ultimately, the SSL CA is used to sign the verisign.com certificate. That’s why my browser “trusts” verisign.com. So, verisign SSL chain looks like this:

G1 PCA signs ITSELF, which signs G5 CA, which signs SSL CA, which signs verisign.com

Next, I looked at the SSL signing chain for a site that I was suspicious of. The other site’s chain looks like this:

G5 CA signs ITSELF, which signs SSL CA, which signs othersite.com

Because the G5 CA doesn’t ship with Opera, I don’t trust it unless I go out of my way to download, install, and trust that certificate. I actually did this, by locating the key on the Verisign website based on its “signature.” It’s not very hard to add SSL certificates to Opera, but there are a few problems with the process.

For example, unless I trust that my nameserver will correctly resolve the Verisign website, I cannot trust that I am actually getting a good copy of the certificate. Also, I must trust that verisign’s web servers are secure enough to guarantee that I am getting a trustworthy copy of the certificate.

Finally, there’s the proof of concept in the paper above, which suggests that it’s possible to tamper with X.509 certificates. Basically, this leaves open the possibility that the site I am connecting to is using a separate public keychain, which somehow is called by the same name, but which is self signed instead of G1-signed. In the case that a separate keychain is in use, the communication could conceivably be compromised…

So how to very if it’s good or not? I don’t trust the self-signed certificate as much as the G1-signed certificate. …so do I trust it at all?

RTFA: http://www.livescience.com/strangenews/071026-hott…

Researchers at New Mexico State University have discovered the world’s hottest chili pepper. It’s called the Bhut Jolokia, a variety originating in Assam, India.

In tests that yield Scoville heat units (SHUs), the Bhut Jolokia reached 1 million SHUs, almost double the SHUs of former hotshot Red Savina (a type of habanero pepper), which measured a mere 577,000. The result was announced today by the American Society for Horticultural Science.

Time to make some enhanced pepper spray!

RTFA: http://www.cnn.com/2007/US/law/10/26/wilson.freed/…

The Georgia Supreme Court on Friday ordered that Genarlow Wilson be released from prison, ruling 4-3 that his sentence for a teen sex conviction was cruel and unusual punishment.

Genarlow Wilson’s case received national attention and led to changes in Georgia law.

Wilson, 21, was convicted in 2005 of having oral sex with a consenting 15-year-old girl when he was 17.

He has served more than two years in prison.

I can’t believe he served 2 years in jail - absolutely disgusting.

RTFA: http://news.bbc.co.uk/2/hi/uk_news/england/tees/70…

A man who urinated on a woman as she lay dying and shouted “this is YouTube material” has been sentenced to three years in prison.

Anthony Anderson also covered Christine Lakinski with shaving foam after she collapsed in a Hartlepool street.

The 50-year-old, who suffered from a number of medical conditions, was later pronounced dead at the scene.