| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 01 Feb 2008 10:37:32 +0000 From: Ian Campbell <ijc@...lion.org.uk> To: George Spelvin <linux@...izon.com> Cc: hpa@...or.com, linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com Subject: Re: There are smaller ways to encode a CRC32 table... On Thu, 2008-01-31 at 23:53 -0500, George Spelvin wrote: > The code to fill it in is smaller than the table itself. > Is it worth complicating things with some INIT code to reduce > the stored image size? (The table is not compressible.) [snip] Thanks but since the code is only used when building the image I'm not too worried which way is used and I've tested the table based one ;-). > And BTW, storing the inverse of the CRC only catches trailing (after the CRC) > all-zero padding. If this is not a problem, it's not necessary, although you > still might want to do it just for consistency. This inversion changes the > CRC of the entire image (body + CRC) from all-zero to a fixed non-zero value. > (To be precise, to the (non-inverted) CRC of 0xffffffff.) I didn't know the precise details of why you might invert it, thanks for the info. Ian -- Ian Campbell Current Noise: Reverend Bizarre - Sodoma Sunrise I am a man: nothing human is alien to me. -- Publius Terentius Afer (Terence) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists