Re: SSH key algorithm updates

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

> On Fri, 2015-11-06 at 06:16 +0100, Niels Möller wrote:

[about hmac-sha1]

> Your understanding matches mine.  However, it's still only a 160-bit
> hash, and eventually that just stops being strong enough.  I'd like to
> have something stronger implemented and reasonably widely deployed
> before then.

Reasonable. We need to specify a new REQUIRED algorithm. Demoting
HMAC-SHA1 to recommended lets implementations drop support in due time
without formally departing from the standard. It would kind-of make
sense to specify a flag day "algothithm X is REQUIRED until date Y,
after which is is only RECOMMENDED", but not worth the effort to
formalize.

> SSH's 3des-cbc is three-key EDE 3DES.  It has an effective key length of
> 112 bits, and so is weaker than AES128.

But the "effective key bits" attack is a time/memory-tradeoff which
requires a huge table, right? So in practice I'm not sure a brute force
attack on 3DES really can be expected to be 16 times faster than a brute
force attack on aes128.

> It's also a CBC mode and AFAIK has the same problems as all of SSH's
> other CBC-mode ciphers.

Right, reprecating CBC makes sense. What's the status of 3des-ctr mode?
Not at all as widely deployed as 3des-cbc, I imagine.

> Group exchange doesn't have to mean live, dynamic group generation.  It
> can work fine with a set of fixed groups, either manually configured or
> compiled in.  

Hmm. I was thinking of the receiver of the group list, it has to be
prepared to handle any group, and make an intelligent choice. My gut
feeling is that there may be some subtleties there. But maybe there's no
issue to trust the server and just choose the largest group you think
you can afford to compute with.

> I'd have to go back and look, but I think the sense of the
> group at the time was that there was no reason to define more variations
> with the group baked into the algorithm names.

I can see that argument. Perhaps we shouldn't get into that now, but I
could see scenarious where client might have a preference like

  1. Large Z_p group (preferred option)
  2. curve25519      (acceptable)
  3. Small Z_p group (not acceptable)

Then negotiation fails in the case that they agree on group exchange,
but the server offers only small Z_p groups. While with named groups,
they might have agreed to use curve25519.

Feel free to ignore this discussion if you find in untimely or
distracting. There's a spec for it and noone on the list have raised any
serious security concerns.

>> Is that related to the (now expireed, I think) draft I and Simon wrote
>> some time ago? I'm not following the cfrg work.
>
> I'm not sure.  It's only a month old, and does have Simon's name on it.

Hmm. It looks like like it's based on our earlier version. I think the python
reference implementation of ed25519 is the same. Nice.

Regards,
/Niels


-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.