'Re: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to prime'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: gnutls-dev
Subject: Re: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to	prime
From: Peter Williams <home_pw () msn ! com>
Date: 2015-05-22 14:50:03
Message-ID: BAY404-EAS177893E5E072ED012682FBA92C00 () phx ! gbl
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Simply add comment that the value is output as an x409 integer in ber encoding (and \
perhaps der encoding).

In type theory, one can compare properly (according to the encoding).

When comparing certs (properly, as types), one needs formalities such as this. \
Historically, upon receipt of client cert during association binding, one issues a \
directory compare operation which, she executed by the resolver, would compare the \
value against the value(s) in the named directory record, to test existence of the \
operand in the "trust list".

Obviously a security critical operation, for which one uses formal type theory which, \
for certs was a little over formalized due to the any typing of the dh block.

All good fodder for structured vulnerability insertion in standards, of course, in \
the name of extensibility.

Sent from my Windows Phone
________________________________
From: Nikos Mavrogiannopoulos<mailto:nmav@gnutls.org>
Sent: ‎5/‎22/‎2015 12:06 AM
To: Thomas Klute<mailto:thomas2.klute@uni-dortmund.de>
Cc: bugs@gnutls.org<mailto:bugs@gnutls.org>
Subject: Re: [gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to prime

On Fri, May 22, 2015 at 12:17 AM, Thomas Klute
<thomas2.klute@uni-dortmund.de> wrote:
> Hello,
> I believe I have found a bug in gnutls_dh_get_group: It returns the
> prime with an extra zero byte at the beginning.

Indeed, I see that the number is written as a non-negative integer
there, so it will have a leading zero if the number would have been
interpreted as negative. The intention was to assist applications who
may import that value in an mpz_t value. Would it make sense to
document the fact that there may be a leading zero in that case,
rather than eliminating? That behavior has been for quite some time
and I believe any users of this function would already use or work
around it.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

[Attachment #5 (unknown)]

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>
<div style="font-family: Calibri,sans-serif; font-size: 11pt;">Simply add comment \
that the value is output as an x409 integer in ber encoding (and perhaps der \
encoding). 
In type theory, one can compare properly (according to the encoding). 
 
When comparing certs (properly, as types), one needs formalities such as this. \
Historically, upon receipt of client cert during association binding, one issues a \
directory compare operation which, she executed by the resolver, would compare the \
value against the value(s) in the named directory record, to test existence of the \
operand in the &quot;trust list&quot;. 
Obviously a security critical operation, for which one uses formal type theory which, \
for certs was a little over formalized due to the any typing of the dh block. \
 All good fodder for structured vulnerability insertion in standards, of course, \
in the name of extensibility. 
Sent from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
From: <a href="mailto:nmav@gnutls.org">Nikos Mavrogiannopoulos</a> Sent: \
‎5/‎22/‎2015 12:06 AM To: <a \
href="mailto:thomas2.klute@uni-dortmund.de">Thomas Klute</a> Cc: \
<a \
href="mailto:bugs@gnutls.org">bugs@gnutls.org</a> Subject: \
Re: \
[gnutls-devel] Bug: gnutls_dh_get_group prepends a zero byte to prime 
</div>
<div class="BodyFragment">
<div class="PlainText">On Fri, May 22, 2015 at 12:17 AM, Thomas Klute 
&lt;thomas2.klute@uni-dortmund.de&gt; wrote: 
&gt; Hello, 
&gt; I believe I have found a bug in gnutls_dh_get_group: It returns the 
&gt; prime with an extra zero byte at the beginning. 
 
Indeed, I see that the number is written as a non-negative integer 
there, so it will have a leading zero if the number would have been 
interpreted as negative. The intention was to assist applications who 
may import that value in an mpz_t value. Would it make sense to 
document the fact that there may be a leading zero in that case, 
rather than eliminating? That behavior has been for quite some time 
and I believe any users of this function would already use or work 
around it. 
 
regards, 
Nikos 
 
_______________________________________________ 
Gnutls-devel mailing list 
Gnutls-devel@lists.gnutls.org 
<a href="http://lists.gnupg.org/mailman/listinfo/gnutls-devel">http://lists.gnupg.org/mailman/listinfo/gnutls-devel</a> 
 </div>
</div>
</body>
</html>

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

[prev in list] [next in list] [prev in thread] [next in thread] 