Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-24 Thread Peter Gutmann
Eric Rescorla e...@networkresonance.com writes:
At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote:
 Steven M. Bellovin s...@cs.columbia.edu writes:

 So -- who supports TLS 1.2?

 Not a lot, I think.  The problem with 1.2 is that it introduces a pile of
 totally gratuitous incompatible changes to the protocol that require quite a
 bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not 
 a
 bigger step, than the change from SSL to TLS), complicate an implementation,
 are difficult to test because of the general lack of implementations
 supporting it, and provide no visible benefit.  Why would anyone rush to
 implement this when what we've got now works[0] just fine?

Ordinarily I wouldn't bother to respond to Peter's curmudgeon act,

:-).

but since I was obviously heavily involved with TLS 1.2, I think a bit of
context is in order.

I'm aware of why the changes were made, but the point of my comment was to
explain their consequences in the lack of support for TLS 1.2.  I had (AFAIK)
one of the first implementations of TLS 1.1, an incremental upgrade of TLS 1.0
(and then had some fun trying to find things to interop against) but for TLS
1.2 I haven't implemented it and have no plans to implement it because it
provides absolutely no benefit over TLS 1.1 and a great many downsides.

Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those
between SSL and TLS. I'm not particularly happy about that either, but it's
what we felt was necessary to do a principled job.

It may have been a nicely principled job but what actual problem is the switch
in hash algorithms actually solving?  Making changes of such magnitude to a
very, very widely-deployed protocol is always a tradeoff between the necessity
of the change and the pain of doing so.  In TLS 1.2 the pain is proportionate
to the scale of the existing deployed base (i.e. very large) and the necessity
of doing so appears to be zero.  I don't know of any attack or threat to the
existing dual-hash mechanism that TLS 1.2 addresses, and it may even make
things worse by switching from the redundant dual-hash (a testament to the
original SSL designers) to a single algorithm.  This is why I called the
changes gratuitous, there is no threat that they address - it can even be
argued (no doubt endlessly) that they make the PRF weaker rather than stronger
- but they come at considerable cost.

SSL/TLS is (and has been for many years) part of the Internet infrastructure.
You don't make significant, totally incompatible changes to the infrastructure
without very carefully weighing the advantages and disadvantages.  Maybe
there'll be a sudden flood of unexpected TLS 1.2 implementations right after I
post this, but at the moment it seems that implementors have weighed up the
cost and said no thanks.

Peter.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-24 Thread Ben Laurie
On Sat, Jan 24, 2009 at 2:36 AM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:
 You seem to be out of touch I am afraid. Just look at what many O/S
 distributions do. They adopt a new OpenSSL 0.9.Xy release from time to
 time (for some initial y) and back-port security fixes never changing
 the letter. One can't actually tell from openssl version what version
 one is running and which fixes have been applied.

 Why am I back-porting patch-sets to 0.9.8i? Is that because there is no
 demand for bugfix releases? There is indeed demand for real bugfix
 releases, just that people have gotten used to doing it themselves,
 but this is not very effective and is difficult to audit.

It is not that I am unaware of this, I was pointing out what we
actually do. But you do have a fair point and I will take it up with
the team.

However, I wonder how this is going to pan out? Since historically
pretty much every release has been prompted by a security issue, but
also includes new features and non-security bugfixes, in order to
release 0.9.8j the way you want us to, we would also have to test and
release security updates for 0.9.8 - 0.9.8i, for a total of 10
branched versions. I think this is asking rather a lot of volunteers!

Don't suggest that we should release feature/bugfix versions less
often, I think we already do that less often than we should.

