I think it's a stretch to say the most widely used libraries do the right thing here unless you're talking specifically about Ed25519, which itself is actually hardly used. The emphasis on breaking crypto libs also seems like a red herring. Non-crypto apps usually don't even try.
-
-
Replying to @BRIAN_____ @diodesign
Most widely used libraries *for cryptographic software*. Other software indeed often doesn't even try. But in that case, you don't need TLBleed at all - any side-channel attack will work fine.
1 reply 0 retweets 0 likes -
Replying to @chandlerc1024 @diodesign
I'd guess that OpenSSL 1.0.1 or earlier is probably the most common open-source crypto library and (1) it doesn't implement Ed25519, (2) It's ECC implementation leaves a lot to be desired for the curves it does implement, especially on non-x86-64. BoringSSL was fixed 9 weeks ago.
2 replies 0 retweets 0 likes -
Replying to @BRIAN_____ @diodesign
But again, if broken, you wouldn't need TLBleed. The thing really hurt here are approaches to mitigating side channels other than data-invariant coding such as the ones discussed in the paper, and those seem somewhat rarely deployed outside of libgcrypt.
1 reply 0 retweets 0 likes -
Replying to @chandlerc1024 @diodesign
AFAICT the paper isn't available publicly yet so I can't refer to it. NSS and OpenSSL are both using non-data-invariant mitigations even in their master branches today, except in special cases like x25519/Ed25519 and some optimzed x86-64 or 64-bit-only P-256 implementations.
2 replies 0 retweets 0 likes -
Replying to @BRIAN_____ @diodesign
@agl__ to comment about non-data-invariant side channel mitigation still being relied on in OpenSSL. If that's the case (for either of these libs) we should definitely work on fixing it.2 replies 0 retweets 0 likes -
I don't know any details here, but it seems that TLB-based side-channels would be a subset of well-known cache side-channels, so it would be weaker than existing attacks.
2 replies 0 retweets 0 likes -
Replying to @agl__ @chandlerc1024 and
But we have a fair handle on how to solve cache side-channels. Issues are cases where we haven't pushed that all the way through crypto libraries, compilers possibly optimising away that work, and non-crypto cases.
1 reply 0 retweets 0 likes -
Replying to @agl__ @chandlerc1024 and
But there's a reason why these papers target gcrypt: it has historically been lagging at constant-time implementations. It's true that OpenSSL/BoringSSL still have work to do also, but they're doing much better.
2 replies 0 retweets 0 likes -
Yes that's true. The point I'm trying to make w.r.t. OpenSSL and BoringSSL is that a lot of the improvements were done recently, and we can't just look at OpenSSL master and say "nothing to worry about" when RHEL & Ubuntu are shipping OpenSSL 1.0.1 in current enterprise products.
2 replies 2 retweets 1 like
OTOH, if it's true that this is even less powerful than the existing cache timing attacks then it would be nothing new to worry about.
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.