[curves] Simple EC-based transport protocols (was Simple Peer-to-Peer Security (SPTPS))
trevp at trevp.net
Wed Apr 30 09:27:59 PDT 2014
On 4/29/14, 9:46 PM, Tony Arcieri wrote:
> This is a minimalist transport encryption protocol with forward secrecy,
> based on Curve25519 and ChaCha20+Poly1305
Seems vulnerable to the usual "identity misbinding" aka "unknown key
share" issue where the attacker signs a victim's KEX to take credit for
data sent by the victim.
It also assumes "peers have each other's credentials beforehand", so
doesn't support Trust-On-First-Use or certificate trust models.
But the idea of a minimalist, EC-based transport protocol is a good one.
CurveCP is one candidate . I have a hobby project here ("Noise"
). These protocols use ECDH instead of signatures, which makes
implementation simpler and messages smaller.
For a minimalist protocol, you might also want a single ciphersuite (or
a single "mandatory-to-implement" ciphersuite). Also, for a
mutually-authenticated ECDH protocol like CurveCP, Noise, or MQV, both
parties need keys on the same curve. So choosing the "best" curve
becomes important here.
I think you could argue this in several directions:
(1) Curve25519 should be chosen, since it's fast enough to work in a
wide range of use-cases.
(2) An "extra-strength" curve should be chosen (eg Goldilocks or
Curve41417) to provide long-term security margin against EC
cryptanalysis, despite the speed hit (Goldilocks appears ~3.5x slower
than Curve25519 ).
(3) Separate DH and signature curves should be chosen, with an
extra-strength DH for long-term confidentiality and Ed25519 signatures
(4) A non-EC, post-quantum key agreement should be chosen to provide
long-term security margin again quantum cryptanalysis.
In Noise I voted (2) for a general-purpose protocol, since I like the
security and simplicity of building everything around a single
But these are all reasonable, IMO, so I'm curious how other people lean.
More information about the Curves