5 ms·

The naming is unfortunate. Some people (Ubuntu...) have concluded that because some curves are branded "safe" that must mean all the other curves are therefore

The naming is unfortunate. Some people (Ubuntu...) have concluded that because some curves are branded "safe" that must mean all the other curves are therefore "unsafe" and must be aggressively phased out as if they were MD5. They're changing apt to refuse to download from repositories signed using NIST curves, for instance. This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor that nobody was able to find. But that isn't their stated justification. Instead they cite djb's website. It's apparently not clear enough that the "SafeCurves" are safe in the sense of being easier for cryptographers to implement without bugs, not in the sense that if you have two correct implementations of a "safe" and "unsafe" curve both are equally cryptographically strong. Therefore if people want to migrate to the "safe" curves over time, that's fine, but it's more like migrating stuff from C++ to Rust. It doesn't automatically imply the prior codebase was buggy, and if you do know of a specific bug then you need to fix it anyway so such migrations are always about reducing the risk of future problems through better engineering practices. That doesn't justify creating a lot of disruption across a distributed ecosystem.

red_admiral 2y ago
People migrating to djb's curves, or at least allowing them as a first-class citizen, include - SSH (which includes git over SSH - github suggests djb's Curve 25519 as default: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) - TLS (recommended in n1.3) - NIST (allows Curve25519, but isn't the default choice) - various cryptocurrency crap The people not on djb's curves yet are PGP/GPG/OpenPGP (available as an "advanced" option but not by default, for backwards compatibility) and as a consequence, debian's package signing (that mostly uses GPG with RSA, afaik). So ubuntu is in good company, even if it makes their job of working with "upstream" harder. [EDIT: apparently changed now - GPG has joined the ranks of djb-by-default] It's only like migrating from C to rust for the person implementing the crypto package and singature verifier. For the average package maintainer, they just have to generate a new key and pass a new command line flag to their sign command.
- normaler 2y ago
  GPG is using ed25519 keys as default since 2.3 https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...
- mike_hearn 2y ago
  Yes, but SSH isn't e.g. forbidding you from connecting to servers that use RSA or secp256r1, whereas they want to make apt refuse to access repositories that aren't using djb's curves.
  - red_admiral 2y ago
    SSH by default isn't, but admins can set up their own list of allowed ciphers in their config file. Github, for example, has banned ssh_dss - I think they still support ECDSA, but they only mention Curve25519 and RSA (with caveats) on their SSH keys page.
    - deleted 2y ago
      [deleted]
    - throw0101a 2y ago
      > SSH by default isn't Yes, and that's fine. But if SSH mandated a certain thing and disallowed even admins to change it it would be the equivalent problem. It's Ubuntu preventing the use of anything but "SafeCurves" that's the problem. If Ubuntu/Canonical want to use them—fine. (Maybe.†) But don't disable the functionality for admins. † Some regulated industries need to use certain Approved Algorithms, which may or may not include your favourite ones. Further there may be all sorts of other (workflow) tooling that may not support your favourite ones either, and forcing your favourites on other people (especially taking away other options) is a jerk move.
      - red_admiral 2y ago
        So, I'm mostly with you here, but I'd say disallowing e.g. MD5 (horribly broken) or anything involving Dual_EC (horribly suspicious) by force would be reasonable. ECDSA/secp* curves, that's more controversial. The TLS 1.2 -> 1.3 upgrade also disallowed a lot of previously used things, and this was generally considered to be a great improvement (though of course TLS endpoints can be backwards-compatible).
Y_Y 2y ago
> unless you think the NSA have an unknown backdoor that nobody was able to find Your post names sense to me, but I don't think it's too crazy to allow for the possibility that e.g. the NSA has backdoored some of the "recommended" crypto constants in current use.
- red_admiral 2y ago
  Snowden said that they were doing this, I think?
  - jiggawatts 2y ago
    The NSA definitely put back doors into cryptographic algorithms by forcing their variant into the NIST standards. E.g.: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
    - tialaramex 2y ago
      Dual EC DRBG is a bad design and so you shouldn't use it. It is reasonable to believe it's backdoored, but only the same way it would be reasonable to believe David Cameron stuck his dick in a dead pig. Some people say he did, he says he didn't, there's no conclusive proof available - and it's worth noting the "source" is a man who has a grudge against Cameron. My favourite also reasonable explanation for the mysterious Dual EC DBRG constants is that some senior person picked their favourite numbers (birthday of a niece, phone number of a friend, whatever) not realising that these should be Nothing Up My Sleeve Numbers. Later when a subordinate says "For documentation we need to explain these numbers" it was late to change them and so the agency can't do better than insist they were chosen at random. If this was crucial technology we should do the work to re-make it with Nothing Up My Sleeve Numbers, but it's garbage, indeed that's one reason for the suspicion, this is a very complicated machine, well suited to hiding a backdoor, why do this at all?
      - red_admiral 2y ago
        As far as I'm aware, the other problem with Dual EC is there's two kinds of componets you can use to build a DRBG: "chaotic" (think hash functions, or components thereof) and "algebraic" (highly structured but guaranteed to have certain properties such as minimum period size). Cryptographic common sense is that if you use an "algebraic" generator, you feed the output through a "chaotic" one at the end. This can't possibly harm security (as long as the output transformation doesn't depend on secret state) as there's a reduction in which the adversary just does the transformation themselves. This is even more important if the algebraic transformation is efficiently invertible in principle, for example if someone has extra secret knowledge (such as the dlog of the base point in use). If they'd used Dual-EC followed by SHA1 or something that would have not only been better according to folk wisdom, and demonstrably no worse for security (and costing very little compared to the EC operations) but it would also have shut down a lot of conjectured attacks that one could do with twiddled constants. Yet for some reason, Dual-EC decided to go with an algebraic approach without a "chaotic" output transformation, which is either extreme incompetence or strong evidence that someone is up to no good.
