On Thu, Feb 17, 2005 at 02:33:44AM +0000, Jason Holt wrote:
> Actually, RIPEMD was broken along with md5:
> 
> http://eprint.iacr.org/2004/199
> 
> RIPEMD-160 may be better than vanilla RIPEMD, but I'd still be very
> suspicious.

Yes, SHA-256, RIPEMD-160, and the sort may very well be subject to
some sort of class break.  When a paper comes out where some
researchers actually produce a collision with RIPEMD-160, we will have
all the more reason to be concerned.  So.... how 'bout Whirlpool?  :-)

There has been some discussion regarding security and probabilities.
Those who have read Schneier may be familiar with the risk assessment
tree.  That is, the path up the tree to the resource that is least
costly is the path you should worry about the most when considering a
security solution.  For example:

  Resource ($5,000)
      /     \
   $1,000  $200
    /  \      \
$5,000 $200  $10,000

The cheapest path to the $5,000 resource is $200+$1,000=$1,200.  All
the other paths cost more than the resource is worth, so no rational
person will take those paths.  The strategy is to strengthen one of
the nodes along that weak path or to insert a node to increase the
total cost along that path.  The nodes could be anywhere from
``calculate a SHA-1 collision'' to ``bribe the janitor.''

Given that, I would have to think hard about (1) the probability that
RIPEMD-160 is broken, (2) how much it would cost to create a
RIPEMD-160 collision, (3) how much I value whether or not an email is
falsely signed with my key.  Well, I know (1) and (2) with relative
certainty with regard to SHA-1 (yes and O(2^69)).  (3) is widely
varying, and I'd rather not think about that too hard, or I might
become even more paranoid.  With regard to RIPEMD-160, I can only
speculate on (1), and I have no idea what (2) may be.  It would seem
that RIPEMD-160 is at least a few orders of magnitude safer than SHA-1
at the moment.

In any case, I really shouldn't be squabbling over SHA-1 when I have a
1024-bit public key.  And I shouldn't be worrying so much about my
precious digital signatures, when I have a 1 in 87 chance of dying in
a car accident.  It's *other people's* digital signatures, like banks
and spies, that I really should be worrying about.  :-)

So I think the safe tentative conclusion set is this:
 - Use security whose strength is in proportion to what it is
   protecting.
 - Don't use cryptographic primitives that are known to be broken.
 - Be very judicious with cryptographic primitives that may be
   broken.  Consider things like scope of usage and time limits on
   usefulness.  For example, anything you want to keep secret longer
   than a couple of decades should probably be OTP'd.
 - Wear your seatbelt, keep your headlights on, and buy a car with
   airbags.

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
 - Bertrand Russell

Attachment: signature.asc
Description: Digital signature

--------------------
BYU Unix Users Group 
http://uug.byu.edu/ 

The opinions expressed in this message are the responsibility of their
author.  They are not endorsed by BYU, the BYU CS Department or BYU-UUG. 
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list

Reply via email to