X448 Key Exchange

[Joseph S. Testa II]

Hi all,

I'm interested in having X448 protocol available as an option, as it
gives a larger security margin over X25519. For anyone unfamiliar, it
is an Diffie-Hellman elliptic curve key exchange using Curve448 (defined
in RFC7748: https://tools.ietf.org/html/rfc7748). Furthermore, it is
included in the new TLS 1.3 specification (RFC8846:
https://tools.ietf.org/html/rfc8446).

A few questions:

1. What has been OpenSSH's involvement in this related IETF draft,
if any?: https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-08.html

2. Has there been any (even informal) plans for including X448?

3. Has anyone begun an implementation yet?

I've got some experience with OpenSSH development, so I wouldn't
mind writing a first draft of a patch. I just don't want to duplicate
efforts if its already ongoing, nor make a lone-wolf diff with no chance
of merging.

Thanks,
- Joe

[Damien Miller]

Post by Joseph S. Testa II
Hi all,
I'm interested in having X448 protocol available as an option, as it gives
a larger security margin over X25519. For anyone unfamiliar, it is an
https://tools.ietf.org/html/rfc7748). Furthermore, it is included in the new
TLS 1.3 specification (RFC8846: https://tools.ietf.org/html/rfc8446).
1. What has been OpenSSH's involvement in this related IETF draft, if
any?: https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-08.html
2. Has there been any (even informal) plans for including X448?
3. Has anyone begun an implementation yet?

We have any plans to add more crypto options to OpenSSH without a strong
justification, and I don't see one for X448-SHA512 ATM.

It's hard to imagine a world where X25519-SHA256 is broken but
X448-SHA512 is unaffected. AFAIK The most likely ways that X25519-SHA256
could fail are:

1) discovery of weaknesses in prime field EC crypto. This would almost
certainly affect both X25519/X448.

2) working quantum computers. Exciting times, everything breaks.

3) a weakness in SHA256. Online key agreement protocols like SSH KEX are
the last thing affected by collisions, because the attacker has such a
limited window in which to generate one and limited degrees of freedom
to manipulate the colliding data.

Personally, I'm more interested in a post-quantum KEX than another of the
same species...

-d

[Joseph S. Testa II]

Post by Damien Miller
We have any plans to add more crypto options to OpenSSH without a strong
justification, and I don't see one for X448-SHA512 ATM.

What I like about it is that it offers ~224 bit security level, whereas
X25519 offers ~128 bits (according to RFC7748). Hence, pairing X448
with AES256 would provide a full chain of security in the ~224 bit
level, no?

It also provides an alternative to the NIST P-curves (like P-521), which
some people suspect are back-doored by the NSA. P-521 in ECDSA has been
supported by OpenSSH for awhile now.

Post by Damien Miller
It's hard to imagine a world where X25519-SHA256 is broken but
X448-SHA512 is unaffected.

Ok, but still... X448 provides a higher security margin that pairs well
with AES256. That's a benefit users can enjoy immediately.

Post by Damien Miller
AFAIK The most likely ways that X25519-SHA256
1) discovery of weaknesses in prime field EC crypto. This would almost
certainly affect both X25519/X448.

The same could happen with the NIST P-curves, which OpenSSH already
supports.

Post by Damien Miller
2) working quantum computers. Exciting times, everything breaks.
3) a weakness in SHA256. Online key agreement protocols like SSH KEX are
the last thing affected by collisions, because the attacker has such a
limited window in which to generate one and limited degrees of freedom
to manipulate the colliding data.

(Did you mean SHA-512 here?)

Again, this can happen with the P-curves/SHA-256/384/512/ECDSA that is
already supported.

While we're daydreaming about this, what about SHA3-512? (note the "3")

Post by Damien Miller
Personally, I'm more interested in a post-quantum KEX than another of the
same species...

I'm very interested in this too. They're not exclusive to each other,
however.

I haven't stayed on top of post-quantum crypto lately, but isn't that
still years away? X448, on the other hand, is fully defined and was
recently put into TLS 1.3.

It wouldn't be hard to convince me that X448 is still a little too new;
perhaps we could wait a year and see how well it does with the new
scrutiny it gets from being in the TLS spec. If it survives its
field-testing, then we could move forward. And/or we make X448 a
last-priority KEX for a year or two and patiently see what happens.

