Saturday, January 03, 2009

Re: very high speed hardware RNG

On Dec 30, 2008, at 5:11 PM, Jerry Leichter wrote:
> This is a highly chaotic process, and after a short time, you see a
> completely random-looking dispersion of dye through the liquid.
> Present this to someone and any likely test will say this is quite
> random. But ... if you slow turn the inner cylinder backwards -
> "slowly", for both directions of turn, depending on details of the
> system - the original line of dye miraculously reappears.

(Laminar flow: <http://www.youtube.com/watch?v=p08_KlTKP50>.)

--
Ivan Krstić <krstic@solarsail.hcs.harvard.edu> | http://radian.org

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Friday, January 02, 2009

Re: MD5 considered harmful today

On Tue, 30 Dec 2008, Hal Finney wrote:
>
> - The attack relies on cryptographic advances in the state of the art for
> finding MD5 collisions from inputs with different prefixes. These advances
> are not yet being published but will presumably appear in 2009.

To insert a malicious "basicConstraints CA = TRUE" these advances appear
necessary; I do not believe that they are necessary for the other very
similar attack (where the malicious cert is a wildcard (*) certificate). I
could be wrong about this, but I also don't think that the advances in
cryptography to get from chosen prefix attacks to here are anywhere near
as great as were needed to get the original chosen prefix work. We can
evaluate the correctness of that statement when the work is published, of
course.

> - The collision was found using Arjen Lenstra's PlayStation Lab and used
> 200 PS3s with collectively 30 GB of memory. The attack is in two parts,
> a new preliminary "birthdaying" step which is highly parallelizable and
> required 18 hours on the PS3s, and a second stage which constructs the
> actual collision using 3 MD5 blocks and runs on a single quad core PC,
> taking 3 to 10 hours.

Prof. Lenstra's PlayStation Lab is definitely impressive, but there are
many ways to get the computation time needed to perform this attack,
including Amazon's EC2, botnets, and other high powered computing systems.
It's not *that* much computation time.

> My take on this is that because the method required advances in
> cryptography and sophisticated hardware, it is unlikely that it could
> be exploited by attackers before the publication of the method, or
> the publication of equivalent improvements by other cryptographers. If
> these CAs stop issuing MD5 certs before this time, we will be OK. Once
> a CA stops issuing MD5 certs, it cannot be used for the attack. Its old
> MD5 certs are safe and there is no danger of future successful attacks
> along these lines. As the paper notes, changing to using random serial
> numbers may be an easier short-term fix.

I am worried that this may be too optimistic of an outlook. This attack
was known and discussed by at least two research teams for at least a year
(Dan Kaminsky, Meredith L. Patterson, and I worked out the attack at the
last CCC).

To be fully confident in the CA infrastructure, all certificates that have
delegated signing authority granted to them by a higher CA (using MD5 on
the certificate in question) should be audited to ensure they are not
malicious. This of course includes private certificate infrastructures,
too.

I would be extremely surprised if this attack had been performed prior to
the original chosen prefix work being published -- but since that time,
there has been plenty of opportunity for a malicious party to quietly
perform this attack in the wild.

--Len.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: A History of U.S. Communications Security

Pehr Söderman wrote:
> Freshly declassified and a rather interesting read:
>
> A History of U.S. Communications Security (Volumes I and II, 1973)
> David G. Boak Lectures, National Security Agency (NSA)
>
> http://www.governmentattic.org/2docs/Hist_US_COMSEC_Boak_NSA_1973.pdf
>
> (From Bruce Schneier/Governmentattic)

I like the informal style of the document, it's an easy read, even if
one is not an intelligence buff. In the first volume, all but the first
and last chapters are redacted (what is left is an introduction and
TEMPEST). The second volume is more intact, and has some history DES,
and a view on public key cryptography before affordable general
computers. Certainly other things of which I don't realize the
significance...

Some of the redactions may be easily guessable, I fancy "iron curtain",
"embassy", and later "Russia" on page 97. Why do they even bother?
This would be a good exercise for some student to write a program doing
a dictionary attack on the text using the properties of the used font.

The last page has a puzzle, an "innocent text system" (steganography).
Didn't solve it yet, but I think I found the clue, a misspelling of "be
advised" to "he advised".

Thanks,
Marcus

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Thursday, January 01, 2009

Re: Security by asking the drunk whether he's drunk

At 10:19 PM -0500 12/30/08, Jerry Leichter wrote:
>Robert Graham writes in Errata Security (http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) that the attack depends on being able to predict the serial number field that will be assigned to a legitimate certificate by the CA.

That part is true.

>Only a few CA's use predictable "serial numbers"

That part, I think, is wrong. I looked into this a bit earlier this month and found that most of the ones I looked at are still using sequential numbers.

>- the field is actually arbitrary text

If by "arbitrary text" you mean "a non-negative integer".

>and need only be certainly unique among all certificates issued by a given CA.

True as well.

>So: The current attack is only effective against a very small number of CA's which both use MD5 *and* have predictable sequence numbers.

The attack is on end users who trust a root store that has a trust anchor from *any single* CA that uses MD5 and has predictable sequence numbers. The attack lets the attacker become a subordinate CA for that CA. At that point, the attacker can issue their own certs for any purpose.

>So the sky isn't falling

It never does. That's why it is the sky.

>- though given how hard it is to "decertify" a CA (given that the "known good" CA's are known to literally billions of pieces of software, and that hardly anyone checks CRL's - and are there even CRL's for CA's?) this is certainly not a good situation.

There are not CRLs for CAs. That's why is it is a root store.

Oh, and how do you create a definitive list of CAs that use MD5 in their signatures?

>This also doesn't mean that, now that the door has been opened, other attacks won't follow. In fact, it's hard to imagine that this is the end of the story....

Quite right.

--Paul Hoffman, Director
--VPN Consortium

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

enigma simulator in flash

http://enigmaco.de/enigma/enigma.swf

Hat Tip: Robert Hettinga

--
Perry E. Metzger perry@piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Tuesday, December 30, 2008

Re: Security by asking the drunk whether he's drunk

On Dec 30, 2008, at 4:21 PM, Sidney Markowitz wrote:

> Sidney Markowitz wrote, On 31/12/08 10:08 AM:
>> or that CA root certs that use MD5 for their hash are
>> still in use and have now been cracked?
>
> I should remember -- morning coffee first, then post.
>
> The CA root certs themselves have not been cracked -- It is the
> digital
> signatures created by some CAs who still use MD5 to sign the certs
> that
> they issue that have been hacked: The known weakness in MD5 allows one
> to create two certs with the same MD5 hash, one that is legitimate to
> get signed by the CA, and another one for rogue use that can be given
> the same signature.
Robert Graham writes in Errata Security (http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html
) that the attack depends on being able to predict the serial number
field that will be assigned to a legitimate certificate by the CA.
Only a few CA's use predictable "serial numbers" - the field is
actually arbitrary text and need only be certainly unique among all
certificates issued by a given CA.

Of course, we've seen in the past that having too much freedom to
insert "known to be random" (hence uncheckable) stuff into a signed
piece of text can itself be hazardous in other ways.

So: The current attack is only effective against a very small number
of CA's which both use MD5 *and* have predictable sequence numbers.
So the sky isn't falling - though given how hard it is to "decertify"
a CA (given that the "known good" CA's are known to literally billions
of pieces of software, and that hardly anyone checks CRL's - and are
there even CRL's for CA's?) this is certainly not a good situation.

This also doesn't mean that, now that the door has been opened, other
attacks won't follow. In fact, it's hard to imagine that this is the
end of the story....
-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD5 considered harmful today

At Tue, 30 Dec 2008 11:51:06 -0800 (PST),
"Hal Finney" wrote:
> Therefore the highest priority should be for the six bad CAs to change
> their procedures, at least start using random serial numbers and move
> rapidly to SHA1. As long as this happens before Eurocrypt or whenever
> the results end up being published, the danger will have been averted.
> This, I think, is the main message that should be communicated from this
> important result.

VeriSign says that they have already fixed RapidSSL:

https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php

Q: How will VeriSign mitigate this problem?

A: VeriSign has removed this vulnerability. As of shortly before this
posting, the attack laid out this morning in Berlin cannot be
successful against any RapidSSL certificate nor any other SSL
Certificate that VeriSign sells under any brand.


Q: Does that mean VeriSign has discontinued use of MD5?

A: We have been in the process of phasing out the MD5 hashing
algorithm for a long time now. MD5 is not in use in most VeriSign
certificates for most applications, and until this morning our roadmap
had us discontinuing the last use of MD5 in our customers'
certificates before the end of January, 2009. Today's presentation
showed how to combine MD5 collision attacks with some other clever
bits of hacking to create a false certificate. We have discontinued
using MD5 when we issue RapidSSL certificates, and we've confirmed
that all other SSL Certificates we sell are not vulnerable to this
attack. We'll continue on our path to discontinue MD5 in all end
entity certificates by the end of January, 2009.

Incidentally, I most of the CAs names in Slide 19 are VeriSign
brands. In particular RapidSSL, RSA, Thawte, and Verisign.co.jp are
and I believe that FreeSSL is as well.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: very high speed hardware RNG

On Dec 30, 2008, at 2:11 PM, Jerry Leichter wrote:

> On Dec 30, 2008, at 4:40 PM, Jon Callas wrote:
>> We don't have a formal definition of what we mean by random. My
>> definition is that it needs to be unguessable. If I have a random
>> number and the work factor for you to guess it is more or less its
>> randomness. It's a Shannonesque way of looking things, but not
>> precisely information-theoretic.
> I don't think this quite captures the situation. It's easy to give
> a formal definition of randomness; it's just not clear that such a
> thing can ever be realized.

And that is, pretty much, the point. A formal definition that is no
guidance to people trying to build things is mathematics as art. Not
that art is a bad thing -- I adore mathematics as art, and my time as
a mathematician was all in the art department. It's just not useful to
the part of me that's an engineer. Pretty has worth, just different
worth than useful.

>
>
> Here's one definition: A random bitstream generator is an
> "isolated" source of an infinite stream of bits, numbered starting
> at zero, with the property that a Turing machine, given as input
> anything about the universe except the internal state of the
> "isolated" source, and bits 0 to n generated by the source, has no
> better than a 50% chance of correctly guessing bit n+1. The
> difficulty is entirely in that quoted "isolated". It's not so much
> that we can't define it as that given any definition that captures
> the intended meaning, there are no known systems that we can
> definitely say are "isolated" in that sense. (Well, there's kind of
> an exception: Quantum mechanics tells us that the outcome of
> certain experiments is "random", and Bell's Theorem gives us some
> kind of notion of "isolation" by saying there are no hidden
> variables - but this is very technically complex and doesn't really
> say anything nearly so simple.)
>
> A while back, I wrote to this list about some work toward a stronger
> notion of "computable in principle", based on results in quantum
> mechanics that limit the amount of computation - in the very basic
> sense of bit flips - that can be done in a given volume of space-
> time. The argument is that a computation that needs more than this
> many bit flips can't reasonably be defined as possible "in
> principle" just because we can describe what such a computation
> would look like, if the universe permitted it! One might produce a
> notion of "strongly computationally random" based on such a theory.
> Curiously, as I remarked i that message, somewhere between 128 and
> 256 bits of key, a brute force search transitions from "impractical
> for the forseeable future" to "not computable in principle". So at
> least for brute force attacks - we're actually at the limits
> already. Perhaps it might actually be possible to construct such a
> "random against any computation that's possible in principle" source.
>
>> A deterministic, but chaotic system that is sufficiently opaque
>> gets pretty close to random. Let's just suppose that the model they
>> give of photons bouncing in their laser is Newtonian. If there's
>> enough going on in there, we can't model it effectively and it can
>> be considered random because we can't know its outputs.
> I don't like the notion of "opaqueness" in the context. That just
> means we can't see any order that might be in there. There's a
> classic experiment - I think Scientific American had pictures of
> this maybe 10 years back - in which you take a pair of concentric
> cylinders, fill the gap with a viscous fluid in which you draw a
> line with dye parallel to the cylinders' common axis. Now slowly
> turn the inner cylinder, dragging the dye along. This is a highly
> chaotic process, and after a short time, you see a completely random-
> looking dispersion of dye through the liquid. Present this to
> someone and any likely test will say this is quite random. But ...
> if you slow turn the inner cylinder backwards - "slowly", for both
> directions of turn, depending on details of the system - the
> original line of dye miraculously reappears.
>
> That's why it's not enough to have chaos, not enough to have
> opaqueness. The last thing you want to say is "this system is so
> complicated that I can't model it, so my opponent can't model it
> either, so it's random". To the contrary, you *want* a model that
> tells you something about *why* this system is hard to predict!

Exactly. You've described a chaotic but easily reversible system, and
that makes it unsuitable to be random by my "unguessability" metric.
There exists an algorithm that's faster than guessing, and so
therefore it isn't random.

>
>
>> However, on top of that, there's a problem that hardware people
>> (especially physicists) just don't get about useful randomness,
>> especially cryptographic random variables. Dylan said that to live
>> outside the law, you must be honest. A cryptographic random
>> variable has to look a certain way, it has to be honest. It's got
>> to be squeaky clean in many ways. A true random variable does not.
>> A true random variable can decide that it'll be evenly distributed
>> today, normal tomorrow, or perhaps Poisson -- the way we decide
>> what restaurant to go to. No, no, not Italian; I had Italian for
>> lunch.
>>
>> That's why we cryptographers always run things through a lot of
>> software. It's also why we want to see our hardware randomness, so
>> we can correct for the freedom of the physical process. Imagine a
>> die that is marked with a 1, four 4s, and a 5. This die is crap to
>> play craps with, but we can still feed an RNG with it. We just need
>> to know that it's not what it seems.
> This simply says that *known* bias and randomness are completely
> separate notions. I can always get rid of any *known* bias. Bias
> that's unknown/unmodeled to me as the *user* of the system, on the
> other hand, is very dangerous if an attacker might conceivably know
> more about the bias than I do.

Yes. Again, we're in agreement on this.

If I think some system is unguessable to 256 bits, and it's really
unguessable to 10 bits, then someone who knows those ten bits can
easily search for a state that I think is unsearchable. (At least in
principle -- ten bits worth of calculations that take a century each
is a different thing entirely, but that's only because centuries are
longer than nanoseconds.)

Jon


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: very high speed hardware RNG

On Dec 30, 2008, at 4:40 PM, Jon Callas wrote:
> We don't have a formal definition of what we mean by random. My
> definition is that it needs to be unguessable. If I have a random
> number and the work factor for you to guess it is more or less its
> randomness. It's a Shannonesque way of looking things, but not
> precisely information-theoretic.
I don't think this quite captures the situation. It's easy to give a
formal definition of randomness; it's just not clear that such a thing
can ever be realized.

Here's one definition: A random bitstream generator is an "isolated"
source of an infinite stream of bits, numbered starting at zero, with
the property that a Turing machine, given as input anything about the
universe except the internal state of the "isolated" source, and bits
0 to n generated by the source, has no better than a 50% chance of
correctly guessing bit n+1. The difficulty is entirely in that quoted
"isolated". It's not so much that we can't define it as that given
any definition that captures the intended meaning, there are no known
systems that we can definitely say are "isolated" in that sense.
(Well, there's kind of an exception: Quantum mechanics tells us that
the outcome of certain experiments is "random", and Bell's Theorem
gives us some kind of notion of "isolation" by saying there are no
hidden variables - but this is very technically complex and doesn't
really say anything nearly so simple.)

A while back, I wrote to this list about some work toward a stronger
notion of "computable in principle", based on results in quantum
mechanics that limit the amount of computation - in the very basic
sense of bit flips - that can be done in a given volume of space-
time. The argument is that a computation that needs more than this
many bit flips can't reasonably be defined as possible "in principle"
just because we can describe what such a computation would look like,
if the universe permitted it! One might produce a notion of "strongly
computationally random" based on such a theory. Curiously, as I
remarked i that message, somewhere between 128 and 256 bits of key, a
brute force search transitions from "impractical for the forseeable
future" to "not computable in principle". So at least for brute force
attacks - we're actually at the limits already. Perhaps it might
actually be possible to construct such a "random against any
computation that's possible in principle" source.

> A deterministic, but chaotic system that is sufficiently opaque gets
> pretty close to random. Let's just suppose that the model they give
> of photons bouncing in their laser is Newtonian. If there's enough
> going on in there, we can't model it effectively and it can be
> considered random because we can't know its outputs.
I don't like the notion of "opaqueness" in the context. That just
means we can't see any order that might be in there. There's a
classic experiment - I think Scientific American had pictures of this
maybe 10 years back - in which you take a pair of concentric
cylinders, fill the gap with a viscous fluid in which you draw a line
with dye parallel to the cylinders' common axis. Now slowly turn the
inner cylinder, dragging the dye along. This is a highly chaotic
process, and after a short time, you see a completely random-looking
dispersion of dye through the liquid. Present this to someone and any
likely test will say this is quite random. But ... if you slow turn
the inner cylinder backwards - "slowly", for both directions of turn,
depending on details of the system - the original line of dye
miraculously reappears.

That's why it's not enough to have chaos, not enough to have
opaqueness. The last thing you want to say is "this system is so
complicated that I can't model it, so my opponent can't model it
either, so it's random". To the contrary, you *want* a model that
tells you something about *why* this system is hard to predict!

> However, on top of that, there's a problem that hardware people
> (especially physicists) just don't get about useful randomness,
> especially cryptographic random variables. Dylan said that to live
> outside the law, you must be honest. A cryptographic random variable
> has to look a certain way, it has to be honest. It's got to be
> squeaky clean in many ways. A true random variable does not. A true
> random variable can decide that it'll be evenly distributed today,
> normal tomorrow, or perhaps Poisson -- the way we decide what
> restaurant to go to. No, no, not Italian; I had Italian for lunch.
>
> That's why we cryptographers always run things through a lot of
> software. It's also why we want to see our hardware randomness, so
> we can correct for the freedom of the physical process. Imagine a
> die that is marked with a 1, four 4s, and a 5. This die is crap to
> play craps with, but we can still feed an RNG with it. We just need
> to know that it's not what it seems.
This simply says that *known* bias and randomness are completely
separate notions. I can always get rid of any *known* bias. Bias
that's unknown/unmodeled to me as the *user* of the system, on the
other hand, is very dangerous if an attacker might conceivably know
more about the bias than I do.

> So yeah -- it's a glib confusion between chaotic and random, but
> chaotic enough might be good enough. And the assumption that
> hardware can just be used is bad. Hardware that helpfully whitens is
> worse.
>
> Jon

-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: very high speed hardware RNG

>
> The thing that bothers me about this description is the too-easy
> jump between "chaotic" and "random". They're different concepts,
> and chaotic doesn't imply random in a cryptographic sense: It may
> be possible to induce bias or even some degree of predictability in
> a chaotic system by manipulating its environment. I believe there
> are also chaotic systems that are hard to predict in the forward
> direction, but easy to run backwards, at least sometimes.
>
> That's not to say this system isn't good - it probably is - but just
> saying its chaotic shouldn't be enough.
>

You are saying pretty much what I've been saying about this (and some
other things).

