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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