Perhaps the answer is that we security patch every version that is
less than n months old, and end-of-life anything before that?
Suggestions for reasonable values of n?

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-24 Thread Eric Rescorla
At Sat, 24 Jan 2009 14:55:15 +1300,
Peter Gutmann wrote:
 Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those
 between SSL and TLS. I'm not particularly happy about that either, but it's
 what we felt was necessary to do a principled job.
 
 It may have been a nicely principled job but what actual problem is the switch
 in hash algorithms actually solving?  Making changes of such magnitude to a
 very, very widely-deployed protocol is always a tradeoff between the necessity
 of the change and the pain of doing so.  In TLS 1.2 the pain is proportionate
 to the scale of the existing deployed base (i.e. very large) and the necessity
 of doing so appears to be zero.  I don't know of any attack or threat to the
 existing dual-hash mechanism that TLS 1.2 addresses, and it may even make
 things worse by switching from the redundant dual-hash (a testament to the
 original SSL designers) to a single algorithm.  This is why I called the
 changes gratuitous, there is no threat that they address - it can even be
 argued (no doubt endlessly) that they make the PRF weaker rather than stronger
 - but they come at considerable cost.

I agree that given the current set of attacks on SHA-1 and MD5,
there was no existing attack on the protocol. However, that doesn't
mean that improvements in analysis wouldn't lead to such attacks
and so the general feeling of the community was to err on the
side of safety. No doubt if we hadn't done so, there would be
people screaming about how TLS still used MD5. Indeed, that's
how this thread started. So, once again, I don't share your
opinions about these changes being gratuitous.

Moreover, the bulk of the changes weren't to the PRF. That's actually
quite a trivial change to implement, but rather to have accurate
signalling about what combinations of hashes and signatures
implementations could support--something that was painfully
non-orthogonal in SSLv3 and earlier versions of TLS. Again,
one could argue that we could have hacked around this and indeed 
the original Bellovin-Rescorla paper described a number of such
hacks, but the general feeling of the TLS WG was that it was
more important to get it right.


 SSL/TLS is (and has been for many years) part of the Internet infrastructure.
 You don't make significant, totally incompatible changes to the infrastructure
 without very carefully weighing the advantages and disadvantages. 

Which we did--including having the very discussion we are having
now--and concluded that the course of action we took was the right
one. You're of course free to weigh the evidence yourself and come to
a different conclusion, and even to hold the opinion that those who
agree with you are complete fools, but it's simply not accurate to
imply, as you do here, that we didn't think about it.

-Ekr

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-23 Thread Ben Laurie
On Tue, Jan 20, 2009 at 5:14 AM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:
 On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote:

 The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256
 mandatory), so you can send a SHA-256 certificate to clients that
 indicate they support TLS 1.2 or later.  You'd still need some other
 certificate for interoperability with clients that don't support
 SHA-256, of course, and you'd be sending that one to clients that do
 support SHA-256 but not TLS 1.2.  (So you'd fall back to SHA-1, which
 is not really a problem when CAs make sure to use the hash algorithm
 in a way that doesn't rely on hash collisions being hard to find,
 which probably is a good idea for *any* hash algorithm.)

 It would be helpful if as a first step, SSL_library_init() (a.k.a.
 OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests,
 I would make this change in the 0.9.9 development snapshots.

 [ Off topic: I find OpenSSL release-engineering a rather puzzling
 process. The patch releases are in fact feature releases,

Who said they were patch releases?

 and there
 are no real patch releases even for critical security issues.  I chose
 to backport the 0.9.8j security fixes to 0.9.8i and sit out all the
 new FIPS code, ... This should not be necessary. I really hope to see
 real OpenSSL patch releases some day with development of new features
 *strictly* in the development snapshots. Ideally this will start with
 0.9.9a, with no new features, just bugfixes, in [b-z]. ]

I think that is not likely to happen, because that's not the way it
works. The promise we try to keep is ABI compatibility between
releases that have the same numbers. Letters signify new versions
within that series. We do not have a bugfix-only branch. There doesn't
seem to be much demand for one.


 --
Viktor.

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


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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-23 Thread Victor Duchovni
On Fri, Jan 23, 2009 at 04:01:50PM +1100, Ben Laurie wrote:

  I really hope to see
  real OpenSSL patch releases some day with development of new features
  *strictly* in the development snapshots. Ideally this will start with
  0.9.9a, with no new features, just bug-fixes, in [b-z]. ]
 
 I think that is not likely to happen, because that's not the way it
 works. The promise we try to keep is ABI compatibility between
 releases that have the same numbers. Letters signify new versions
 within that series. We do not have a bugfix-only branch. There doesn't
 seem to be much demand for one.