api 2y ago
Infosec suffers from a huge cargo cult and mindless sticky meme problem because so few people actually understand it. There are still admins who block all ICMP because of the “ping of death,” a Windows bug from either the late 1990s or 2000s. They don’t know this though. They just heard that ICMP is “dangerous.” People also don’t use IPv6 because they think NAT is a security feature. I guess it’s similar to baseless health fears and happens whenever people don’t really understand a domain. You get a proliferation of lore that is just repeated.
- upofadown 2y ago
  In either the case of infosec or health, the idea at work is that you can ensure that something is good simply by identifying and removing all that is bad. ... and everyone feels free to determine for themselves what is bad with no deep understanding of the involved systems.
- leeter 2y ago
  > People also don’t use IPv6 because they think NAT is a security feature. Literally had a sales engineer parrot this at me awhile back. I had to point out that the service they were offering was on the open internet. It only got worse from there. Le sigh...
- esdf 2y ago
  Windows had an ICMP CVE last year and also just released a patch for an IPv6 CVE. OpenSSH on Linux had a CVE recently too. Security in depth is reasonable and not baseless.
marcosdumay 2y ago
[flagged]
- tptacek 2y ago
  Again: NSA did not in fact add a backdoor to a curve; they published a backdoored RNG that used curves.
- mike_hearn 2y ago
  I didn't assume that, and laid out the argument why it might have happened above. I don't take a stance on the question of whether the NIST curves are OK either way, other than to defend those who argue there might be a problem (in the past I've seen this take dismissed as a conspiracy theory, which is clearly absurd). There isn't any specific evidence that there's a problem, only a failure to uphold the highest possible standards, which is a fairly weak form of evidence.
glitchc 2y ago
It's always a problem when scientific guidance becomes dogmatic.
- wahern 2y ago
  Bernstein is savvy enough that I suspect he anticipated how the term "safe" would be interpreted by different groups. That is, he expected and perhaps even intended the subsequent cargo culting.
TacticalCoder 2y ago
> They're changing apt to refuse to download from repositories signed using NIST curves, for instance. > > This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor... It's "only" a CSPRNG (Cryptographically INsecure PRNG in this case) but the NIST recommending a backdoored curve in the past is an undisputable fact. So I don't think it's that non-sensical to go for something simple like 2 exp 255 - 19. https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
- tptacek 2y ago
  I don't think you should be using words like "undisputable fact" in this thread, because Dual EC isn't a curve; it's a construction that uses curves.

red_admiral 2y ago

People migrating to djb's curves, or at least allowing them as a first-class citizen, include - SSH (which includes git over SSH - github suggests djb's Curve 25519 as default: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) - TLS (recommended in n1.3) - NIST (allows Curve25519, but isn't the default choice) - various cryptocurrency crap The people not on djb's curves yet are PGP/GPG/OpenPGP (available as an "advanced" option but not by default, for backwards compatibility) and as a consequence, debian's package signing (that mostly uses GPG with RSA, afaik). So ubuntu is in good company, even if it makes their job of working with "upstream" harder. [EDIT: apparently changed now - GPG has joined the ranks of djb-by-default] It's only like migrating from C to rust for the person implementing the crypto package and singature verifier. For the average package maintainer, they just have to generate a new key and pass a new command line flag to their sign command.

normaler 2y ago
GPG is using ed25519 keys as default since 2.3 https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...
mike_hearn 2y ago
Yes, but SSH isn't e.g. forbidding you from connecting to servers that use RSA or secp256r1, whereas they want to make apt refuse to access repositories that aren't using djb's curves.
- red_admiral 2y ago
  SSH by default isn't, but admins can set up their own list of allowed ciphers in their config file. Github, for example, has banned ssh_dss - I think they still support ECDSA, but they only mention Curve25519 and RSA (with caveats) on their SSH keys page.
  - deleted 2y ago
    [deleted]
  - throw0101a 2y ago
    > SSH by default isn't Yes, and that's fine. But if SSH mandated a certain thing and disallowed even admins to change it it would be the equivalent problem. It's Ubuntu preventing the use of anything but "SafeCurves" that's the problem. If Ubuntu/Canonical want to use them—fine. (Maybe.†) But don't disable the functionality for admins. † Some regulated industries need to use certain Approved Algorithms, which may or may not include your favourite ones. Further there may be all sorts of other (workflow) tooling that may not support your favourite ones either, and forcing your favourites on other people (especially taking away other options) is a jerk move.
    - red_admiral 2y ago
      So, I'm mostly with you here, but I'd say disallowing e.g. MD5 (horribly broken) or anything involving Dual_EC (horribly suspicious) by force would be reasonable. ECDSA/secp* curves, that's more controversial. The TLS 1.2 -> 1.3 upgrade also disallowed a lot of previously used things, and this was generally considered to be a great improvement (though of course TLS endpoints can be backwards-compatible).

Y_Y 2y ago

> unless you think the NSA have an unknown backdoor that nobody was able to find Your post names sense to me, but I don't think it's too crazy to allow for the possibility that e.g. the NSA has backdoored some of the "recommended" crypto constants in current use.

red_admiral 2y ago
Snowden said that they were doing this, I think?
- jiggawatts 2y ago
  The NSA definitely put back doors into cryptographic algorithms by forcing their variant into the NIST standards. E.g.: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
  - tialaramex 2y ago
    Dual EC DRBG is a bad design and so you shouldn't use it. It is reasonable to believe it's backdoored, but only the same way it would be reasonable to believe David Cameron stuck his dick in a dead pig. Some people say he did, he says he didn't, there's no conclusive proof available - and it's worth noting the "source" is a man who has a grudge against Cameron. My favourite also reasonable explanation for the mysterious Dual EC DBRG constants is that some senior person picked their favourite numbers (birthday of a niece, phone number of a friend, whatever) not realising that these should be Nothing Up My Sleeve Numbers. Later when a subordinate says "For documentation we need to explain these numbers" it was late to change them and so the agency can't do better than insist they were chosen at random. If this was crucial technology we should do the work to re-make it with Nothing Up My Sleeve Numbers, but it's garbage, indeed that's one reason for the suspicion, this is a very complicated machine, well suited to hiding a backdoor, why do this at all?
    - red_admiral 2y ago
      As far as I'm aware, the other problem with Dual EC is there's two kinds of componets you can use to build a DRBG: "chaotic" (think hash functions, or components thereof) and "algebraic" (highly structured but guaranteed to have certain properties such as minimum period size). Cryptographic common sense is that if you use an "algebraic" generator, you feed the output through a "chaotic" one at the end. This can't possibly harm security (as long as the output transformation doesn't depend on secret state) as there's a reduction in which the adversary just does the transformation themselves. This is even more important if the algebraic transformation is efficiently invertible in principle, for example if someone has extra secret knowledge (such as the dlog of the base point in use). If they'd used Dual-EC followed by SHA1 or something that would have not only been better according to folk wisdom, and demonstrably no worse for security (and costing very little compared to the EC operations) but it would also have shut down a lot of conjectured attacks that one could do with twiddled constants. Yet for some reason, Dual-EC decided to go with an algebraic approach without a "chaotic" output transformation, which is either extreme incompetence or strong evidence that someone is up to no good.

