Early boot, activation, upgrades

[Ivan Krstić]

On Jul 11, 2007, at 1:25 AM, Jonathan Herzog wrote:
> Now that I've looked through the code for LTC SHA-512, I'm pretty  
> sure that I can examine LTC SHA-256 in a day or two. Is there an  
> imminent deadline I should know about?

I don't want to change the crypto going in the Trial-2 firmware at  
this point so there isn't an imminent 2-day deadline, but if we're  
changing the primitives, I'd like to get it done very soon. To  
provide context: the bios-crypto was originally going to be solely  
used to ascertain integrity of BIOS updates, but we're now planning  
to use it for kernel integrity verification as well (which happens on  
every boot), and it's too slow for that. To accommodate both use  
cases without adding primitives to the library, I proposed going from  
the current state (Whirlpool, SHA-512, ECC-521, RSA-2048) to 256-bit  
truncated Whirlpool, SHA-256, ECC-256, and RSA-2048 (no change there).

I'm perfectly comfortable with this not meaningfully reducing the  
overall security of the BIOS update verification, while letting us  
use just SHA-256 and ECC-256 to do kernel integrity verification,  
which should prove substantially faster (benchmark is pending).

> As for the 256-bit curve: yes, it will trigger unaudited code  
> paths, but that's because I haven't yet audited every function used  
> by the ECC package. ECC uses a lot of math, for example, and I  
> haven't yet looked at each mathematical function yet. However, I  
> can say that the 256-bit curve defined in LTC matches the NIST  
> recommendation, and that the unaudited code paths triggered by that  
> curve will be in the underlying math functions, not LTC itself.

Right. The math functions are in your queue to be audited, correct?

Cheers,

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org