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

[Stephen H. Dawson]

Very good write up.

Since you well present they state they have high performance, and I
would like to see more of their process to get this high performance,
and the data to support it, and Christian well presents the niche for
their work is not really clear, it seems we are all in agreement to get
more information from them. I recommend we ask for more information,
specify what that is, and go from there.

Also, a user manual would be valuable, to expedite consuming what they
provide next.

Thank You,
Stephen H. Dawson
(865) 804-3454
http://www.linkedin.com/in/shdcs


On 11/26/2013 03:32 AM, Niels Möller wrote:
> 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
>