Re: 9GB libcrypto.a in openssl-1.0.1c
On Sun, Jul 29, 2012 at 11:00 AM, Dennis Clarke dcla...@blastwave.org wrote: After a build of openssl-1.0.1c on Solaris 10 with the Sun Studio 12 compilers I was very surprised to see this : # ls -l libcrypto.a -rw-r--r-- 1 root root 9908820968 Jul 17 19:47 libcrypto.a It's not supposed to be that large. I've never built on Solaris, but this OSX build is typical as far as I can tell: -rw-r--r-- 1 root admin 3136968 May 10 09:28 /opt/local/lib/libcrypto.a I'm inclined to suspect something funny with the Sun Studio compilers. I would be interested to know what size libcrypto.a prints for you. That will indicate which of the object files in the library is/are responsible for its overall size. zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Make issue with openssl-1.0.0f and openssl-1.0.0j
On Tue, Jul 17, 2012 at 11:18 AM, Barone, Philip pbar...@harris.com wrote: 2. Does the 11GB .a file contain multiple copies of each .o file, perhaps every version you ever compiled? (You can test this with the command $ ar -t libcrypto.a This does not appear to be the issue either Server1 ar -t libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o cpt_err.o ebcdic.o uid.o o_time.o o_str.o o_dir.o sparcv9cap.o sparccpuid.o o_names.o obj_dat.o obj_lib.o obj_err.o obj_xref.o md4_dgst.o md4_one.o md5_dgst.o md5_one.o This list should be much longer. What does size libcrypto.a print? zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 2012-06-04 8:10 PM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. C89/90 is hard to find now, but it definitely did specify free(NULL) is no-op. You say elsethread you may have confused C89 free() with generally similar calls in OS or perhaps libraries; those certainly might not be safe for NULL. According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the last widely-used platform that crashed on free(NULL) was SunOS 4, which stopped being a reasonable portability target around 2007. SunOS 4 was noncompliant with C89 in dozens of other ways as well. zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
On Tue, Jun 5, 2012 at 4:35 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 6/5/2012 6:19 AM, Zack Weinberg wrote: According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the last widely-used platform that crashed on free(NULL) was SunOS 4, which stopped being a reasonable portability target around 2007. Actually, that is not really what it says when read closely. What it really says is than some guy named Jim Meyering believed (possibly mistakenly) that the free(NULL) issue existed only on SunOS 4 (he gave no reason for that belief). Rather, that it existed on many pre-C89 platforms including SunOS 4, but all of them ceased to be interesting portability targets before SunOS 4 did. On top of that Jim Meyering may have referring to some political GNU policy of not wanting to support SunOS 4 as an official porting target (again, Jim Meyering gave no reason for why SunOS 4 became irrelevant in 2007). I'm not aware of any general GNU policy for or against supporting old systems (but I am not necessarily in the loop for such things). However, I trust Jim Meyering not to make such statements lightly. (I would have put SunOS 4's irrelevance date considerably earlier, tbh.) Enough about this, but I do have a related question which is more on-topic for this list: Do the various OBJECT_free() functions *defined by libssl and libcrypto* make the same promise to be a no-op when called on a NULL pointer? zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Writing constant-time elliptic curve calculations against the low-level OpenSSL API
I've got a project ( https://github.com/zackw/moeller-ref ) which does
a bunch of elliptic curve operations against custom curves, using the
OpenSSL and/or Crypto++ low-level APIs (two parallel implementations
of the same asymmetric cryptosystem). One function in each
implementation performs decryption and therefore needs to run in
constant time to prevent timing attacks. But nearly all the functions
in openssl/ec.h and openssl/bn.h can fail, which means there are a
good *nine* early exits from the decryption routine, all of them
potentially data-dependent.
I'm appending the problematic routine. Does anyone know how to revise
it so that even under failure conditions it always takes the same
amount of time? You can see the whole file at
https://github.com/zackw/moeller-ref/blob/master/mref-o.c .
(The Crypto++ implementation probably has the same problem, but it's
so slow that I do not imagine its being used for reals, and in any
case, the immediate use I have for this code is in an application
based on OpenSSL.)
Thanks,
zw
int
MKEM_decode_message(const MKEM *kp, uint8_t *secret, const uint8_t *message)
{
int use_curve0 = !(message[0] kp-params-curve_bit);
const EC_GROUP *ca = use_curve0 ? kp-params-c0 : kp-params-c1;
const BIGNUM *sa = use_curve0 ? kp-s0 : kp-s1;
EC_POINT *q = 0, *r = 0;
uint8_t *unpadded = 0;
BIGNUM x, y;
size_t mlen = kp-params-msgsize;
int rv;
if (!kp-s0 || !kp-s1) /* secret key not available */
return -1;
BN_init(x);
BN_init(y);
FAILZ(q = EC_POINT_new(ca));
FAILZ(r = EC_POINT_new(ca));
FAILZ(unpadded = malloc(mlen + 1));
/* Copy the message, erase the padding bits, and put an 0x02 byte on
the front so we can use EC_POINT_oct2point to recover the
y-coordinate. */
unpadded[0] = 0x02;
unpadded[1] = (message[0] ~(kp-params-pad_mask|kp-params-curve_bit));
memcpy(unpadded[2], message[1], mlen - 1);
FAILZ(EC_POINT_oct2point(ca, q, unpadded, mlen + 1,
kp-params-ctx));
FAILZ(EC_POINT_mul(ca, r, 0, q, sa, kp-params-ctx));
FAILZ(EC_POINT_get_affine_coordinates_GF2m(ca, q, x, y, kp-params-ctx));
if (bn2bin_padhi(x, secret, mlen) != mlen)
goto fail;
FAILZ(EC_POINT_get_affine_coordinates_GF2m(ca, r, x, y, kp-params-ctx));
if (bn2bin_padhi(x, secret + mlen, mlen) != mlen)
goto fail;
rv = 0;
done:
if (unpadded) {
memset(unpadded, 0, mlen + 1);
free(unpadded);
}
if (q) EC_POINT_clear_free(q);
if (r) EC_POINT_clear_free(r);
BN_clear(x);
BN_clear(y);
return rv;
fail:
rv = -1;
memset(secret, 0, mlen * 2);
goto done;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
1.0.1-final release time frame
Is there a time frame for the final release of openssl 1.0.1 yet? I need the GCM support, and I'd hate to have to ask people to install a snapshot in order to build my program. Thanks, zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