We don't have a formal definition of what we mean by random. My
definition is that it needs to be unguessable. If I have a random
number and the work factor for you to guess it is more or less its
randomness. It's a Shannonesque way of looking things, but not
precisely information-theoretic.

A deterministic, but chaotic system that is sufficiently opaque gets
pretty close to random. Let's just suppose that the model they give of
photons bouncing in their laser is Newtonian. If there's enough going
on in there, we can't model it effectively and it can be considered
random because we can't know its outputs.

However, on top of that, there's a problem that hardware people
(especially physicists) just don't get about useful randomness,
especially cryptographic random variables. Dylan said that to live
outside the law, you must be honest. A cryptographic random variable
has to look a certain way, it has to be honest. It's got to be squeaky
clean in many ways. A true random variable does not. A true random
variable can decide that it'll be evenly distributed today, normal
tomorrow, or perhaps Poisson -- the way we decide what restaurant to
go to. No, no, not Italian; I had Italian for lunch.

That's why we cryptographers always run things through a lot of
software. It's also why we want to see our hardware randomness, so we
can correct for the freedom of the physical process. Imagine a die
that is marked with a 1, four 4s, and a 5. This die is crap to play
craps with, but we can still feed an RNG with it. We just need to know
that it's not what it seems.

So yeah -- it's a glib confusion between chaotic and random, but
chaotic enough might be good enough. And the assumption that hardware
can just be used is bad. Hardware that helpfully whitens is worse.

