[some_furry]

> It is worth noting that this change could potentially leave implementations vulnerable to Bleichenbacher’s attack on PKCS#1 v1.5 RSA padding. In our implementation, these concerns are not an issue as there we have no access to any of the decrypt responses or stack traces.

You don't need those things to exploit a padding oracle. A timing leak is sufficient.

Unless you're doing what s2n does to blind response times of any potential timing leaks, you're probably still vulnerable.

https://github.com/aws/s2n-tls#timing-blinding

You're probably not using s2n to talk to a Nitro enclave.

[arcurn]

Good point! We can safely isolate ourselves from any timing leaks by E3 because all E3 requests with potential timing leaks simply get transparently tunnelled to the end destination (e.g. an API you're passing through Relay), so a malicious end user can not determine if there was a crypto error and, specifically, how long that crypto error took to happen.

More broadly, though, we don't currently use RSA and chose ECDH instead — so padding oracles aren't something we have to worry too much about. We also have similar safety models for things like invalid curve attacks.

[some_furry]

> a malicious end user can not determine if there was a crypto error and, specifically, how long that crypto error took to happen

That sounds interesting. I'd like to test this hypothesis sometime ;)

> We also have similar safety models for things like invalid curve attacks.

What is your defense against invalid curve attacks exactly? I'm very curious about that (although your target audience largely won't care, so this post probably doesn't need to be updated).

Two defenses that work:

1. Always check that the (x, y) coordinate is a solution for the curve equation

2. Use compressed public key points

I prefer option 2 (especially since the patent on point compression expired years ago), but option 1 works.

[arcurn]

> That sounds interesting. I'd like to test this hypothesis sometime ;)

That sounds great! Feel free to shoot me an email on [e-mail] if you'd like to get further into the weeds :)

Our main defence against invalid curves is compressed public key points. It's not often that security mitigations also give some other nice advantages (smaller public keys!), but for this scenario it made total sense.

[some_furry]

> Our main defence against invalid curves is compressed public key points.

This is the point in Slack when I usually reply with a sparkly heart emoji.

I'll get in touch sometime. This is a busy month for me so I won't have a lot of spare cycles, but if I catch a break it might be fun to test. :D

[adamisntdead]

I'm surprised that something like point compression can even be patented, considering that it's relatively straightforward mathematically (all of the difficulty seems to lie in the number theory to compute a solution, which I assume wasn't invented by whoever owned the patent)...

[some_furry]

Cryptography patents are, on some level, stupid. It's all math.

[z77dj3kl]

That's not how timing attack mitigation works: just because you're doing some other stuff too doesn't mean the timings can't be exploited.

[arcurn]

Yep, but there will be no variance in timing from the end user's perspective (regardless of what payload they send to E3) because neither encryption results nor timing data get returned to the end user.