3 ms·

I simply do not understand what you mean. Here is a proposal: I have verified that when the Skein cryptographic hash function is computed on a buffer of length

I simply do not understand what you mean. Here is a proposal: I have verified that when the Skein cryptographic hash function is computed on a buffer of length n, using the reference implementation, then out of the program inputs, the computation time only depends on: - n, the length of the buffer - one, a static const variable used to determine endianness and NOT on the contents of the buffer. Please take any widespread processor of your choice, any widespread OS of your choice, any reasonable C compiler (not a C compiler that transforms constant-time operations into non-constant-time, I can write one of these as well as you, this is not the goal of the exercise), the length n of your choice, two input buffer contents of length n of your choice, and show how measuring the execution time as often as you like lets you discern between one input buffer version and the other. Do as much statistic analysis as you need. Launch Skein a billion times if you need to. Have a device on the USB port that causes interrupts if that helps. Disable all cores except one. Disable hyperthreading. Enable hyperthreading. But only come back when you have concrete proof of your claim. Deal? NOTE: you may think it's too much work just to satisfy some dude on Hacker News, but I'm sure you can become quite famous if you know how to do this. You are not doing this to convince only me. The people behind Skein think that its execution time does not depend on secrets, the fools, and since I followed Adam Langley's methodology to verify that property, you'll be proving him wrong too.

TheLoneWolfling 12y ago
Nope. I have neither the time nor the expertise to be able to do this myself. You're not trying to defend against people with my level of expertise (or rather, lack thereof). You're trying to defend against people who are a whole lot smarter than me, and have a whole lot more time on their hands. I was hoping you either had something showing it wasn't a problem, or a workaround. Instead you've basically gone "I don't think it's a problem" and dismissed it. Normally, that would be ok. But it's cryptography. That's not good enough.
- pascal_cuoq 12y ago
  That is one way of putting it. The other way of putting it is that you are arguing about things that you may not fully understand, or perhaps you are not able to put your ideas into words that others can understand. You are right, I have given up on understanding what you meant. I will look forward to the proof of concept.
nkurz 12y ago
For what it's worth, I mostly[1] agree with you. You should consider should writing this up more formally as a challenge. Figure out some some of money you can afford to lose, and award it as a cash prize to anyone who can disprove you. show how measuring the execution time as often as you like lets you discern between one input buffer version and the other I think you can simplify this even further: is there any set of two inputs that can be distinguished from each other by measurement of execution time? One does not even need to identify which input is which --- merely show that there is some measurable property that is different for hashing A vs hashing B. [1] I think the weakness is the reference to a "reasonable C compiler". It seems likely to me that at least one of GCC/Clang/MSVC/ICC with some combination of legal flags will generate assembly that defeats the obvious intent of your algorithm. This would be a disappointing way to lose your bet.

TheLoneWolfling 12y ago

Nope. I have neither the time nor the expertise to be able to do this myself. You're not trying to defend against people with my level of expertise (or rather, lack thereof). You're trying to defend against people who are a whole lot smarter than me, and have a whole lot more time on their hands. I was hoping you either had something showing it wasn't a problem, or a workaround. Instead you've basically gone "I don't think it's a problem" and dismissed it. Normally, that would be ok. But it's cryptography. That's not good enough.

pascal_cuoq 12y ago
That is one way of putting it. The other way of putting it is that you are arguing about things that you may not fully understand, or perhaps you are not able to put your ideas into words that others can understand. You are right, I have given up on understanding what you meant. I will look forward to the proof of concept.

nkurz 12y ago

For what it's worth, I mostly[1] agree with you. You should consider should writing this up more formally as a challenge. Figure out some some of money you can afford to lose, and award it as a cash prize to anyone who can disprove you. show how measuring the execution time as often as you like lets you discern between one input buffer version and the other I think you can simplify this even further: is there any set of two inputs that can be distinguished from each other by measurement of execution time? One does not even need to identify which input is which --- merely show that there is some measurable property that is different for hashing A vs hashing B. [1] I think the weakness is the reference to a "reasonable C compiler". It seems likely to me that at least one of GCC/Clang/MSVC/ICC with some combination of legal flags will generate assembly that defeats the obvious intent of your algorithm. This would be a disappointing way to lose your bet.