4 ms·
Ok yeah makes sense. What about a pure functional language, in which a program computes a result that is a function of the input only. In this case the only t
by Ono-Sendai 8y ago
Ok yeah makes sense.
What about a pure functional language, in which a program computes a result that is a function of the input only.
In this case the only timing information usable for side-channel info leakage would be in the input to the program.
I guess the problems in this case become twofold:
* How can we determine we are not leaking any such info in the input to the program?
and
* Is a pure, functional language sufficient to do the stuff we want, or are they too limited, e.g. for use as a browser scripting language.
- ufo 8y agoPurity is not enough to prevent timing attacks. A famous example is string equality. The running time of a typical implementation is proportional to the length of the largest common prefix between the two strings. To prevent this information leak the implementation must be written to always iterate until the end. But spectre is even worse than that as it attacks at the hardware level. If the CPU does any sort of speculative optimization, through things like caches or branch prediction buffers, then it likely can be the target of a spectre attack. You can try to add spectre mitigations to your language's compiler but, as the article discusses, this approach is an uphill battle.
- bluGill 8y agoPurity is enough, but purity is not useful. If java script was entirely pure it couldn't do any IO. You couldn't do anything with the string compare result because that requires IO to know what it is done, and that IO is not allowed. Pure algorithms are a useful thing in programming. However pure algorithms are not useful on their own, you always need something impure to get the output out.