From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 28 Feb 2007 09:58:09 -0500 Subject: [U-Boot-Users] RFC: extended image formats In-Reply-To: <625fc13d0702280621l3aa02837m7ed896bba79f3df6@mail.gmail.com> References: <20070227222912.902CB352B86@atlas.denx.de> <625fc13d0702280621l3aa02837m7ed896bba79f3df6@mail.gmail.com> Message-ID: <45E59881.4060402@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Josh Boyer wrote: > On 2/27/07, Wolfgang Denk wrote: >> Hello, >> >> I'm trying to figure out what could be done to add (at least in some >> cases) more information to U-Boot images. >> >> In this case, the existing CRC32 checksum is not sufficient; >> therequirement is to use some stronger hashes (md5 or sha1) to verify >> the correctness of the kernel and file system images. > > Just curious, but why isn't CRC32 sufficient exactly? > > josh CRC32 is pretty weak with respect to: * Multibit errors: * It will detect all single bit errors - good * It will detect all two bit errors up to a block size that is dependent on the CRC length & polynomial (2KBytes for CRC-32 IIRC, but I may recall incorrectly - much less than a u-boot image size in any case) - bad * It detects some multibit errors but not all of them - bad * Cryptography: it is trivial (cryptographically speaking) to "fix up" the CRC after changing something in the block it is covering - very bad. Ref: HTH, gvb