4 ms·
I know, it would slow down the whole thing by a factor of 3. Monocypher can "only" produce 7000 signatures per seconds on a single thread on my laptop (i5 Skyl
by loup-vaillant 9y ago
I know, it would slow down the whole thing by a factor of 3.
Monocypher can "only" produce 7000 signatures per seconds on a single thread on my laptop (i5 Skylake Intel). With the verification, I would waste a whooping 0.3ms on each signature, reducing the throughput to 2000 signatures per seconds.
Unless you're running a signing intensive application on the scale of Let's Encrypt, you won't really care about the slow-down. If you don't fully trust your hardware however, faults might be a real problem.
- rightos 9y agoEven let's encrypt is issuing only a handful of certificates per second. Perhaps it'd matter more if used on a per connection basis.
- tptacek 9y ago1. Nobody is attacking Lets Encrypt with fault attacks. 2. If you can induce faults on Lets Encrypt's signing infrastructure you have better attacks to deploy. 3. Lets Encrypt doesn't use Elliptic Curve in the first place.
- loup-vaillant 9y agoOf course, I was only speculating about the scale required to make several thousands of signature per second. Your second point stands, though. It's probably a waste of CPU to mitigate fault attacks in a Lets Encrypt like use case.
- deleted 9y ago[deleted]
- rightos 9y agoI wasn't suggesting any of those things weren't true, merely a back-of-the-napkin estimate of the sort of load a function like this would be sufficient for.
- wolf550e 9y agoLet's Encrypt use HSMs to sign, and more than 90% of signatures produced are for OCSP, not for issuance. Though I have failed to find the link for this, I saw them publish these numbers.