Re: [CVS] OpenSSL: openssl/ FAQ

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Richard Levitte - VMS Whacker
It's interesting to see this happening.  We have two parts of OpenSSL,
sha512 and pqueue, that solve the 64-bit integer problem in very
different manners.

Would it be a bad thing to have a header file in crypto/bn that
provides a guaranteed 64-bit number, possibly through BIGNUM, with
macros to distinguish between the true 64-bit integer and BIGNUM cases
(like pq_compat.h has today), and have both sha512 and pqueue use it?

I'm not saying that sha512 should be implemented using BINUMs, but
rather that it should be possible to detect if 64-bit integers are
support as far as OpenSSL knows, and have sha512 implemented in those
terms instead of forcing the user to say no-sha512 because his first
build failed?

In message <[hidden email]> on Mon,  6 Jun 2005 11:32:03 +0200 (CEST), "Andy Polyakov" <[hidden email]> said:

appro>   OpenSSL CVS Repository
appro>   http://cvs.openssl.org/
appro>   ____________________________________________________________________________
appro>
appro>   Server: cvs.openssl.org                  Name:   Andy Polyakov
appro>   Root:   /v/openssl/cvs                   Email:  [hidden email]
appro>   Module: openssl                          Date:   06-Jun-2005 11:32:02
appro>   Branch: HEAD                             Handle: 2005060610320100
appro>
appro>   Modified files:
appro>     openssl                 FAQ
appro>
appro>   Log:
appro>     FAQ to mention no-sha512 as option for compilers without support for 64-bit
appro>     integer type.
appro>
appro>   Summary:
appro>     Revision    Changes     Path
appro>     1.103       +10 -0      openssl/FAQ
appro>   ____________________________________________________________________________
appro>
appro>   patch -p0 <<'@@ .'
appro>   Index: openssl/FAQ
appro>   ============================================================================
appro>   $ cvs diff -u -r1.102 -r1.103 FAQ
appro>   --- openssl/FAQ 19 May 2005 19:54:49 -0000 1.102
appro>   +++ openssl/FAQ 6 Jun 2005 09:32:01 -0000 1.103
appro>   @@ -47,6 +47,7 @@
appro>    * Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]?
appro>    * Why does OpenBSD-i386 build fail on des-586.s with "Unimplemented segment type"?
appro>    * Why does the OpenSSL test suite fail in sha512t on x86 CPU?
appro>   +* Why does compiler fail to compile sha512.c?
appro>    
appro>    [PROG] Questions about programming with OpenSSL
appro>    
appro>   @@ -607,6 +608,15 @@
appro>    instruction extentions. See accompanying INSTALL file and
appro>    OPENSSL_ia32cap(3) documentation page for further information.
appro>    
appro>   +* Why does compiler fail to compile sha512.c?
appro>   +
appro>   +OpenSSL SHA-512 implementation depends on compiler support for 64-bit
appro>   +integer type. Few elder compilers [ULTRIX cc, SCO compiler to mention a
appro>   +couple] lack support for this and therefore are incapable of compiling
appro>   +the module in question. The recommendation is to disable SHA-512 by
appro>   +adding no-sha512 to ./config [or ./Configure] command line. Another
appro>   +possible alternative might be to switch to GCC.
appro>   +
appro>    [PROG] ========================================================================
appro>    
appro>    * Is OpenSSL thread-safe?
appro>   @@ .
appro> ______________________________________________________________________
appro> OpenSSL Project                                 http://www.openssl.org
appro> CVS Repository Commit List                     [hidden email]
appro> Automated List Manager                           [hidden email]
appro>

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Andy Polyakov
> It's interesting to see this happening.  We have two parts of OpenSSL,
> sha512 and pqueue, that solve the 64-bit integer problem in very
> different manners.

:-)

> Would it be a bad thing to have a header file in crypto/bn that
> provides a guaranteed 64-bit number, possibly through BIGNUM, with
> macros to distinguish between the true 64-bit integer and BIGNUM cases
> (like pq_compat.h has today), and have both sha512 and pqueue use it?

1. I'm reluctant to include bn.h to non-bn code, because it's nothing
but counterintuitive [and is not good in long run]. 2. My standpoint is
[still] that pqueue/dtls1 should not have dependancy on bh.h either. 3.
Using BIGNUM for DTLS purposes is *total* overkill. To back this up I'm
going to suggest alternative, 64-bit neutral pq code shortly:-)

> I'm not saying that sha512 should be implemented using BINUMs, but
> rather that it should be possible to detect if 64-bit integers are
> support as far as OpenSSL knows, and have sha512 implemented in those
> terms instead of forcing the user to say no-sha512 because his first
> build failed?

We can discuss this after I suggest the alternative code... A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Richard Levitte - VMS Whacker
In message <[hidden email]> on Mon, 06 Jun 2005 22:32:05 +0200, Andy Polyakov <[hidden email]> said:

appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
appro>    nothing but counterintuitive [and is not good in long run].
appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
appro>    dependancy on bh.h either.
appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
appro>    this up I'm going to suggest alternative, 64-bit neutral pq
appro>    code shortly:-)