Jon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Security by asking the drunk whether he's drunk

Sidney Markowitz wrote, On 31/12/08 10:08 AM:
> or that CA root certs that use MD5 for their hash are
> still in use and have now been cracked?

I should remember -- morning coffee first, then post.

The CA root certs themselves have not been cracked -- It is the digital
signatures created by some CAs who still use MD5 to sign the certs that
they issue that have been hacked: The known weakness in MD5 allows one
to create two certs with the same MD5 hash, one that is legitimate to
get signed by the CA, and another one for rogue use that can be given
the same signature.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Steve Bellovin on the MD5 Collision attacks, more on Wired

http://www.cs.columbia.edu/~smb/blog//2008-12/2008-12-30.html

Steve mentions the social pressures involved in disclosing the vulnerability:

Verisign, in particular, appears to have been caught short. One of the CAs
they operate still uses MD5. They said:

The RapidSSL certificates are currently using the MD5 hash function
today. And the reason for that is because when you're dealing with
widespread technology and [public key infrastructure] technology, you have
phase-in and phase-out processes that cane take significant periods of
time to implement.

...
[4 years?]

Legal pressure? Sotirov and company are not "hackers"; they're respected
researchers. But the legal climate is such that they feared an injunction.
Nor are such fears ill-founded; others have had such trouble. Verisign isn't
happy: "We're a little frustrated at Verisign that we seem to be the only
people not briefed on this". But given that the researchers couldn't know
how Verisign would react, in today's climate they felt they had to be cautious.

