Why Constant-Time Crypto?
bearssl.org
Why Constant-Time Crypto?
1–10 of 24 posts
Re: Why Constant-Time Crypto?
#2Silly question here: why not get a reasonable worst-case time measure one-off, then yield the thread until total time elapsed for said crypto op is up?
Re: Why Constant-Time Crypto?
#3Silly question here: why not get a reasonable worst-case time measure one-off, then yield the thread until total time elapsed for said crypto op is up?
I would imagine that you can detect that in various ways - how fast the server is able to serve concurrent requests, or if you have more local access how much power is being drawn, and so on.
Re: Why Constant-Time Crypto?
#4A little off-topic, but I wonder if the barcode-ish design in the header is a puzzle with an interesting hidden message. It's not uncommon for cryptographers to do things like this.
Re: Why Constant-Time Crypto?
#5Silly question here: why not get a reasonable worst-case time measure one-off, then yield the thread until total time elapsed for said crypto op is up?
First of all: that technique is not very accurate, calling sleep() is not guaranteed to return in a specific amount of time.
But more importantly, that only covers the basic timing attack side channel and not even that very well. Cache and branch predictor attacks are still possible (and these are a bigger threat when you're using a virtual machine that may be shared with your adversary). Not to mention all the side channels (power consumption, etc) that are visible if your hardware is compromised.
And if you do end up yielding a thread, the context switch overhead will be measurable. It can take hundreds of microseconds to fully recover from a context switch (TLBs and cache misses, etc), which will certainly affect the timing. It would almost certainly be possible to detect if the encryption method yielded the thread or not based on timing alone (e.g. encrypting next block would consume more time after a thread yield).
There are no easy ways out, crypto code should be free of side channels: constant time, no data dependent memory accesses (cache attack), no data dependent branches (branch predictor attack), etc. This requires the crypto implementor not only to be proficient in the mathematics of cryptography but also details of the computer architecture they're running on.
Re: Why Constant-Time Crypto?
#6Silly question here: why not get a reasonable worst-case time measure one-off, then yield the thread until total time elapsed for said crypto op is up?
That's going to vary based on processor, memory, load, etc.
Re: Why Constant-Time Crypto?
#7A little off-topic, but I wonder if the barcode-ish design in the header is a puzzle with an interesting hidden message. It's not uncommon for cryptographers to do things like this.
Best I could come up with was "868686692969"...
Re: Why Constant-Time Crypto?
#8A little off-topic, but I wonder if the barcode-ish design in the header is a puzzle with an interesting hidden message. It's not uncommon for cryptographers to do things like this.
The bar code reads: 86 86 86 69 29 69.
Re: Why Constant-Time Crypto?
#9Looks like @pornin has invested a lot more effort since BearSSL's initial release nearly a year ago, previous HN comments at:
Re: Why Constant-Time Crypto?
#10From having spent a bunch of time working on wrapping crypto libraries for Python, the author’s name (Thomas Pornin) is one that I regularly saw providing in-depth answers on the Cryptography stack exchange: https://crypto.stackexchange.com/users/28/thomas-pornin.
It is encouraging to see BearSSL at beta stage. I believe the last time I saw it, Thomas still considered it to be alpha. The promise of a small, MIT-licensed crypto library, written by a solid cryptographer who understands implementation details is nice. I’ve used libtomcrypt in the past, but as a non-expert, I’ve always wondered how resilient and well-written the code base is.