Again, if this gets the green light, I'll be happy to write the initial
implementation.

Thanks,
- Joe

[Joseph S. Testa II]

Hmm... crickets. Does this imply that X448 in OpenSSH is not ever a
possibility?

- Joe

Post by Joseph S. Testa II

Post by Damien Miller
We have any plans to add more crypto options to OpenSSH without a strong
justification, and I don't see one for X448-SHA512 ATM.

What I like about it is that it offers ~224 bit security level, whereas
X25519 offers ~128 bits (according to RFC7748).  Hence, pairing X448
with AES256 would provide a full chain of security in the ~224 bit
level, no?
It also provides an alternative to the NIST P-curves (like P-521), which
some people suspect are back-doored by the NSA.  P-521 in ECDSA has been
supported by OpenSSH for awhile now.

Post by Damien Miller
It's hard to imagine a world where X25519-SHA256 is broken but
X448-SHA512 is unaffected.

Ok, but still... X448 provides a higher security margin that pairs well
with AES256.  That's a benefit users can enjoy immediately.

Post by Damien Miller
AFAIK The most likely ways that X25519-SHA256
1) discovery of weaknesses in prime field EC crypto. This would almost
certainly affect both X25519/X448.

The same could happen with the NIST P-curves, which OpenSSH already
supports.

Post by Damien Miller
2) working quantum computers. Exciting times, everything breaks.
3) a weakness in SHA256. Online key agreement protocols like SSH KEX are
the last thing affected by collisions, because the attacker has such a
limited window in which to generate one and limited degrees of freedom
to manipulate the colliding data.

(Did you mean SHA-512 here?)
Again, this can happen with the P-curves/SHA-256/384/512/ECDSA that is
already supported.
While we're daydreaming about this, what about SHA3-512? (note the "3")

Post by Damien Miller
Personally, I'm more interested in a post-quantum KEX than another of the
same species...

I'm very interested in this too.  They're not exclusive to each other,
however.
I haven't stayed on top of post-quantum crypto lately, but isn't that
still years away?  X448, on the other hand, is fully defined and was
recently put into TLS 1.3.
It wouldn't be hard to convince me that X448 is still a little too new;
perhaps we could wait a year and see how well it does with the new
scrutiny it gets from being in the TLS spec.  If it survives its
field-testing, then we could move forward.  And/or we make X448 a
last-priority KEX for a year or two and patiently see what happens.
Again, if this gets the green light, I'll be happy to write the initial
implementation.
  Thanks,
  - Joe

[Damien Miller]

Post by Joseph S. Testa II
Hmm... crickets. Does this imply that X448 in OpenSSH is not ever a
possibility?

I'm not sure what more to I can add.

Like I said: none of us presently see the value of it outweighing the
cost of having to support X448 and SHA3 in ~perpetuity.

-d

[Blumenthal, Uri - 0553 - MITLL]

Frankly, I'd much rather see PKCS#11 support for EC keys integrated.

—
Regards,
Uri

Post by Joseph S. Testa II
Hmm... crickets. Does this imply that X448 in OpenSSH is not ever a
possibility?

I'm not sure what more to I can add.

Like I said: none of us presently see the value of it outweighing the
cost of having to support X448 and SHA3 in ~perpetuity.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-***@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Tim Jones]

Post by Joseph S. Testa II
Again, if this gets the green light, I'll be happy to write the initial
implementation.

Given the touchy subject of the lack of Yubikey support for anything other than RSA (multiple patches put forward by the community, all ignored https://bugzilla.mindrot.org/show_bug.cgi?id=2474). I would say that the inner circle are likely to ignore your "initial implementation".

[Joseph S. Testa II]

Post by Tim Jones
Given the touchy subject of the lack of Yubikey support for anything other than RSA (multiple patches put forward by the community, all ignored https://bugzilla.mindrot.org/show_bug.cgi?id=2474). I would say that the inner circle are likely to ignore your "initial implementation".

If the maintainers of an open-source project ignore their community on
important subjects, then a fork fixes that problem, no?

I've maintained a fork before. Its not easy. I'd recommend to anyone
considering it that they make sure they've got a good amount of
community support, as well as 5+ hours of free time per week. (No, I'm
not volunteering for this.)

- Joe