This is a dangerous trend. If good guys are afraid to find flaws in fielded
systems, that effort will be left to the bad guys. Remember that for
academics, publication is the only way they're really "paid". We need a
legal structure in place to protect security researchers. To paraphrase an
old saying, security flaws don't crack systems, bad guys do.

--

The researchers provided information under NDA to browser manufacturers and
Microsoft contacted Verisign providing no real details
(http://blog.wired.com/27bstroke6/2008/12/berlin.html , the Wired article.):

Callan confirms Versign was contacted by Microsoft, but he says the NDA
prevented the software-maker from providing any meaningful details on the
threat. "We're a little frustrated at Verisign that we seem to be the only
people not briefed on this," he says.

The researchers expect that their forged CA certificate will be revoked by
Verisign following their talk, rendering it powerless. As a precaution, they
set the expiration date on the certificate to August 2004, ensuring that any
website validated through the bogus certificate would generate a warning
message in a user's browser.

---

The 2007 paper http://www.win.tue.nl/hashclash/EC07v2.0.pdf

Chosen-prefix Collisions for MD5 and Colliding X.509 Certificates for Different
Identities, Marc Stevens , Arjen Lenstra , and Benne de Weger

(also from the Wired article)

--

Nate Lawson's comments
http://rdist.root.org/2008/12/30/forged-ca-cert-talk-at-25c3/
To paraphrase Gibson, "Crypto security is available already, it just isn't
equally distributed."


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: MD5 considered harmful today

Re: http://www.win.tue.nl/hashclash/rogue-ca/

Key facts:

- 6 CAs were found still using MD5 in 2008: RapidSSL, FreeSSL, TC
TrustCenter AG, RSA Data Security, Thawte, verisign.co.jp. "Out of the
30,000 certificates we collected, about 9,000 were signed using MD5,
and 97% of those were issued by RapidSSL." RapidSSL was used for the
attack.

- The attack relies on cryptographic advances in the state of the art for
finding MD5 collisions from inputs with different prefixes. These advances
are not yet being published but will presumably appear in 2009.

- The collision was found using Arjen Lenstra's PlayStation Lab and used
200 PS3s with collectively 30 GB of memory. The attack is in two parts,
a new preliminary "birthdaying" step which is highly parallelizable and
required 18 hours on the PS3s, and a second stage which constructs the
actual collision using 3 MD5 blocks and runs on a single quad core PC,
taking 3 to 10 hours.

- The attack depends on guessing precisely the issuing time and serial
number of the "good" certificate, so that a colliding "rogue"
certificate can be constructed in advance. The time was managed
by noting that the cert issuing time was reliably 6 seconds after
the request was sent. The serial number was managed because RapidSSL
uses serially incrementing serial numbers. They guessed what serial
number would be in use 3 days hence, and bought enough dummy certs
just before the real one that hopefully the guessed serial number would
be hit.

- The attacks were mounted on the weekend, when cert issuance rates are
lower. It took 4 weekends before all the timing and guessing worked right.
The cert was issued November 3, 2008, and the total cert-purchase cost was
$657.

- The rogue cert, which has the basicConstraints CA field set to TRUE, was
intentionally back-dated to 2004 so even if the private key were stolen,
it could not be misused.

My take on this is that because the method required advances in
cryptography and sophisticated hardware, it is unlikely that it could
be exploited by attackers before the publication of the method, or
the publication of equivalent improvements by other cryptographers. If
these CAs stop issuing MD5 certs before this time, we will be OK. Once
a CA stops issuing MD5 certs, it cannot be used for the attack. Its old
MD5 certs are safe and there is no danger of future successful attacks
along these lines. As the paper notes, changing to using random serial
numbers may be an easier short-term fix.

Therefore the highest priority should be for the six bad CAs to change
their procedures, at least start using random serial numbers and move
rapidly to SHA1. As long as this happens before Eurocrypt or whenever
the results end up being published, the danger will have been averted.
This, I think, is the main message that should be communicated from this
important result.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Researchers Use PlayStation Cluster to Forge a Web Skeleton Key

http://blog.wired.com/27bstroke6/2008/12/berlin.html

More coverage on the MD5 collisions.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Researchers Show How to Forge Site Certificates |

http://www.freedom-to-tinker.com/blog/felten/researchers-show-how-forge-site-certificates

By Ed Felten - Posted on December 30th, 2008 at 11:18 am

Today at the Chaos Computing Congress, a group of researchers (Alex Sotirov,
Marc Stevens, Jake Appelbaum, Arjen Lenstra, Benne de Weger, and David
Molnar) announced that they have found a way to forge website certificates
that will be accepted as valid by most browsers. This means that they can
successfully impersonate any website, even for secure connections.


---

Through the use of MD5 collisions. The slides from the presentation are
available here:

http://events.ccc.de/congress/2008/Fahrplan/events/3023.en.html

The presentation entitled "MD5 considered harmful today, Creating a rogue CA
Certificate"

The collisions were found with a cluster of 200 PlayStation 3's. (slide
number 3, see slide number 25 for a picture of the cluster, a collision
taking one to two days)

