Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Subject: Re: gnutls.c warning
Date: Fri, 28 Jun 2013 10:22:15 -0400	[thread overview]
Message-ID: <878v1upb6w.fsf@lifelogs.com> (raw)
In-Reply-To: <87bo6q5s01.fsf@thinkpad.tsdh.de>

On Fri, 28 Jun 2013 14:39:26 +0200 Tassilo Horn <tsdh@gnu.org> wrote: 

TH> "Herbert J. Skuhra" <hskuhra@eumx.net> writes:
>>> When the client (Emacs) and the server negotiate to 1024, for
>>> instance, everything is kosher.  They will try for the highest
>>> number.
>> 
>> Will they?
>> 
>> With gnutls-min-prime-bits = 256:
>> 
>> gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange
>> has been lowered to 256 bits and this may allow decryption of the session data
>> 
>> With gnutls-min-prime-bits = 512:
>> 
>> gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange
>> has been lowered to 512 bits and this may allow decryption of the session data
>> 
>> The warning is gone if value is >= 768 or nil.

TH> Same here, so it looks like it's the other way round: they seem to
TH> negotiate the lowest number of prime bits the client is willing to
TH> accept.  Or well, possibly servers can be configured to do it that way,
TH> cause I think I got that warning not with all IMAP servers I'm using.

gnutls.el patch that introduces the setting:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-07/msg00657.html

I can't find a clear explanation of what this parameter means in the
negotiation, and in GnuTLS 3.1.7 the function `gnutls_dh_set_prime_bits'
is actually deprecated.  The clearest explanation is in the
documentation for `gnutls_dh_set_prime_bits':
http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits

"This function sets the number of bits, for use in a Diffie-Hellman key
exchange. This is used both in DH ephemeral and DH anonymous cipher
suites. This will set the minimum size of the prime that will be used
for the handshake.

In the client side it sets the minimum accepted number of bits. If a
server sends a prime with less bits than that
GNUTLS_E_DH_PRIME_UNACCEPTABLE will be returned by the handshake.

Note that values lower than 512 bits may allow decryption of the
exchanged data."

So I can't say for sure, but I think the answer is "it depends on the
server" rather than "they negotiate the lowest/highest/etc number of
bits."  I would suggest asking on the GnuTLS mailing list to get a
definitive answer.

HTH
Ted




  reply	other threads:[~2013-06-28 14:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-25 19:07 J. David Boyd
2013-06-25 21:38 ` Herbert J. Skuhra
2013-06-26  6:25   ` Tassilo Horn
2013-06-27 17:43     ` Ted Zlatanov
2013-06-27 22:53       ` Herbert J. Skuhra
2013-06-28 12:39         ` Tassilo Horn
2013-06-28 14:22           ` Ted Zlatanov [this message]
2013-07-01 12:41             ` Ted Zlatanov
2013-06-26 15:47   ` J. David Boyd
2013-06-26 16:59     ` J. David Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878v1upb6w.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).