api 2y ago

Infosec suffers from a huge cargo cult and mindless sticky meme problem because so few people actually understand it. There are still admins who block all ICMP because of the “ping of death,” a Windows bug from either the late 1990s or 2000s. They don’t know this though. They just heard that ICMP is “dangerous.” People also don’t use IPv6 because they think NAT is a security feature. I guess it’s similar to baseless health fears and happens whenever people don’t really understand a domain. You get a proliferation of lore that is just repeated.

upofadown 2y ago
In either the case of infosec or health, the idea at work is that you can ensure that something is good simply by identifying and removing all that is bad. ... and everyone feels free to determine for themselves what is bad with no deep understanding of the involved systems.
leeter 2y ago
> People also don’t use IPv6 because they think NAT is a security feature. Literally had a sales engineer parrot this at me awhile back. I had to point out that the service they were offering was on the open internet. It only got worse from there. Le sigh...
esdf 2y ago
Windows had an ICMP CVE last year and also just released a patch for an IPv6 CVE. OpenSSH on Linux had a CVE recently too. Security in depth is reasonable and not baseless.

marcosdumay 2y ago

[flagged]

tptacek 2y ago
Again: NSA did not in fact add a backdoor to a curve; they published a backdoored RNG that used curves.
mike_hearn 2y ago
I didn't assume that, and laid out the argument why it might have happened above. I don't take a stance on the question of whether the NIST curves are OK either way, other than to defend those who argue there might be a problem (in the past I've seen this take dismissed as a conspiracy theory, which is clearly absurd). There isn't any specific evidence that there's a problem, only a failure to uphold the highest possible standards, which is a fairly weak form of evidence.

glitchc 2y ago

It's always a problem when scientific guidance becomes dogmatic.

wahern 2y ago
Bernstein is savvy enough that I suspect he anticipated how the term "safe" would be interpreted by different groups. That is, he expected and perhaps even intended the subsequent cargo culting.

TacticalCoder 2y ago

> They're changing apt to refuse to download from repositories signed using NIST curves, for instance. > > This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor... It's "only" a CSPRNG (Cryptographically INsecure PRNG in this case) but the NIST recommending a backdoored curve in the past is an undisputable fact. So I don't think it's that non-sensical to go for something simple like 2 exp 255 - 19. https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG

tptacek 2y ago
I don't think you should be using words like "undisputable fact" in this thread, because Dual EC isn't a curve; it's a construction that uses curves.