They apparently did a live demo using forged certificates in a man in the
middle attack using a wireless network during the demonstration with access
by the audience. (slide number 5)

CAs still using MD5 in 2008: (slide number 19)
? RapidSSL
? FreeSSL
? TrustCenter
? RSA Data Security
? Thawte
? verisign.co.jp


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: very high speed hardware RNG

On Tue, Dec 30, 2008 at 11:45:27AM -0500, Steven M. Bellovin wrote:

> Of course, every time a manufacturer has tried it, assorted people
> (including many on this list) complain that it's been sabotaged by the
> NSA or by alien space bats or some such.

Well, maybe it has. Or maybe it was just not competently implemented,
or perhaps it has a failure mode that was not accounted for. The
design might be perfect but the physical implementation that happens
to be in your computer has a manufacturing flaw such that if the CPU
core voltage is slightly low and the ambient temperature is above 95F,
the raw output becomes biased from a uniform distribution in a subtle
way - how do you detect something like that? I personally would not
trust the direct output of any physical hardware source for anything,
precisely because you cannot measure it, or test for failures, in any
meaningful way. That does not mean it is not a useful thing to have.

> It's not obvious to me that you're right. In particular, we need to
> consider how such an instruction would interact with a virtual machine
> hypervisor. Is it a bug or a feature that the hypervisor can't
> intercept the request? Remember that reproducibility is often a virtue.

We already have this problem with rdtsc and equivalent cycle counter
reading instructions. ISTR that some architectures allow the kernel to
forbid access to the cycle counter - if so, similar techniques could
be used for a rdrandom instruction. For those that don't, the
non-reproducability ship has already sailed (think of rdtsc as a
rdrandom that has a very bad probability distribution).

Reproducability is sometimes a virtue, but sometimes not. I recall
discussions last year, I believe on this list, about how to design a
PRNG that was able to safely deal with VM state rollbacks. A
user-accessible RNG instruction would easily alleviate this problem.

> The JVM could just as easily open /dev/urandom today.

Except when it doesnt exist - in which case most Java software seems
to default to things like seeding a PRNG with the timestamp, because
the other alternatives that are feasible in Java, like interleaving
counter reads among multiple threads, are slow, difficult to implement
correctly, and even more difficult to test.

-Jack

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

MD5 considered harmful today

-----BEGIN PGP SIGNATURE-----

