On 09/13/2018 08:18 PM, Damien Miller wrote:> 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.> 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.> 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.The same could happen with the NIST P-curves, which OpenSSH already supports.> 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")> 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 Founder & Principle Security Consultant Positron Security
Hmm... crickets. Does this imply that X448 in OpenSSH is not ever a
possibility?
- Joe
On 09/14/2018 09:20 AM, Joseph S. Testa II wrote:> On 09/13/2018 08:18 PM, Damien Miller wrote:
>> 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.
>
>
>> 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.
>
>
>> 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.
>
> The same could happen with the NIST P-curves, which OpenSSH already
> supports.
>
>
>> 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")
>
>
>> 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
Founder & Principle Security Consultant
Positron Security
> 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".
On 09/21/2018 08:24 AM, Tim Jones wrote:> 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 -- Joseph S. Testa II Founder & Principle Security Consultant Positron Security
On Fri, 21 Sep 2018, Joseph S. Testa II wrote:> 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