I agree.  I'd rather see something like crypto/64bit.h (which is
exported) and crypto/64bit.c.  However, considering we're not very far
from releasing 0.9.8 (everyone look at http://www.openssl.org/news/state.html!)
I'd say a change to something completely new in this department should
only be added to the 0.9.8 tree with lots of caution, and that the
BIGNUM reference in pqueue may be a necessary compromise.  In
0.9.9-dev, the matter is different, and I for one welcome any more
developed 64-bit integer handling there.

About the code in crypto/bn: there are some low-level routines that
are specifically designed to handle 64-bit integers represented as two
32-bit integers.  That code should be used, there's no point not to.
So it would be natural to depend on that part of crypto/bn...

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Andy Polyakov
> appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
> appro>    nothing but counterintuitive [and is not good in long run].
> appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
> appro>    dependancy on bh.h either.
> appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
> appro>    this up I'm going to suggest alternative, 64-bit neutral pq
> appro>    code shortly:-)
>
> I agree.

Consider http://cvs.openssl.org/chngview?cn=13985 for 0.9.8.

> I'd say a change to something completely new in this department should
> only be added to the 0.9.8 tree with lots of caution,

The proposed path fixes bugs too:-) BTW, does anybody see bug here:

        bitmap <<= (a-b);

BTW, is there any test application? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Richard Levitte - VMS Whacker
In message <[hidden email]> on Wed, 08 Jun 2005 00:32:52 +0200, Andy Polyakov <[hidden email]> said:

appro> > appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
appro> > appro>    nothing but counterintuitive [and is not good in long run].
appro> > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
appro> > appro>    dependancy on bh.h either.
appro> > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
appro> > appro>    this up I'm going to suggest alternative, 64-bit neutral pq
appro> > appro>    code shortly:-)
appro> >
appro> > I agree.
appro>
appro> Consider http://cvs.openssl.org/chngview?cn=13985 for 0.9.8.

That was... unexpected :-).  I was expecting some better kind of
64-bit emulating type, but definitely not an array of unsigned char.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Richard Levitte - VMS Whacker
In message <[hidden email]> on Wed, 08 Jun 2005 06:16:54 +0200 (CEST), Richard Levitte - VMS Whacker <[hidden email]> said:

richard> In message <[hidden email]> on Wed, 08 Jun 2005 00:32:52 +0200, Andy Polyakov <[hidden email]> said:
richard>
richard> appro> > appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
richard> appro> > appro>    nothing but counterintuitive [and is not good in long run].
richard> appro> > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
richard> appro> > appro>    dependancy on bh.h either.
richard> appro> > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
richard> appro> > appro>    this up I'm going to suggest alternative, 64-bit neutral pq
richard> appro> > appro>    code shortly:-)
richard> appro> >
richard> appro> > I agree.
richard> appro>
richard> appro> Consider http://cvs.openssl.org/chngview?cn=13985 for 0.9.8.
richard>
richard> That was... unexpected :-).  I was expecting some better kind of
richard> 64-bit emulating type, but definitely not an array of unsigned char.

Don't take that as a complaint, BTW.  If it works, I see no problem
having that in 0.9.8, and maybe develop a better 64-bit type for
0.9.9.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

Andy Polyakov
In reply to this post by Richard Levitte - VMS Whacker
> appro> > appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
> appro> > appro>    nothing but counterintuitive [and is not good in long run].
> appro> > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
> appro> > appro>    dependancy on bh.h either.
> appro> > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
> appro> > appro>    this up I'm going to suggest alternative, 64-bit neutral pq
> appro> > appro>    code shortly:-)
> appro> >
> appro> > I agree.
> appro>
> appro> Consider http://cvs.openssl.org/chngview?cn=13985 for 0.9.8.
>
> That was... unexpected :-).  I was expecting some better kind of
> 64-bit emulating type, but definitely not an array of unsigned char.

We sometimes forget that short array of unsigned chars can be useful
too:-) But what is concern? Performance? Of course subtracting of two
values in registers is way faster than satsub64be, *but* keep in mind
that those values get collected into registers with character loads and
shifts first, so altogether it's hardly faster [just a tad]. The only
concern is probably traversing pqueue... But the list is not expected to
be very long, is it? But if it is, then one can cache the value in host
byte order upon insertion into list... BTW, is original contributor on
the list? A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CVS] OpenSSL: openssl/ FAQ

nagendra modadugu
In reply to this post by Richard Levitte - VMS Whacker

Apologies for the delayed joining of the discussion.

I chose to use BN to implement 64-bit numbers because (1) it was
little code, (2) the abstraction was clean, (3) BN works on all
supported platforms, (4) the places where emulated 64-bit numbers are
used are not performance critical, and (5) no changes were required
outside of pqueue and DTLS code.

> appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
> appro>    nothing but counterintuitive [and is not good in long run].
> appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
> appro>    dependancy on bh.h either.

I don't quite follow this point.  Is it that pqueue is not
self-contained?  (There are already a number of cross-dependancies
in libcrypto, including on bn.h)

> appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
> appro>    this up I'm going to suggest alternative, 64-bit neutral pq
> appro>    code shortly:-)

That works for me.  Though, I'll add that neither pqueue nor DTLS do
anything heavy with PQ_64BIT--the performance gain for the few
platforms that do need the specialized code will be minimal.

nagendra

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]