Don't want to start a long debate here, but I do want to respond to this.

You seem to be out of touch I am afraid. Just look at what many O/S
distributions do. They adopt a new OpenSSL 0.9.Xy release from time to
time (for some initial y) and back-port security fixes never changing
the letter. One can't actually tell from openssl version what version
one is running and which fixes have been applied.

Why am I back-porting patch-sets to 0.9.8i? Is that because there is no
demand for bugfix releases? There is indeed demand for real bugfix
releases, just that people have gotten used to doing it themselves,
but this is not very effective and is difficult to audit.

OpenSSL has not infrequent security advisories, and these are always fixed
in new feature releases not bugfix releases (which are misleadingly called
patch releases).

#define HEADER_OPENSSLV_H

/* Numeric release version identifier:
 * MNNFFPPS: major minor fix patch status
 * The status nibble has one of the values 0 for development, 1 to e for 
betas
 * 1 to 14, and f for release.  The patch level is exactly that.
 * For example:
 * 0.9.3-dev  0x00903000
 * 0.9.3-beta10x00903001
 * 0.9.3-beta2-dev 0x00903002
 * 0.9.3-beta20x00903002 (same as ...beta2-dev)
 * 0.9.3  0x0090300f
 * 0.9.3a 0x0090301f
 * 0.9.4  0x0090400f
 * 1.2.3z 0x102031af
 *
 * For continuity reasons (because 0.9.5 is already out, and is coded
 * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
 * part is slightly different, by setting the highest bit.  This means
 * that 0.9.5a looks like this: 0x0090581f.  At 0.9.6, we can start
 * with 0x0090600S...
 *
 * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
 * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
 *  major minor fix final patch/beta)
 */
#define OPENSSL_VERSION_NUMBER  0x0090809fL

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-23 Thread Eric Rescorla
At Tue, 20 Jan 2009 17:57:09 +1300,
Peter Gutmann wrote:
 
 Steven M. Bellovin s...@cs.columbia.edu writes:
 
 So -- who supports TLS 1.2?
 
 Not a lot, I think.  The problem with 1.2 is that it introduces a pile of
 totally gratuitous incompatible changes to the protocol that require quite a
 bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a
 bigger step, than the change from SSL to TLS), complicate an implementation,
 are difficult to test because of the general lack of implementations
 supporting it, and provide no visible benefit.  Why would anyone rush to
 implement this when what we've got now works[0] just fine?

Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, but
since I was obviously heavily involved with TLS 1.2, I think a bit
of context is in order.

Nearly all the changes to TLS between 1.1 and 1.2 were specifically designed
to accomodate new digest algorithms throughout the protocol. For those
of you who aren't TLS experts, TLS had MD5 and SHA-1 wired all throughout
the protocol and we had to arrange to strip them out, plus find a way
to signal that you were willing to support the newer algorithms. To
avoid this becoming a huge pile of hacks, we had to restructure some of
the less orthogonal negotiation mechanisms. The other major (and totally
optional) change was the addition of combined cipher modes like GCM.
That change was made primarily because we were in there and there was
some demand for those modes. So, no, I don't consider these changes
gratuitous, though of course they are incompatible. Yes, there were
simpler things we could have done, such as just specifying a new set of
fixed digest algorithms to replace MD5 and SHA-1, but I and others felt
that this was unwise from a futureproofing perspective.

Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those
between SSL and TLS. I'm not particularly happy about that either, but
it's what we felt was necessary to do a principled job.

-Ekr







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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-21 Thread Peter Gutmann
Jon Callas j...@callas.org writes:

I've always been pleased with your answer to Question J, so I'll say what
we're doing at PGP.

