ECDSA signature verification

[Shobhit Srivastava]

Hi All 

I have tried to do the performance analysis for different curve in golang and got below output:

for secp256r1 I got 28000 Signature verified per second

for secp384r1 I got 1600 Signature verified per second  

for secp521r1 I got 700 Signature verified per second    

Is there something I did wrong or is this the usual results?

Let me know if someone has done performance comparison.

Best,

Shobhit

[Marcin Romaszewicz]

secp256r1 has been hand optimized for performance, the others haven't.

If performance there matters to you, it's actually faster to call out to C libraries to verify 384 and 512 bit curves.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fdc14759-b995-43af-948d-cdb2201e4718n%40googlegroups.com.

[Shobhit Srivastava]

Yeah the inclination is towards 512 curve only so need to optimise it.

Will check out the C library. Thanks

[Shobhit Srivastava]

Hey Marcin

Can you give me the pointer on C library and if can be used in Cgo .

Thanks

[Marcin Romaszewicz]

My issue was slightly different than yours, in that I was burning way too much CPU verifying 384 bit client certificates for TLS. The solution was to have nginx do TLS termination, and proxy decrypted traffic to my Go server, rather than doing TLS termination in Go.

The first place I would start looking is either the LibreSSL or OpenSSL libraries. LibreSSL is a cleanup of OpenSSL, which has grown messy over the years. Both of these contain a crypto library which does what you want. Here is what it looks like in LibreSSL:

https://man.openbsd.org/ECDSA_SIG_new.3

-- Marcin

[Shobhit Srivastava]

Thanks for the detailed explanation for your issue.

Thanks for the pointers for the library. Just a quick question, do you think calling C library from Go can give great results for 521 curve.

[Marcin Romaszewicz]

Yes, in my experience, the C SSL libraries are much faster than Go's implementation on curves P384 and P521, however, Go's tuned implementation of P256 curves is comparable to OpenSSL performance (https://golang.org/src/crypto/elliptic/). If you look in the directory I linked, you'll see that it has assembly language implementations of the P256 curve.

Practically, there isn't much reason today to use the P384 and P521 curves. The security provided by P256 is very good, not known to be crackable today, and it's a widely supported curve. P384 is reasonably well supported, but not as widely, and P521 isn't well supported at all, since it's not in the NSA Suite B crypto recommendations, which drive many crypto standards.

-- Marcin

[Shobhit Srivastava]

Thank you Marcin for your response.

It is really helpful.

[Kevin Chadwick]

On 2020-10-08 16:22, Marcin Romaszewicz wrote:
> Practically, there isn't much reason today to use the P384 and P521 curves. The
> security provided by P256 is very good, not known to be crackable today, and
> it's a widely supported curve. P384 is reasonably well supported, but not as
> widely, and P521 isn't well supported at all, since it's not in the NSA Suite B
> crypto recommendations, which drive many crypto standards.

There is no good reason to use P384 and little reason to use P521 and no reason
to use p521 for a standard website. The only reason I know of to consider p521
which the browsers do not support (for no good reason, though ssh even installs
a 256 bit host key by default anyway, so maybe key variability simplicity) is
because it offers the greatest challenge in qubits to any potential quantum
computer. However, there is even a possibility that a quantum computer with
enough qubits to defeat p256 is never built or a traditionally binary computer
succeeds first in many years time.

I don't think the world is quite ready for tls 1.3 only yet but you could even
limit the provided algorithms to ed25519 or block P384 in tls 1.2. I would see
that as a far better choice than cgo personally!

Here is how
"https://blog.cloudflare.com/exposing-go-on-the-internet/"

[Kevin Chadwick]

On 2020-10-09 09:01, Kevin Chadwick wrote:
> However, there is even a possibility that a quantum computer with
> enough qubits to defeat p256 is never built or a traditionally binary computer
> succeeds first in many years time.

It is also worth noting that the amount of money required to build and run a
quantum computer, will be many times more than enough to subvert a certificate
authority today.

[Shobhit Srivastava]

Will consider your input