Aloha! Pavel Shatov wrote: >> Hi, Joachim, sorry for a late reply.
NP, thanks for thoughts. ... >> I was thinking, in what place of SHA-512 exactly do timing checks fail? >> I bet it's in the carry chains of 64-bit adders. yes, or more correctly the chained 64-bit ALU ops. In SHA-512 there are a chain of three 64-bit adders in the worst path (and the carry will be the longest through it all). See op-chain in the attached image. I have considered pipelining between these ops before. This will fix the clock speed issue. The downside is of course that performance will be halved. This might still be ok for the RNG though. I had dismissed this solution since it doesn't also reduce the resources consumes. (It actually increases slightly, of course. But a 64-bit reg and an extra FSM state is is really insignificant.) But your post and Robs comment makes me think that we should treat this as a multi stage development of the RNG. Fix clock speed now by pipelining and then work on resource reduction at a later step. In fact, I see more pressing things to improve in the RNG that we should probably focus on before resource reduction. Implementing online tests for the entropy sources (based on AIS31) for example. Decision: Pipeline the SHA-512 to solve clock speed. Thanks to all who has given feedback. I'm pretty certain we will replace the SHA-512 in a future update. And do other changes to the RNG. I'll post ideas about such ideas in separate mails. -- Med vänlig hälsning, Yours Joachim Strömbergson - Assured AB ========================================================================
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