That wasn't really meant as a compliment :-).  The problem is that by leaping
on things the instant they appear you end up having to support a menagerie of
wierdo algorithms and mechanisms that the industry as a whole never adopts.
How many crypto libraries that could be used to implement the OpenPGP spec
actually support Haval, or Tiger, or Twofish, or SAFER-SK128?  The result of
this too-quick adoption has been a bunch of gaps in newer versions of the spec
(look for a range of algorithm IDs marked as reserved) where algorithms
adopted too quickly were removed again when they failed to gain general (or
any) acceptance.

Another concern with too-quick adoption is the potential for moving to an
algorithm that's later found to be flawed.  This hasn't happened yet for
cryptographer-designed algorithms and mechanisms (as opposed to WEP et al) but
it's quite possible that some new algorithm introduced at Crypto n is shown to
reduce to rot-13 in a paper published in Crypto n+1.  I use an informal five-
year rule that I won't make an algorithm a default (i.e. enabled without
explicit user action) until it's had active attention paid to it for at least
five years, where active attention means not so much published in an obscure
conference somewhere but required in an industry spec or something similar
that results in active scrutiny of its security.  (Actually it's not quite
that simple, it's more of a balancing act and the pace depends on whether
there are credible threats to the current default algorithm or not).

In crypto, new doesn't necessarily mean better, it can also mean
riskier.

Peter.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Bodo Moeller
On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin s...@cs.columbia.edu 
wrote:

 I've mentioned it before, but I'll point to the paper Eric Rescorla
 wrote a few years ago:
 http://www.cs.columbia.edu/~smb/papers/new-hash.ps or
 http://www.cs.columbia.edu/~smb/papers/new-hash.pdf .  The bottom line:
 if you're running a public-facing web server, you *can't* offer a SHA-2
 certificate because you have no way of knowing if the client supports
 SHA-2. Fixing that requires a TLS fix; see the above timeline for that.

The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256
mandatory), so you can send a SHA-256 certificate to clients that
indicate they support TLS 1.2 or later.  You'd still need some other
certificate for interoperability with clients that don't support
SHA-256, of course, and you'd be sending that one to clients that do
support SHA-256 but not TLS 1.2.  (So you'd fall back to SHA-1, which
is not really a problem when CAs make sure to use the hash algorithm
in a way that doesn't rely on hash collisions being hard to find,
which probably is a good idea for *any* hash algorithm.)

Bodo

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Darren J Moffat

Paul Hoffman wrote:

At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote:

When in 2012 the winner of the
NIST SHA-3 competition will be known, and everybody will start
using it (so that according to Peter's estimates, by 2018 half
of the implementations actually uses it), do we then have enough
redundancy?


No offense, Benne, but are serious? Why would everybody even consider it? 
Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 
is any better than SHA-2 for applications such as digital certificates?

In specific, if most systems have implemented the whole SHA-2 family by the 
time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would 
argue that it is probably much more prudent to change to SHA-2/384 than to 
SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will 
have had significantly more study.


Can you state the assumptions for why you think that moving to SHA384 
would be safe if SHA256 was considered vulnerable in some way please.


SHA256,384,512 are a suite all built on the same basic algorithm 
construction.  Depending on how SHA256 fell the whole suite could be 
vulnerable irrespective of the digest length or maybe it won't be.


Until we know how the SHA3 digest is actually constructed the same could 
even be true of that.


I don't think it depends at all on who you trust but on what algorithms 
are available in the protocols you need to use to run your business or 
use the apps important to you for some other reason.   It also very much 
depends on why the app uses the crypto algorithm in question, and in the 
case of digest/hash algorithms wither they are key'd (HMAC) or not.


--
Darren J Moffat

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Paul Hoffman
At 1:38 PM + 1/19/09, Darren J Moffat wrote:
Can you state the assumptions for why you think that moving to SHA384 would be 
safe if SHA256 was considered vulnerable in some way please.

Sure. I need 128 bits of pre-image protection for, say, a digital signature. 
SHA2/256 is giving me that. Then, due to some weakness, it is only giving me 
112 bits of protection. The weakness is understood in the crypto community, and 
it's a straight-line loss of bits of protection.

