----- Original Message ----- > From: "mancha" <mancha1@xxxxxxxx> > To: openssh-unix-dev@xxxxxxxxxxx > Sent: Thursday, 13 February, 2014 9:16:30 PM > Subject: Re: 3des cipher and DH group size > > 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. <sarcasm>"Proving that P is equal NP is trivial and left as an exercise to the reader"</sarcasm> I already asked for literature on the subject. No book or standard I read stated anything to the effect of "IV size" == "security estimate". Suite B for secret (effectively 128 bit security) communication allows use of AES only in GCM or CTR mode. RFC 6239 specifies that SSH in Suite B must use AES in GCM mode. IV of AES 128 in GCM mode as used in SSH is 12 octets (96bit). How do you explain this disparity? > 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. People have been doing that for the past 60 years in cryptography. 95% of Internet still uses SHA-1 certificates! Including online banking. All my suggestions are already way past the levels any normal person or business needs. Those people that actually require higher security won't be using defaults if they have any clue what so ever. I want the defaults to be relatively secure and provide maximum interoperability. > 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? The FIPS limits the size of parameters exactly for interoperability reasons. If there was no need for key size agreement, we would all be using hardcoded 8k or 16k DH. And I'm not saying they should be confined. I'm saying that the proposed values shouldn't effectively depend on the MAC key size. > > --- > > 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. Security levels above 128 bit realistically have any meaning only if algorithms are broken or quantum computers come into play. In both cases all bets are off. At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. ENISA also recommends 3072 bit DH at 128 bit security level[1]. > 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. That was the first thing I tried, unfortunately, not supported by the cryptlib server in question. 1 - https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
