[zeromq-dev] Considerations about Elliptic Curve algorithms

Wed Sep 18 10:12:42 CEST 2013

Cryptography will be a controversial area for a long time, and the
only thing we can be sure of is that any given crypto mechanism will
become outclassed at some point.

This is why the ZeroMQ wire protocol, ZMTP, doesn't specify any fixed
mechanism, but leaves this open and extensible. CURVE makes a good
place to start, but was never intended to be a single definitive
answer.

Elliptic Curve Cryptography is particularly controversial, given the
role of certain agencies in the standardization process, and in the
end the strength of Curve25519 comes down to how much one can trust
its designer, Daniel Bernstein, and implementations like libsodium.
>From my perspective, his work is outstanding. Whether 255 bits of ECC
is a sufficient key size, I can't answer.

Curve25519 has been selected for use in DNSCurve, Tor, Tahoe-LAFS, and
Google's new QUIC protocol. It has some strong advantages: speed, good
open source implementations, simplicity, and no known patent issues.

Both the ZMTP wire protocol and the libzmq library make it easy to add
new mechanisms over time. I'd like to encourage anyone interested in
this area to explore that.

-Pieter

On Wed, Sep 18, 2013 at 9:45 AM,  <l.alebarde at free.fr> wrote:
> Quotes from tinc Digest Vol 107 Issue 9 (I have bolded the interesting
> parts. Daniel J. Bernstein's Curve25519 is also discussed) :
>
>
> Sujet:
> ECDSA curve used in new protocol has suspicious seed value
> De :
> Markus Teufelberger <markusteufelberger at gmail.com>
> Date :
> 14/09/2013 04:53
>
> Pour :
> tinc at tinc-vpn.org
>
>
> Hi there,
>
> As I'm sure you are aware, *there are suspicions (as usual) against the
> NSA potentially weakening crypto around the globe*. This time it is
> about a cipher that is/will be used in the new tinc protocol: ECDSA
>
> According to
> https://github.com/gsliepen/tinc/blob/1.1/src/openssl/ecdsagen.c you use
> the secp521r1 curve, which is derived (according to
> http://www.secg.org/collateral/sec2_final.pdf - page 18) from the seed
> value "D09E8800 291CB853 96CC6717 393284AA A0DA64BA". There is suspicion
> around, that this seed value might weaken a ECDSA curve (as it is not
> explained where it actually comes from and how/why it was selected) to
> an attack not yet known to the public, chosen potentially by brute force
> to make this attack easier.
>
> Unfortunately, there is no alternative curve defined for these key sizes
> in Fp, as far as I'm aware (for 256 bits, one could use secp256k1 for
> example, which does not use an unexplained seed value), so this is
> mainly a heads-up and maybe a request to change to any widely accepted
> curve that might emerge in the future for that key size.
>
> I don't know enough about ECDSA to give any more input than: The next
> largest Koblitz-curve would be sect571k which still has 256 bit
> strength, maybe it would be possible to use this one. I'll let people
> more intimate with crypto in general, openssl in particular and tinc
> sort this out though, since it uses a different finite field (F2^m).
>
> Stay safe and thank you for tinc,
> Markus
>
> ForwardedMessage.eml
>
> Sujet:
> Elliptic curves in tinc
> De :
> Guus Sliepen <guus at tinc-vpn.org>
> Date :
> 14/09/2013 10:25
>
> Pour :
> tinc at tinc-vpn.org, tinc-devel at tinc-vpn.org
>
>
> In the past 24 hours multiple persons have contacted me regarding the use of
> elliptic curve cryptography in tinc 1.1 in light of the suspicion that the NSA
> might have weakened algorithms and/or elliptic curves published by NIST.
>
> The new protocol in tinc 1.1 (SPTPS) uses ECDH and ECDSA to do session key
> exchange and authentication, in such a way that it has the perfect forward
> secrecy (PFS) property. For both the ephemeral keys used in ECDH and the
> long-lived keys used for ECDSA, tinc uses the "secp521r1" curve, as published
> by NIST. There are suspicions in the cryptographic community that the NSA has
> influenced the EC standards so they contain weaknesses that the NSA supposedly
> could exploit. There are two concerns I have heard of:
>
> 1) The Dual_EC_DRBG algorithm, which uses elliptic curve cryptography to create
>     a*pseudo random number generator (PRNG), might be flawed. NIST has since
> issued
>     a recommendation that this algorithm should not be used anymore.*  Tinc does
> NOT
>     use this algorithm.
>
> 2)*The curves secp???r1*have been generated using parameters that are not
>     explained, and hence these curves*might have some flaws*that make them
> weaker
>     than intended. Tinc uses the secp521r1 curve.
>
> Personally,*I think that the NSA would not compromise curves that are
> recommended for encryption of government data*, as the risk that a foreign
> country finds out about their weaknesses would then gain an advantage in
> decrypting US government data. However, I might be wrong.
>
> Some suggestions have been made for alternative curves. The first one is that,
> instead of using the NIST curves defined over a prime field, one could use
> those defined over a binary field (sect???k1). The drawback is that, at least
> in OpenSSL, operations on those curves are an order of magnitude slower than on
> a prime field curve.
>
> *The second is using Daniel J. Bernstein's Curve25519. This curve allows very
> fast operations, however it only has a strength of 255 bits, and as far as I
> know, only ECDH operations are well-defined on this curve, but ECDSA is not.
> Note that tinc requires at least 512 bit curves in order to allow 256 bit
> strength for the symmetric encryption.*
>
> There are also other groups which have found and defined elliptic curves, such
> as ECC Brainpool, which has defined a 512 bit curve. I have not tried out this
> curve myself, and I don't know how well their curves have been scrutinized by
> the cryptographic community.
>
> Another option would be to try to generate our own curve. However, I have no
> idea what pitfalls there are when doing that.
>
> If any of you have well informed suggestions to make about elliptic curves,
> please let me know. I'm subscribed to the randombit.net and metzdowd.com
> cryptography mailing lists, so anything you hear there you don't have to
> repeat. I would certainly switch curves if the new one is not less suspect than
> the secp curves, and if it allows at least a few ECDH or ECDSA operations per
> second on low-powered devices. By the way, if you are running tinc on
> low-powered devices, please run "openssl speed ecdsap521 ecdsak571 ecdhp521
> ecdhk571" and send me the results.
>
> -- Met vriendelijke groet / with kind regards, Guus Sliepen
> <guus at tinc-vpn.org>
>
>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
> ----- End forwarded message -----
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>