SHA2/384 would then give me 168 bits of protection, which is more than the 128 
what I need.

Even if you don't trust that there is a straight-line loss of bits, you would 
have to be believing that the attack is much worse for SHA2/384 than it was for 
SHA2/256 in order to bring the output down to the level that I need.

--Paul Hoffman, Director
--VPN Consortium

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Victor Duchovni
On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote:

 The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256
 mandatory), so you can send a SHA-256 certificate to clients that
 indicate they support TLS 1.2 or later.  You'd still need some other
 certificate for interoperability with clients that don't support
 SHA-256, of course, and you'd be sending that one to clients that do
 support SHA-256 but not TLS 1.2.  (So you'd fall back to SHA-1, which
 is not really a problem when CAs make sure to use the hash algorithm
 in a way that doesn't rely on hash collisions being hard to find,
 which probably is a good idea for *any* hash algorithm.)

It would be helpful if as a first step, SSL_library_init() (a.k.a.
OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests,
I would make this change in the 0.9.9 development snapshots.

[ Off topic: I find OpenSSL release-engineering a rather puzzling
process. The patch releases are in fact feature releases, and there
are no real patch releases even for critical security issues.  I chose
to backport the 0.9.8j security fixes to 0.9.8i and sit out all the
new FIPS code, ... This should not be necessary. I really hope to see
real OpenSSL patch releases some day with development of new features
*strictly* in the development snapshots. Ideally this will start with
0.9.9a, with no new features, just bugfixes, in [b-z]. ]

-- 
Viktor.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Steven M. Bellovin
On Mon, 19 Jan 2009 10:45:55 +0100
Bodo Moeller bmoel...@acm.org wrote:

 On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin
 s...@cs.columbia.edu wrote:
 
  I've mentioned it before, but I'll point to the paper Eric Rescorla
  wrote a few years ago:
  http://www.cs.columbia.edu/~smb/papers/new-hash.ps or
  http://www.cs.columbia.edu/~smb/papers/new-hash.pdf .  The bottom
  line: if you're running a public-facing web server, you *can't*
  offer a SHA-2 certificate because you have no way of knowing if the
  client supports SHA-2. Fixing that requires a TLS fix; see the
  above timeline for that.
 
 The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256
 mandatory), so you can send a SHA-256 certificate to clients that
 indicate they support TLS 1.2 or later.  You'd still need some other
 certificate for interoperability with clients that don't support
 SHA-256, of course, and you'd be sending that one to clients that do
 support SHA-256 but not TLS 1.2.  (So you'd fall back to SHA-1, which
 is not really a problem when CAs make sure to use the hash algorithm
 in a way that doesn't rely on hash collisions being hard to find,
 which probably is a good idea for *any* hash algorithm.)
 
So -- who supports TLS 1.2?  (Btw -- note the date of that RFC: August
2008.  That's almost exactly 3 years after ekr and I published our
paper.  Since ekr is co-chair of the TLS working group, we can assume
that that group was aware of the problem.  See what Peter and I said
about how long it takes to get any changes deployed.)

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Peter Gutmann
Steven M. Bellovin s...@cs.columbia.edu writes:

So -- who supports TLS 1.2?

Not a lot, I think.  The problem with 1.2 is that it introduces a pile of
totally gratuitous incompatible changes to the protocol that require quite a
bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a
bigger step, than the change from SSL to TLS), complicate an implementation,
are difficult to test because of the general lack of implementations
supporting it, and provide no visible benefit.  Why would anyone rush to
implement this when what we've got now works[0] just fine?

Peter.

[0] For whatever level of works applies to SSL/TLS, in the sense that 1.2
won't work any better than 1.1 does.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Jon Callas
I have a general outline of a timeline for adoption of new crypto  
mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically  
algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt 
, see Question J about 2/3 of the way down.  It's not meant to be  
definitively accurate for all cases but was created as a rough  
guideline for people proposing to introduce new crypto mechanisms to  
give an idea of how long they should expect to wait to see them  
adopted.


I've always been pleased with your answer to Question J, so I'll say  
what we're doing at PGP.


