bug#11267: 24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 18 May 2012 04:38:01 -0700 (PDT) n.mavrogiannopoulos@gmail.com wrote: 

nm> On Tuesday, May 15, 2012 10:24:56 AM UTC+2, Ted Zlatanov wrote:
>> On Sun, 13 May 2012 21:04:24 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 
>> 
LMI> "Roland Winkler" <winkler@gnu.org> writes:
>> >> Also, it would be good (though I don't know whether a generic answer
>> >> is possible) to give some guidance on "reasonable" values for
>> >> `gnutls-min-prime-bits' as compared to cases where it would be
>> >> better to contact the sysadmin of the server requesting a change in
>> >> the setup of the server.
>> 
LMI> Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
LMI> that "reasonable" is, because there's apparently quite a few servers out
LMI> there that has less bits than whatever the GnuTLS default is.  Which
LMI> isn't a very good user experience.
>> 
>> I'm OK with lowering it to 256.

nm> Note that Diffie-Hellman group of 256-bits means that the communication can be
nm> decrypted by someone that stored the session. The default minimum
nm> accepted value in gnutls is already weak according to [0] (727 bits)
nm> but a good balance between security and compatibility. (other
nm> implementations like NSS have similar limits).

nm> If you need to support weaker servers you could warn your users of the consequences.

nm> [0]. http://www.keylength.com/en/3/

Hi Nikos,

We've continued the discussion in bug#15057 (about the min prime bits)
and bug#16253 (about the logging).  I've copied all three bug trackers
on this e-mail.  I hope that helps connect them for searches and when we
close them.

Roland, if you are satisfied with the direction taken in those bugs, we
can probably close this one.

Thanks
Ted