gnueval-security
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnueval-security] [Richard Stallman] evaluating an encryption progr


From: Niels Möller
Subject: Re: [gnueval-security] [Richard Stallman] evaluating an encryption program
Date: Tue, 26 Nov 2013 09:32:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)

Christian Grothoff <address@hidden> writes:

> However, as long as quantum
> cryptoanalysis (not quantum computing with a handful of bits) is not
> real, it is unclear if NTRU is actually going to be stronger than say a
> good curve.

They also claim high performance. But the comparison "NTRU performs the
costly private key operations much faster than RSA. In fact, CyaSSL+NTRU
runs 20x to 200x faster than openSSL RSA" (from the FAQ,
https://www.securityinnovation.com/security-lab/crypto/102.-ntru-faqs.html)
is maybe not so relevant for us.

For fast public key operations, one should compare to things like the
ecc curves djb has designed for high performance (curve25519,
elligator). They're also going to be a lot faster than RSA, in
particular for the private key operations, since with ecc in general,
the private key operation is a lot faster then the public key
operations, and it's the opposite way with RSA.

With plain standard ecc, signatures are about 10x faster than RSA
(benchmarking Nettle's implementation, RSA 2048 vs ecc over the curve
secp256r1), and using curve25519 should be quite a bit faster than the
curve secp256r1, right?

For signature verification, on the other hand, ecc is almost 10x slower
than RSA, comparing with the same parameters and the RSA public exponent
65537. The NTRU FAQ doesn't mention NTRU performance for signature
verification, so I imagine it's not impressive.

> So the real question is if the GNU packages using NTRU should be trying
> to prepare for the 10% chance in 10-30 years.  MOST should probably not
> do this.  A few crypto libraries (libgcrypt, nettle, GnuPG) may (!) put
> this on their medium-term feature list, but any "normal" package should
> not touch this IMO -- they're much more likely to have security issues
> elsewhere.

I agree.

At this point, would it be useful to also have a look at the provided
source code and see if it appears to be well written?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]