We deprecated MD5 in '97. That was one of the main points of the new  
formats that became OpenPGP was that agility has its own challenges,  
but it's worth it.


We had a meeting recently to look at what we're going to do. Our first  
thoughts were that we would scrub MD5 from the UI and be done with it.  
Then we realized that we need to leave enough of the old UI so that  
people can *remove* MD5 from their use.


We decided that we'll issue warnings in the annotations when we verify  
MD5 signatures. We can't stop verifying them, but we'll do an  
equivalent to what we do with 40-bit crypto in S/MIME. (40-bit still  
harries S/MIME; it's really a pity that we have to deal with it. Our  
solution is that 40-bit crypto is just a fancy form of plaintext. We  
decode it the way we decode quoted-printable, base64, and other fancy  
forms of plaintext.) We debated removing it from the APIs, and  
concluded that that is asking for trouble, because someone will need  
to do that for diagnostic and testing purposes.


We've started deprecating the 160-bit hashes. There will be comments  
in the UI for both SHA-1 and RIPE-MD/160. We think NIST's advice for  
phasing them out next year is just fine, and so we'll start really  
phasing them out next year.


Lastly, we considered other options for hash algorithms. Presently,  
it's too early to do anything, but we'll look at it again when we do  
more work on the 160-bit hashes.


Jon

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Nicolas Williams
On Mon, Jan 19, 2009 at 01:38:02PM +, Darren J Moffat wrote:
 I don't think it depends at all on who you trust but on what algorithms 
 are available in the protocols you need to use to run your business or 
 use the apps important to you for some other reason.   It also very much 
 depends on why the app uses the crypto algorithm in question, and in the 
 case of digest/hash algorithms wither they are key'd (HMAC) or not.

As Jeff Hutzelman suggested recently, inspired by the SSHv2 CBC mode
vulnerability, hash algorithm agility for PKI really means having more
than one signature, each using a different hash, in each certificate;
this enlarges certificates.  Alternatively, it needs to be possible to
select what certificate to present to a peer based on an algorithm
negotiation; this tends to mean adding round-trips to our protocols.

Nico
-- 

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


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-18 Thread Paul Hoffman
At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote:
When in 2012 the winner of the
NIST SHA-3 competition will be known, and everybody will start
using it (so that according to Peter's estimates, by 2018 half
of the implementations actually uses it), do we then have enough
redundancy?

No offense, Benne, but are serious? Why would everybody even consider it? 
Give what we know about the design of SHA-2 (too little), how would we know 
whether SHA-3 is any better than SHA-2 for applications such as digital 
certificates?

In specific, if most systems have implemented the whole SHA-2 family by the 
time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would 
argue that it is probably much more prudent to change to SHA-2/384 than to 
SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will 
have had significantly more study.

It all depends on who you trust and why.

--Paul Hoffman, Director
--VPN Consortium

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


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-17 Thread Peter Gutmann
Weger, B.M.M. de b.m.m.d.we...@tue.nl writes:

 Bottom line, anyone fielding a SHA-2 cert today is not going=20
 to be happy with their costly pile of bits.

Will this situation have changed by the end of 2010 (that's next year, by the
way), when everybody who takes NIST seriously will have to switch to SHA-2?

