Hacker News Reader

Comment by smegel | Hacker News Reader

Sigh. If you're configuring "Curve Preferences" you're doing it wrong. Crypto either works out of the box or find another tool.

View on HN

First, the person writing this article (Filippo Valsorda) has expertise.

Second, the point isn't to select crypto that "works", but rather to select crypto that is efficiently supported by Golang.

> However, you should still set PreferServerCipherSuites to ensure safer and faster cipher suites are preferred, and CurvePreferences to avoid unoptimized curves

Sounds more like he's giving advice to others on the finer points of elliptic curve cryptography. Programmers should not need to know this stuff.

...no, it's literally saying "here are the settings you need to make sure you only use efficiently implemented algorithms"

Because making safe, efficient settings the hard-to-tamper-with default would be waaay too sensible?

More sensible than trying to have a conversation by stating your points as condescending "questions".

In case you actually care to discuss it, there's definitely a trade-off between variety of cipher support (which some people want) and efficiency of cipher support (which some people absolutely need). Prioritizing one over the other is not a clear or simple decision.

instead, programmers are given a fips-compliant "black box" drop-in openssl replacement which they're not expected to question, right? :)

If by "question" you mean an average web scripter with a community college degree in "IT" deciding what elliptic curve to use in conjunction with what cipher suite and protocol...then maybe the answer is yes?

Are you at all familiar with Go's TLS and crypto libraries? Because, by design, unsafe and exotic curve choices aren't in the standard library. Here's the entire set of curves exposed in 1.7 to Go's TLS:

    type CurveID uint16

    const (
        CurveP256 CurveID = 23
        CurveP384 CurveID = 24
        CurveP521 CurveID = 25
    )

>> and CurvePreferences to avoid unoptimized curves

The key word being unoptimized. In the article, the code snippet has a comment "Only use curves which have assembly implementations" and he mentions that "a client using CurveP384 would cause up to a second of CPU to be consumed on our machines." (presumably because it does not have an assembly implementation)

> Programmers should not need to know this stuff.

It can sometimes be a sign of a leaky abstraction, but programmers might need to know the performance characteristics of the code they write.

Reply on news.ycombinator.com