X448 Key Exchange

[Joseph S. Testa II]

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