[Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

[R. A. Hettinga]

[Moderator's note: I'm ending forwards/posts on this topic, unless
someone has something stunningly new to say. --Perry]

--- begin forwarded text


To: mac_crypto at vmeng.com
From: "Arnold G. Reinhold" <reinhold at world.std.com>
Subject: Re: [Mac_crypto] Apple should use SHA! (or stronger) to
 authenticate software releases
Sender: mac_crypto-admin at vmeng.com
Reply-To: mac_crypto at vmeng.com
List-Id: Macintosh Cryptography <mac_crypto.vmeng.com>
List-Post: <mailto:mac_crypto at vmeng.com>
List-Help: <mailto:mac_crypto-request at vmeng.com?subject=help>
List-Subscribe: <http://www.vmeng.com/mailman/listinfo/mac_crypto>,
	<mailto:mac_crypto-request at vmeng.com?subject=subscribe>
List-Archive: <http://www.vmeng.com/pipermail/mac_crypto/>
Date: Tue, 13 Apr 2004 23:53:35 -0400

>On 13 Apr 2004, at 4:04, R. A. Hettinga wrote:
>>From: "Joseph Ashwood" <ashwood at msn.com>
>>>It's not clear to me that you need all this complexity.  All you need
>>>if to arrange that the attacker does not know exactly what will be
>>>signed until it has been signed.  So you append some randomness from a
>>>good random number source to the end of the file just before you sign
>>>it, and you're safe.
>>
>>I'm not quite sure that's a good solution, that random tail provides exactly
>>what the attacker needs to make this as easy as possible. Since the random
>>tail cannot be know beforehand it cannot be known by the user of the patch.
>>If anything this would actually make an attack easier. It is only if the
>>random data is from a _bad_ random source that you might actually gain some
>>security (a bad source would at the very least have redundancy, internal or
>>external, that could be verified by the end user, making it more complex to
>>compute valid numbers). Instead it would probably be more useful to include
>>the same random number between each file, this should short circuit all but
>>the most fatal of hash flaws, but might open up other possibilities (I don't
>>have the time right now to prove things about it).
>
>It's true that the putting randomness on the tail is a bad idea if
>the attacker stands any chance of controlling the supposedly random
>data.  That's why you need to buy a good solid hardware security
>module with the ability to limit the use of the signing keys to only
>be used by your custom code that adds hardware generated random
>padding!
>

I suppose it is educational to think about different ways to solve a
problem like this, but this is getting silly. All that is needed to
prevent my attack is to use calculate and publish the SHA1 hash along
with the MD5 hash. Easy as can be.  No special hardware required.

Arnold Reinhold
_______________________________________________
mac_crypto mailing list
mac_crypto at vmeng.com
http://www.vmeng.com/mailman/listinfo/mac_crypto

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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