On Wednesday, November 4, 2015 at 12:56:12 PM UTC-5, jean-pierre.muench wrote: > > Interesting idea, although I fear that a timing side channel may remain > (two dozen carries may take longer than no carry) and thereby not fixing > the problem (if I'm reading things right). >
Forgot to mention... An ADC will work nicely here (http://www.fermimn.gov.it/linux/quarta/x86/adc.htm). There might even be an intrinsic for it. But anyways I got the analysis data. The reproduction details are > documented below and I appended the log file that was created. > > The highlights: > We get a 50% speed penalty best-case for the 4 byte counters. > We get a small speed increase for 1 byte counters (unexpected). > The overhead seems to scale linearly with the byte count. > Thanks for the data. I'd probably make one of the goals efficiency. I would not worry too much if its not optimal. I don't see a lot of harm in losing 3 or 4 cycles (ADC and SBB have a latency of 1). There might even be an intrinsic to do it. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
