News for hackers. Stuff that matters.
Re:How we built the Evervault Encryption Engine (E3) by arcurn on Tuesday August 10, 2021 @10:27AM (#28129245)
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.

Re:How we built the Evervault Encryption Engine (E3) by some_furry on Tuesday August 10, 2021 @10:30AM (#28129298)
> 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.

Re:How we built the Evervault Encryption Engine (E3) by arcurn on Tuesday August 10, 2021 @10:41AM (#28129446)
> That sounds interesting. I'd like to test this hypothesis sometime ;)

That sounds great! Feel free to shoot me an email on [email protected] 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.

Re:How we built the Evervault Encryption Engine (E3) by some_furry on Tuesday August 10, 2021 @10:47AM (#28129517)
> 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

Re:How we built the Evervault Encryption Engine (E3) by adamisntdead on Tuesday August 10, 2021 @10:43AM (#28129466)
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)...
Re:How we built the Evervault Encryption Engine (E3) by some_furry on Tuesday August 10, 2021 @10:49AM (#28129537)
Cryptography patents are, on some level, stupid. It's all math.
Re:How we built the Evervault Encryption Engine (E3) by z77dj3kl on Tuesday August 10, 2021 @02:09PM (#28132166)
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.
Re:How we built the Evervault Encryption Engine (E3) by arcurn on Tuesday August 10, 2021 @03:01PM (#28132798)
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.