iD8DBQFJWlG7uIQakZ0PrOQRCka3AJwICK6zOA0V1SiiEFpDeK4WUNYaBQCfRdYq
GDnHudTF3lPBOwZec+Mdo1c=
=XRLo
-----END PGP SIGNATURE-----
Hello,

I wanted to chime in more during the previous x509 discussions but I was
delayed by some research.

I thought that I'd like to chime in that this new research about
attacking x509 is now released. We gave a talk about it at the 25c3
about an hour or two ago.

MD5 considered harmful today: Creating a rogue CA certificate

Nearly everything is here:
http://www.win.tue.nl/hashclash/rogue-ca/

Best,
Jacob

Re: very high speed hardware RNG

On Sun, 28 Dec 2008 23:49:06 -0500
Jack Lloyd <lloyd@randombit.net> wrote:

> On Sun, Dec 28, 2008 at 08:12:09PM -0500, Perry E. Metzger wrote:
> >
> > Semiconductor laser based RNG with rates in the gigabits per second.
> >
> > http://www.physorg.com/news148660964.html
> >
> > My take: neat, but not as important as simply including a decent
> > hardware RNG (even a slow one) in all PC chipsets would be.

Of course, every time a manufacturer has tried it, assorted people
(including many on this list) complain that it's been sabotaged by the
NSA or by alien space bats or some such.

> I've been thinking that much better than a chipset addition (which is
> only accessible by the OS kernel in most environments) would be a
> simple ring-3 (or equivalent) accessible instruction that writes 32 or
> 64 bits of randomness from a per-core hardware RNG, something like
>
> ; write 32 bits of entropy from the hardware RNG to eax register
> rdrandom %eax
>
> Which would allow user applications to access a good hardware RNG
> directly, in addition to allowing the OS to read bits to seed the
> system PRNG (/dev/random, CryptoGenRandom, or similar)

It's not obvious to me that you're right. In particular, we need to
consider how such an instruction would interact with a virtual machine
hypervisor. Is it a bug or a feature that the hypervisor can't
intercept the request? Remember that reproducibility is often a virtue.
>
> I think the JVM in particular could benefit from such an extension, as
> the abstractions it puts into place otherwise prevent most of the
> methods one might use to gather high-quality entropy for a PRNG seed.
>
The JVM could just as easily open /dev/urandom today.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Fw: [saag] Further MD5 breaks: Creating a rogue CA certificate

Begin forwarded message:

Date: Tue, 30 Dec 2008 11:05:28 -0500
From: Russ Housley <housley@vigilsec.com>
To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org
Subject: [saag] Further MD5 breaks: Creating a rogue CA certificate


http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today
Creating a rogue CA certificate

December 30, 2008

Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
Weger

We have identified a vulnerability in the Internet Public Key
Infrastructure (PKI) used to issue digital certificates for secure
websites. As a proof of concept we executed a practical attack
scenario and successfully created a rogue Certification Authority
(CA) certificate trusted by all common web browsers. This certificate
allows us to impersonate any website on the Internet, including
banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic
hash function that allows the construction of different messages with
the same MD5 hash. This is known as an MD5 "collision". Previous work
on MD5 collisions between 2004 and 2007 showed that the use of this
hash function in digital signatures can lead to theoretical attack
scenarios. Our current work proves that at least one attack scenario
can be exploited in practice, thus exposing the security
infrastructure of the web to realistic threats.

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Short announcement: MD5 considered harmful today - Creating a rogue CA certificate

Hi all,

Today, 30 December 2008, at the 25th Annual Chaos Communication Congress in Berlin,
we announced that we are currently in possession of a rogue Certification
Authority certificate. This certificate will be accepted as valid and trusted by
all common browsers, because it appears to be signed by one of the commercial root
CAs that browsers trust by default. We were able to do so by constructing a
collision for the MD5 hash function, obtaining a valid CA signature in a website
certificate legitimately purchased from the commercial CA, and copying this
signature into a CA certificate constructed by us such that the signature remains
valid.

For more information about this project, see http://www.win.tue.nl/hashclash/rogue-ca/.

The team consists of:

Alexander Sotirov (independent security researcher, New York, USA),
Marc Stevens (CWI, Amsterdam, NL),
Jacob Appelbaum (Noisebridge, The Tor Project, San Francisco, USA),
Arjen Lenstra (EPFL, Lausanne, CH),
David Molnar(UCB, Berkeley, USA),
Dag Arne Osvik (EPFL, Lausanne, CH),
Benne de Weger (TU/e, Eindhoven, NL).

For press and general inquiries, please email md5-collisions@phreedom.org.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

FBI "code"-cracking contest

http://www.networkworld.com/community/node/36704


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Monday, December 29, 2008

Re: Security by asking the drunk whether he's drunk

On Tue, Dec 30, 2008 at 4:25 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Ben Laurie <benl@google.com> writes:
>
>>what happens when the cert rolls? If the key also changes (which would seem
>>to me to be good practice), then the site looks suspect for a while.
>
> I'm not aware of any absolute figures for this but there's a lot of anecdotal
> evidence that many cert renewals just re-certify the same key year in, year
> out (there was even a lawsuit over the definition of the term "renewal" in
> certificates a few years ago). So you could in theory handle this by making a
> statement about the key rather than the whole cert it's in. OTOH this then
> requires the crawler to dig down into the data structure (SSH, X.509,
> whatever) to pick out the bits corresponding to the key.

Not really a serious difficulty.

> Other alternatives
> are to use a key-rollover mechanism that signs the new key with old one
> (something that I've proposed for SSH, since their key-continuity model kinda
> breaks at that point), and all the other crypto rube-goldbergisms you can
> dream up.

Yeah, that's pretty much the answer I came up with - another option
would be to use both the old and new certs for a while.

But signing the new with the old seems easiest to implement - the
signature can go in an X509v3 extension, which means CAs can sign it
without understanding it, and only Google has to be able to verify it,
so all that needs to change is CSR generating s/w...

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Security by asking the drunk whether he's drunk

