3des cipher and DH group size

[mancha]

Hubert Kario <hkario <at> redhat.com> writes:

> [SNIP]

Hi.

I've identified three distinct points you've made so far;
here are my brief reactions:

1. IV length and block size should not be taken into
account for DH GEX group size computation.

I'll leave the particulars of birthday collisions and how
they link IV length and block size to security level as an
exercise to the reader.

2. DH GEX group size requests should be as minimal as
possible to accommodate the limited computing power of
embedded devices (e.g. smartphones)

I would be extremely uncomfortable if security
infrastructure I relied on constrained its cryptographic
primitives - potentially to the detriment of overall
security - in order to facilitate use with phones,
consumer-grade routers, or other devices characterized
by limited processing power.

3. OpenSSH primitives should be confined to ensure
interoperability with implementations that are RFC
non-compliant (e.g. cryptlib & DH GEX & RFC 4419).

What's the point of standards then?

---

I personally would like larger increases in DH GEX
requests. NIST SP 800-57, the basis for the OpenSSH
change, recommends a value well above 8192 bits (which
OpenSSH sets as a hard max following RFC 4419) when
supporting 256 bits of security. Not to mention that
other research initiatives (e.g. ECRYPT II) recommend
even larger DH group sizes than NIST at every security
level.

Finally, if HW/SW limitations of embedded devices or
non-compliant servers is of major concern and you want to
force a 2048-bit DH modulus, why not use Oakley group 14?
That's an RFC 4253 REQUIRED.

--mancha