2 ms·
Which is why you should use RISC-V Ariane instead which is already being timing modelled by ETH. Or work on the ARM Cortex M5 verification then run it on AMD-S
by AstralStorm 8y ago
Which is why you should use RISC-V Ariane instead which is already being timing modelled by ETH.
Or work on the ARM Cortex M5 verification then run it on AMD-SP which is one. Presuming they allow you to run your own code.
Likewise Intel ME... But that processor is some weird architecture.
Or other external hardware - smart card or the fancy U2F.
- detaro 8y agoDifferent RISC-V and ARM cores also have differing timing?
- AstralStorm 8y agoYes, which is why I mentioned the specific Ariane in-order application processor and specific ARM processor. If the encryption algorithm validates in SeL4 Ariane environment, it is algorithmically side channel free. However, this does not say anything about it being side channel free on x86 Linux - out of order execution, more caches, HT - all Spectre vectors. Of course the proof can be easily extended to handle other RISC-V in order cores. Proving out of order execution is hairier, a lot of work to be done. Oh, and you get to freeze the code to given validated compilation FIPS style. Any random C compiler revision can mess you up. Or rerun the prover.
- detaro 8y agoHuh, I could have sworn your comment said you should use RISC-V instead. Apologies.