[iofiiiiiiiii]

What is the state of the art for doing encryption with ECC? The author just says "use NaCl" here but what should I do if I am not in a position to do that but can still use ECC?

My understanding of ECC is that it is not really suitable for encryption as-is, as RSA was, rather it is used for key agreement (somehow through a multi-step process that I do not understand). But it is unclear how much of this is just rumor and implementation limitations.

[red_admiral]

If you can't use NaCl directly you may still be able to use the underlying "25519" Edwards curve. The point is that it was designed in such a way to make implementation bugs ("bad" points, separate addition/doubling formulas, and other edge cases) either non-existent or at least easy to deal with.

In contrast, ECDSA seems like it was almost designed by the NSA to make it as easy as possible to accidentally introduce an exploitable implementation bug.

You are right that ECC is mainly a key agreement/transport and signing tool, not to be used directly for encryption except in very special cases (e.g. modified ElGamal for verifiable voting schemes).

[loup-vaillant]

> The author just says "use NaCl" here but what should I do if I am not in a position to do that but can still use ECC?

Not being in a position to use even a single-file C library like Monocypher (well, 2 compilation units if you want the optional parts), is… well, unusual.

> My understanding of ECC is that it is not really suitable for encryption as-is, as RSA was, rather it is used for key agreement (somehow through a multi-step process that I do not understand)

The steps are: once you’ve done key agreement, you have a shared key. You can then use authenticated encryption with that key. One caveat though is that key agreement often don’t give you an actual key, but a statistically biased shared secret. So the actual steps are:

  1. Do key agreement. You now have a shared secret.
  2. Hash your shared secret. You now have a key.
  3. Encrypt your messages with your key. Use AEAD for this.

Caveat: I omitted a number of important details, most notably forward secrecy.

[opheliate]

The author definitely should have clarified this. The standard is to use ECC for key exchange only. This can be done entirely offline - each party chooses a random secret scalar, and multiplies the base point of the curve by that scalar to produce a public point. You publish your public point in advance of communication. When you want to send a message, you multiply the other party’s public point by your secret scalar to obtain a shared key. Then, just use a well-studied symmetric AEAD construction to encrypt messages.

Of course, this doesn’t incorporate any forward secrecy, which is a key benefit of using something like TLS or Noise rather than rolling your own custom protocol.