Ben Laurie <benl@google.com> writes:

>what happens when the cert rolls? If the key also changes (which would seem
>to me to be good practice), then the site looks suspect for a while.

I'm not aware of any absolute figures for this but there's a lot of anecdotal
evidence that many cert renewals just re-certify the same key year in, year
out (there was even a lawsuit over the definition of the term "renewal" in
certificates a few years ago). So you could in theory handle this by making a
statement about the key rather than the whole cert it's in. OTOH this then
requires the crawler to dig down into the data structure (SSH, X.509,
whatever) to pick out the bits corresponding to the key. Other alternatives
are to use a key-rollover mechanism that signs the new key with old one
(something that I've proposed for SSH, since their key-continuity model kinda
breaks at that point), and all the other crypto rube-goldbergisms you can
dream up.

In any case though at the moment we have basically no assurance at all of
key/cert information so even a less-than-perfect mechanism like trusting
Google and having problems during cert rollover is way, way better than what
we've got now. In any case if Google decides to go bad then redirecting
everyone's searches to www.drivebymalware.ru is a bigger worry than whether
they're sending out inaccurate Perspectives responses.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Security by asking the drunk whether he's drunk

On Mon, Dec 29, 2008 at 10:10 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> David Molnar <dmolnar@eecs.berkeley.edu> writes:
>
>>Service from a group at CMU that uses semi-trusted "notary" servers to
>>periodically probe a web site to see which public key it uses. The notaries
>>provide the list of keys used to you, so you can attempt to detect things
>>like a site that has a different key for you than previously shown to all of
>>the notaries. The idea is that to fool the system, the adversary has to
>>compromise all links between the target site and the notaries all the time.
>
> I think this is missing the real contribution of Perspectives, which (like
> almost any security paper) has to include a certain quota of crypto rube-
> golbergism in order to satisfy conference reviewers. The real value isn't the
> multi-path verification and crypto signing facilities and whatnot but simply
> the fact that you now have something to deal with leap-of-faith
> authentication, whether it's for self-generated SSH or SSL keys or for rent-a-
> CA certificates. Currently none of these provide any real assurance since a
> phisher can create one on the fly as and when required. What Perspectives
> does is guarantee (or at least provide some level of confidence) that a given
> key has been in use for a set amount of time rather than being a here-this-
> morning, gone-in-the-afternoon affair like most phishing sites are. In other
> words a phisher would have to maintain their site for a week, a month, a year,
> of continuous operation, not just set it up an hour after the phishing email
> goes out and take it down again a few hours later.
>
> For this function just a single source is sufficient, thus my suggestion of
> Google incorporating it into their existing web crawling. You can add the
> crypto rube goldberg extras as required, but a basic "this site has been in
> operation at the same location with the same key for the past eight months" is
> a powerful bar to standard phishing approaches, it's exactly what you get in
> the bricks-and-mortar world, "Serving the industry since 1962" goes a lot
> further than "Serving the industry since just before lunchtime".

Two issues occur to me. Firstly, you have to trust Google (and your
path to Google).

Secondly, and this seems to me to be a generic issue with Perspectives
and SSL - what happens when the cert rolls? If the key also changes
(which would seem to me to be good practice), then the site looks
suspect for a while.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Security by asking the drunk whether he's drunk

David Molnar <dmolnar@eecs.berkeley.edu> writes:

>Service from a group at CMU that uses semi-trusted "notary" servers to
>periodically probe a web site to see which public key it uses. The notaries
>provide the list of keys used to you, so you can attempt to detect things
>like a site that has a different key for you than previously shown to all of
>the notaries. The idea is that to fool the system, the adversary has to
>compromise all links between the target site and the notaries all the time.

I think this is missing the real contribution of Perspectives, which (like
almost any security paper) has to include a certain quota of crypto rube-
golbergism in order to satisfy conference reviewers. The real value isn't the
multi-path verification and crypto signing facilities and whatnot but simply
the fact that you now have something to deal with leap-of-faith
authentication, whether it's for self-generated SSH or SSL keys or for rent-a-
CA certificates. Currently none of these provide any real assurance since a
phisher can create one on the fly as and when required. What Perspectives
does is guarantee (or at least provide some level of confidence) that a given
key has been in use for a set amount of time rather than being a here-this-
morning, gone-in-the-afternoon affair like most phishing sites are. In other
words a phisher would have to maintain their site for a week, a month, a year,
of continuous operation, not just set it up an hour after the phishing email
goes out and take it down again a few hours later.

For this function just a single source is sufficient, thus my suggestion of
Google incorporating it into their existing web crawling. You can add the
crypto rube goldberg extras as required, but a basic "this site has been in
operation at the same location with the same key for the past eight months" is
a powerful bar to standard phishing approaches, it's exactly what you get in
the bricks-and-mortar world, "Serving the industry since 1962" goes a lot
further than "Serving the industry since just before lunchtime".

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Sunday, December 28, 2008

Re: very high speed hardware RNG

On Sun, Dec 28, 2008 at 08:12:09PM -0500, Perry E. Metzger wrote:
>
> Semiconductor laser based RNG with rates in the gigabits per second.
>
> http://www.physorg.com/news148660964.html
>
> My take: neat, but not as important as simply including a decent
> hardware RNG (even a slow one) in all PC chipsets would be.

I've been thinking that much better than a chipset addition (which is
only accessible by the OS kernel in most environments) would be a
simple ring-3 (or equivalent) accessible instruction that writes 32 or
64 bits of randomness from a per-core hardware RNG, something like

; write 32 bits of entropy from the hardware RNG to eax register
rdrandom %eax

Which would allow user applications to access a good hardware RNG
directly, in addition to allowing the OS to read bits to seed the
system PRNG (/dev/random, CryptoGenRandom, or similar)

I think the JVM in particular could benefit from such an extension, as
the abstractions it puts into place otherwise prevent most of the
methods one might use to gather high-quality entropy for a PRNG seed.

