3 ms·

I'm unsure if the complaint about the timing attack makes sense in the uint64 version. I know that you're supposed to use "constant time" algorithms for securit

I'm unsure if the complaint about the timing attack makes sense in the uint64 version. I know that you're supposed to use "constant time" algorithms for security, so i'd be interested to hear if my thinking on this is wrong. Does the uint3/uint6 timing attack work with uint64? I've "greyed" bits coming off of random radio waves from the atmosphere in order to test randomness; the drivers i was using for the particular radio didn't allow on-the-fly amplifier adjustments, so if there was, say, a lightning strike within 50 miles, the front-end would get overloaded and "blank" - send mostly zeros, even with incredibly fast AGC control. So entropy wasn't guaranteed unless i could guarantee there wasn't lightning within some predetermined distance of the receiver (as an aside, i have this capability now) - thus for long (96 hour) runs to gather entropy, i'd have to fiddle the output to ensure uniform distribution. Now, with all that said, there was a side channel attack; if there was a lightning storm or other sort of high energy event near my receiver, an "attacker" could determine that the algorithm to ensure uniformity was contributing more to the bits than the atmospheric noise. Possibly.

colmmacc 6y ago
OP here. If parameter s is big, then the branches can be taken quite often, but they also happen up to 2^63 of the times, so it's essentially a single bit bias that is measurable via timing (maybe, if you're very lucky). If s is very small and incongruent then there's the timing channel can leak values, but it can only happen every order 1/2^64 attempts. Of the two I'd be more concerned about the former; biases of that size have led to things being broken before. Technically the latter means the security is less than the 2^64, which isn't very strong for cryptography purposes. But the channel is so hard to measure I wouldn't lose sleep over either, but it is the kind of the team that will get caught in some compliance testing.
kwillets 6y ago
One thought on timing is that, when generating a whole batch of numbers, it makes sense to calculate the modulo exactly once in advance rather than on-demand.

colmmacc 6y ago

OP here. If parameter s is big, then the branches can be taken quite often, but they also happen up to 2^63 of the times, so it's essentially a single bit bias that is measurable via timing (maybe, if you're very lucky). If s is very small and incongruent then there's the timing channel can leak values, but it can only happen every order 1/2^64 attempts. Of the two I'd be more concerned about the former; biases of that size have led to things being broken before. Technically the latter means the security is less than the 2^64, which isn't very strong for cryptography purposes. But the channel is so hard to measure I wouldn't lose sleep over either, but it is the kind of the team that will get caught in some compliance testing.

kwillets 6y ago

One thought on timing is that, when generating a whole batch of numbers, it makes sense to calculate the modulo exactly once in advance rather than on-demand.