I have a general outline of a timeline for adoption of new crypto mechanisms
(e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my
Crypto Gardening Guide and Planting Tips,
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see Question J
about 2/3 of the way down.  It's not meant to be definitively accurate for all
cases but was created as a rough guideline for people proposing to introduce
new crypto mechanisms to give an idea of how long they should expect to wait 
to see them adopted.

Peter.

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


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-17 Thread Weger, B.M.M. de
Hi Peter,

 I have a general outline of a timeline for adoption of new 
 crypto mechanisms
 (e.g. OAEP, PSS, that sort of thing, and not specifically 
 algorithms) in my
 Crypto Gardening Guide and Planting Tips,
 http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, 
 see Question J

I had algorithms in mind, as the 'hash crisis' is about algorithms.
For algorithms the situation might be simpler than for protocols.

It is conceivable that one of these days some clever person comes
up with, say, a practical chosen-prefix collision attack on SHA-1,
enabling something similar as we did with MD5. It is also conceivable 
that some clever person completely breaks Rijndael, or RSA.
Do software vendors (such as browser vendors) and service providers 
(such as CAs) have disaster recovery plans for such a situation? 
Or are these simply 'accepted risks' that nobody worries about? 
In my view it would be prudent to move SHA-1 out of the no-worry
category.

One level up, and maybe an example of a general lesson James was
asking for: good practice to avoid availability problems is to
add redundancy. In hash functions the security in many applications
now seems to be completely based on SHA-1, a not-yet-broken but
known-to-be-weak algorithm. How can we avoid such situations?
(I am thinking long term here). When in 2012 the winner of the
NIST SHA-3 competition will be known, and everybody will start
using it (so that according to Peter's estimates, by 2018 half
of the implementations actually uses it), do we then have enough
redundancy? I was not around when Rijndael was chosen as the AES 
winner. Have there been discussions then about the number of winning 
algorithms? Why only one, and not three winners, say, with a 
sufficiently different design, that everybody then will implement? 
Can / should NIST do so with SHA-3? Is implementing three new hash
functions at the same time much more complicated than implementing
one?

Grtz,
Benne de Weger

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-17 Thread Marcus Brinkmann
Weger, B.M.M. de wrote:
 In my view, the main lesson that the information security community, 
 and in particular its intersection with the application building 
 community, has to learn from the recent MD5 and SHA-1 history,
 is that strategies for dealing with broken crypto need rethinking.

On the other hand, compared to many other aspects of our security
infrastructure, even MD5 does quite well.  Of course, that is not meant
to be taken as an excuse.  I agree with your call to have smooth
transition systems to go from one cipher to another, but when to make
the transition is a difficult decision to make.

 PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) 
 offering the video and audio files of the 25c3 presentation MD5 
 considered harmful today, provide for integrity checking of those 
 files their, uhm, MD5 hashes.

It seems to me they are only provided to protect against transmission
errors, and they are fine for that.  Otherwise, it would be a more
serious mistake to transfer them in-band.  Security is a spectrum.

Thanks,
Marcus

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-17 Thread Steven M. Bellovin
On Mon, 12 Jan 2009 16:05:08 +1300
pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:

 Weger, B.M.M. de b.m.m.d.we...@tue.nl writes:
 
  Bottom line, anyone fielding a SHA-2 cert today is not going=20
  to be happy with their costly pile of bits.
 
 Will this situation have changed by the end of 2010 (that's next
 year, by the way), when everybody who takes NIST seriously will have
 to switch to SHA-2?
 
 I have a general outline of a timeline for adoption of new crypto
 mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically
 algorithms) in my Crypto Gardening Guide and Planting Tips,
 http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see
 Question J about 2/3 of the way down.  It's not meant to be
 definitively accurate for all cases but was created as a rough
 guideline for people proposing to introduce new crypto mechanisms to
 give an idea of how long they should expect to wait to see them
 adopted.
 
My analysis is similar to Peter's: 2-3 years for an RFC, 2-3 years for
design/code/test, 2 years average delay for the next major release of
Windows which will include it, 5 years for most of the older machines to
die off.  

I've mentioned it before, but I'll point to the paper Eric Rescorla
wrote a few years ago:
http://www.cs.columbia.edu/~smb/papers/new-hash.ps or
http://www.cs.columbia.edu/~smb/papers/new-hash.pdf .  The bottom line:
if you're running a public-facing web server, you *can't* offer a SHA-2
certificate because you have no way of knowing if the client supports
SHA-2. Fixing that requires a TLS fix; see the above timeline for that.

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

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


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-11 Thread Weger, B.M.M. de
Hi Victor,

 Bottom line, anyone fielding a SHA-2 cert today is not going 
 to be happy with their costly pile of bits.

