Remember that P-256 carry bug a while back from @FiloSottile/@thecomp1ler/@Cloudflare ?
Here's the bug: https://github.com/golang/go/issues/20040 …
And here's what happen when you get a single bit wrong in a crypto algorithm: https://events.ccc.de/congress/2017/Fahrplan/events/9021.html …
How so? This is the ONLY safe & reliable way to achieve constant-time. Even most ISAs' machine code is not specified to guarantee constant time. Pretending asm can get it is wrong.
-
-
I don’t think anyone is pretending: the ISA problems are well known, and largely considered deficiencies in those ISAs. My question to you is this: how do you select k?
-
Either just pick something huge, or measure over a largeish random set of ops & go a bit larger.
-
"You must use one of a small # of bleeding-edge ISAs to do crypto safely" is not something I consider a viable position.
-
Fair enough, I can respect that. For me, “all crypto opts must take the maximum theoretical execution time on my device” is not a viable position either.
-
I actually have alternate possible solutions based on pseudo-const-time vm interp & const-time algorithms inside the vm, but also very costly.
End of conversation
New conversation -
-
-
Are you aware that timing attacks can be performed using cache invalidation? They target non-constant time table access as well as non-constant time branches. Adding arbitrary delay to the code solves nothing.
-
This is a different class of attacks (local vs remote) but constant cache access pattern and constant time are also different matters.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.