Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

ECC, ECDHE, DHE, "PFS" & advanced cipher suite management

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

Topic Author
Baneki
Posts: 49
Joined: Wed Jan 16, 2013 6:22 pm
Contact:

ECC, ECDHE, DHE, "PFS" & advanced cipher suite management

Postby Baneki » Tue Nov 05, 2013 4:48 pm

{direct link: ecc.cryptostorm.org}


A note on high-security general-purpose elliptic curves
Diego F. Aranha, Paulo S. L. M. Barreto, Geovandro C. C. F. Pereira, and Jefferson E. Ricardini


Abstract

In this note we describe some general-purpose, high-efficiency elliptic curves tailored for security levels beyond 2128 . For completeness, we also include legacy-level curves at standard security levels. The choice of curves was made to facilitate state-of-the-art implementation techniques.
647.pdf


{tl;dr M-383 & M-511 | E-382 & E-521 :-P ~admin}

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Dangers of default NIST curves in ECC (Bernstein & Lange)

Postby Pattern_Juggled » Sat Dec 28, 2013 4:21 pm

Here's some additional useful summary writing on ECC curve selection, known weaknesses (both theoretical, and implementation-based), and best practices for effective deployment of ECC in production systems.

tl;dr is, in a very real sense, that naive use of the NIST curves is a route to security failure - a known route to known security failure, not merely a "gee, this isn't ideal" worry about future problems. And, unfortunately, the vast majority of current ECC implementations are defaulting to the default NIST curves and parameters (according to all the data I've seen, although I've yet to see a formal quantitative in-the-wild research project documenting this).

We're often asked why we're not using ECC more broadly in the cryptocloud framework, and the answer is not what people generally expect. No, we're not convinced that "ECC is broken" or "the NSA has backdoored ECC" - those are both silly statements, and not our position in the least. Rather, we know that deploying ECC correctly requires proper curve selection, careful implementation/testing, and peer-review by one of only a small handful of researchers worldwide (in the civilian world, at least) who are genuinely qualified to validate such metrics.

Fortunately, a good number of these researchers - such as Bernstein & Lange, authors of this specific paper - are incredibly generous in sharing their expertise and experience when it comes to such matters. It is to these good folks who we'll turn when we've deployment frameworks to review, prior to beta testing.

All the tools exist to do this right - especially the NaCl libraries, which are improving at a steady clip - but they are not point-and-click, one-step-install at this point in time. At all. Those who rush these ECC deployments, and do so naively (or recklessly) are doing a tremendous disservice to people who are relying on their deployments to retain in-the-wild security. Only a handful of companies are well-staffed enough, internally, to really do ECC right in production-class systems with high confidence their code is solid (Google being an example, with people of Adam Langley's calibre available on-staff to vet such things); the rest of us must solicit genuine expertise from those genuine experts qualified to ensure we're doing it right. Until we're ready to do so, and have done so, deploying production ECC is reckless bordering on wilfully irresponsible.

We're actively working on ECDHE via TLS 1.2 based on the curve3617 family... but we're not moving away from good, 'ole-fashioned DHE (discrete log based PFS key exchange framework, in other words) until we've got ECDHE ready to deploy correctly.

Anyway, here's the underlying paper - worth a read, and not too technical for an interested layperson to digest:
20130531.pdf
(289.91 KiB) Downloaded 382 times
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 14 guests

Login