----- Original Message ----- > From: "Damien Miller" <djm@xxxxxxxxxxx> > To: "Hubert Kario" <hkario@xxxxxxxxxx> > Cc: openssh-unix-dev@xxxxxxxxxxx > Sent: Tuesday, 4 February, 2014 11:42:31 PM > Subject: Re: 3des cipher and DH group size > > On Tue, 4 Feb 2014, Hubert Kario wrote: > > > Hi all! > > > > Continuing the discussion from > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > > > I have looked at the changes made to implement automatic selection of DH > > groups and there are few changes confusing to me, to say the least. > > > > Especially 1.97~1.96 rev diff of kex.c: > > > > > + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > > secure primitive? Since DH KEX is computationally expensive (think > > smartphones), > > shouldn't we try to use as small DH parameters as possible? > > I think that it's reasonable for users, when they select a cipher of a > given strength, to expect that ssh actually provides enough key material > to properly use it. The previous version did bind cipher to DH sizes so this expectation was met. Problem is, that now when you're running in FIPS mode the chosen HMAC in worst case is sha1-based so the DH moduli end up being 7680 bits in size even when the selected cipher is 3DES: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent as a result, connection to cryptlib server in FIPS mode doesn't work. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hkario@xxxxxxxxxx Web: www.cz.redhat.com 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