-Jack

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: very high speed hardware RNG

On Dec 28, 2008, at 8:12 PM, Perry E. Metzger wrote:

>
> Semiconductor laser based RNG with rates in the gigabits per second.
>
> http://www.physorg.com/news148660964.html
>
> My take: neat, but not as important as simply including a decent
> hardware RNG (even a slow one) in all PC chipsets would be.
True.

The thing that bothers me about this description is the too-easy jump
between "chaotic" and "random". They're different concepts, and
chaotic doesn't imply random in a cryptographic sense: It may be
possible to induce bias or even some degree of predictability in a
chaotic system by manipulating its environment. I believe there are
also chaotic systems that are hard to predict in the forward
direction, but easy to run backwards, at least sometimes.

That's not to say this system isn't good - it probably is - but just
saying its chaotic shouldn't be enough.

BTW, a link from this article - at least when I looked at it - went to http://www.physorg.com/news147698804.html
: "Quantum Computing: Entanglement May Not Be Necessary". There are
still tons of surprises in the quantum computing arena....
-- Jerry


>
>
> Perry
> --
> Perry E. Metzger perry@piermont.com
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

very high speed hardware RNG

Semiconductor laser based RNG with rates in the gigabits per second.

http://www.physorg.com/news148660964.html

My take: neat, but not as important as simply including a decent
hardware RNG (even a slow one) in all PC chipsets would be.

Perry
--
Perry E. Metzger perry@piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Saturday, December 27, 2008

Re: Security by asking the drunk whether he's drunk

On Dec 27, 2008, at 10:02 AM, Ben Laurie wrote:

> On Fri, Dec 26, 2008 at 7:39 AM, Peter Gutmann
> <pgut001@cs.auckland.ac.nz> wrote:
> Adding support for a
>> service like Perspectives (discussed here a month or two back)
>> would be a good
>> start since it provides some of the assurance that a commercial PKI
>> can't (and
>> as an additional benefit it also works for SSH servers, since it's
>> not built
>> around certificates).
>>
>> So, when will Google add Perspectives support to their search
>> database? :-).
>
> I can't find discussion of Perspectives - hint?
Try http://www.cs.cmu.edu/~perspectives/perspectives_usenix08.pdf

-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Security by asking the drunk whether he's drunk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVpKUyyxj0uImQ6gRAuXwAJ9yqU/Z/ycuf178VR2IlGSY49qQSwCfWjox
VCFrws+Nk5juI1e+YA6AWQA=
=Wriw
-----END PGP SIGNATURE-----
Ben Laurie wrote:

>
> I can't find discussion of Perspectives - hint?

Service from a group at CMU that uses semi-trusted "notary" servers to
periodically probe a web site to see which public key it uses. The
notaries provide the list of keys used to you, so you can attempt to
detect things like a site that has a different key for you than
previously shown to all of the notaries. The idea is that to fool the
system, the adversary has to compromise all links between the target
site and the notaries all the time.

Paper, code, and Firefox extension:
http://www.cs.cmu.edu/~perspectives/

Re: Security by asking the drunk whether he's drunk

* Jerry Leichter:

> I got in touch with the company and actually received intelligent
> responses both at their 800 number - I placed my order that way - and
> in a response from their customer service people. Most remarkable -
> almost all organizations ignore such communication. It's ironic that
> those who appear to be trying the hardest are being screwed over by
> the system that's currently in place - and will inadvertently be
> involved in training users to simply bypass yet another kind of bad
> cert warning.

This is also why I don't want browser vendors to remove CAs for which
they haven't got enough documentation, at least at this stage. After
a few rounds of competitors attacking each other (and themselves as
well, because who knows who controls some of the older private keys
these days), the only CAs left are those where initiating RA
procedures is sufficiently difficult for law-abiding citizens--and
cost is a very likely discriminator in this area.

And for most sites, those extra $$$ are better spent on hosting with
some sort of security monitoring.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Domestic surveillance and warrantless wiretaps

Like many people, I found last week's Newsweek cover
piece, revealing Thomas M. Tamm as the principal source
for James Risen and Eric Lichtblau's 2005 NY Times story
that broke the warrantless wiretap story, to be a riveting
read.

But I actually found a sidebar to the story even more
interesting. That story talks about the now famous 2004
incident at Ashcroft's hospital bed in which several
top DoJ officials threatened to resign. It turns out
that was not about warrantless content collection,
but rather about the wholesale collection of call
records:

http://www.newsweek.com/id/174602/output/print

This story raises a number of new -- and ultimately
quite disturbing -- questions about the nature of the
wiretap program and the extent of its reach into the
domestic communication of innocent Americans. In
particular, put together with other reports about the
program, it seems to corroborate claims that telcos
(including my alma matter AT&T) provided the NSA with
wholesale access to domestic call detail records, and
that top DoJ officials worried seriously that this
violated the law.

I discuss the implications of this in more detail on
my blog; perhaps some here will find it interesting:

http://www.crypto.com/blog/metatapping

-matt

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Matt Blaze blog entry about NSA warrantless wiretapping

Interesting reading:

http://www.crypto.com/blog/metatapping/

--
Perry E. Metzger perry@piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: two bits of light holiday reading

On Fri, 26 Dec 2008 01:35:43 -0500
Ivan Krsti__ <krstic@solarsail.hcs.harvard.edu> wrote:


> 2.
>
> The DC-based Center for Strategic and International Studies recently
> released a report titled 'Securing Cyberspace for the 44th
> Presidency' written by a number of influential authors:
>
> <http://www.csis.org/media/csis/pubs/081208_securingcyberspace_44.pdf>
>
> Of most interest to this list, the report suggests going on the
> offensive with regard to identity management, proposing to restrict
> bonuses and awards of US federal agencies not using strong digital
> credentials for employees in sufficient numbers (logical pp. 61-65).
> Maybe, uh, it'll work this time around?

I disagree with a number of recommendations in that report; some of the
ones about identity management are high on my list. See
http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-15.html for my
comments.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com