Will this situation have changed by the end of 2010 (that's
next year, by the way), when everybody who takes NIST seriously 
will have to switch to SHA-2? The first weakness shown in MD5
was not in 2004 but in 1995. Apparently it takes a very long
time before the awareness about the implications of using
weakened or broken crypto has reached a sufficient level. Though
I understand the practical issues you're talking about, Victor,
my bottom line is different.

In my view, the main lesson that the information security community, 
and in particular its intersection with the application building 
community, has to learn from the recent MD5 and SHA-1 history,
is that strategies for dealing with broken crypto need rethinking.

[[Maybe in the previous sentence the word intersection should be 
replaced by union.]]

Grtz,
Benne de Weger

PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) 
offering the video and audio files of the 25c3 presentation MD5 
considered harmful today, provide for integrity checking of those 
files their, uhm, MD5 hashes.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-11 Thread Victor Duchovni
On Sat, Jan 10, 2009 at 11:32:44PM +0100, Weger, B.M.M. de wrote:

 Hi Victor,
 
  Bottom line, anyone fielding a SHA-2 cert today is not going 
  to be happy with their costly pile of bits.
 
 Will this situation have changed by the end of 2010 (that's
 next year, by the way), when everybody who takes NIST seriously 
 will have to switch to SHA-2?

Extremely unlikely in the case of SSL/TLS and X.509 certs. There is
a huge install-base of systems on which SHA-2 certs will failed SSL
handshakes. When Windows XP systems are 1% of the install-base, when
OpenSSL 0.9.8 is 1% of the install-base and 0.9.9 too (if the
support is not added before it goes official), and all the browsers,
Java libraries, ... support SHA-2, then you can deploy SHA-2 certs.

I would estimate 5-8 years, if developers of all relevant mainstream
implementations start to address the issue now. SHA-1 will be with
us well after 2010. New applications written in 2010 will ideally
support SHA-2, but SHA-1 will probably still be the default digest
in many applications through 2013 or 2015.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-10 Thread Victor Duchovni
On Thu, Jan 08, 2009 at 06:23:47PM -0600, Dustin D. Trammell wrote:

 Nearly everything I've seen regarding the proposed solutions to this
 attack have involved migration to SHA-1.  SHA-1 is scheduled to be
 decertified by NIST in 2010, and NIST has already recommended[1] moving
 away from SHA-1 to SHA-2 (256, 512, etc.).  Collision attacks have
 already been demonstrated[2] against SHA-1 back in 2005, and if history
 tells us anything then things will only get worse for SHA-1 from here.
 By not moving directly to at least SHA-2 (until the winner of the NIST
 hash competition is known), these vendors are likely setting themselves
 up for similar attacks in the (relatively) near future.

All fine and good, but no existing OpenSSL release (including
0.9.9-dev) will by default inter-operate with the resulting (SHA2)
certificates. The SSL_library_init() call only initializes ssl
ciphers and digests, which do not include SHA-2. So most SSL
applications won't be able to verify the certificate signatures.
One needs to call OpenSSL_add_all_algorithms() before SHA-2
signed certificates work.

Bottom line, anyone fielding a SHA-2 cert today is not going to be happy
with their costly pile of bits.

-- 
Viktor.

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


MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-09 Thread Dustin D. Trammell
On Tue, 2008-12-30 at 11:51 -0800, 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.

Nearly everything I've seen regarding the proposed solutions to this
attack have involved migration to SHA-1.  SHA-1 is scheduled to be
decertified by NIST in 2010, and NIST has already recommended[1] moving
away from SHA-1 to SHA-2 (256, 512, etc.).  Collision attacks have
already been demonstrated[2] against SHA-1 back in 2005, and if history
tells us anything then things will only get worse for SHA-1 from here.
By not moving directly to at least SHA-2 (until the winner of the NIST
hash competition is known), these vendors are likely setting themselves
up for similar attacks in the (relatively) near future.

[1] http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
[2] http://www.cryptography.com/cnews/hash.html

-- 
Dustin D. Trammell
Security Researcher
BreakingPoint Systems, Inc.


signature.asc
Description: This is a digitally signed message part