Do you also sort in constant time at fixed array size, like djbsort claims it does?
For the 1024 array their cycle count quartiles differ from the median at the 3 promille level, but I don't know if this counts as "constant" for timing attack purposes.
Hmm, interesting question.
Radix sorts, by their nature, execute the same code regardless of the contents of their elements. ( I think, I haven't thought about this before).
However you will see some variation in execution time based on varying memory access patterns.
No, it's not constant time. Depending on implementation details, you end up putting different elements in different buckets in different cache lines and that creates side channels.
Radix sort will perform differently for an input that is 1,1,1,... and 1,2,3,...,n.
I have not read up on how djbsort deals with this issue, but it's the problem it's trying to solve.
Actually, there is only an advantage to radix after 100,000 elements - djb is much faster for small arrays. Also, while radix is cpu constant time, you'd need to do some kind of secure shuffle in advance to make it truly constant-time (considering memory locality timing).
On a say 3.6 Ghz processor that would be around 17ms. So the number of elements sorted per second would be around 61.4 M elements/s.
My parallel radix sort can sort floats (a little harder than integers) at around 165 M elements/s: http://forwardscattering.org/post/34
A serial radix sort should still be similar or faster to djbsort.