diff options
author | Matt Caswell <matt@openssl.org> | 2015-01-22 04:40:55 +0100 |
---|---|---|
committer | Matt Caswell <matt@openssl.org> | 2015-01-22 10:20:09 +0100 |
commit | 0f113f3ee4d629ef9a4a30911b22b224772085e5 (patch) | |
tree | e014603da5aed1d0751f587a66d6e270b6bda3de /crypto/ec/ec_cvt.c | |
parent | More tweaks for comments due indent issues (diff) | |
download | openssl-0f113f3ee4d629ef9a4a30911b22b224772085e5.tar.xz openssl-0f113f3ee4d629ef9a4a30911b22b224772085e5.zip |
Run util/openssl-format-source -v -c .
Reviewed-by: Tim Hudson <tjh@openssl.org>
Diffstat (limited to 'crypto/ec/ec_cvt.c')
-rw-r--r-- | crypto/ec/ec_cvt.c | 123 |
1 files changed, 60 insertions, 63 deletions
diff --git a/crypto/ec/ec_cvt.c b/crypto/ec/ec_cvt.c index 682425de38..0720615802 100644 --- a/crypto/ec/ec_cvt.c +++ b/crypto/ec/ec_cvt.c @@ -10,7 +10,7 @@ * are met: * * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. + * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in @@ -58,7 +58,7 @@ /* ==================================================================== * Copyright 2002 Sun Microsystems, Inc. ALL RIGHTS RESERVED. * - * Portions of the attached software ("Contribution") are developed by + * Portions of the attached software ("Contribution") are developed by * SUN MICROSYSTEMS, INC., and are contributed to the OpenSSL project. * * The Contribution is licensed pursuant to the OpenSSL open source @@ -69,78 +69,75 @@ * */ - - #include <openssl/err.h> #include "ec_lcl.h" - -EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx) - { - const EC_METHOD *meth; - EC_GROUP *ret; +EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, + const BIGNUM *b, BN_CTX *ctx) +{ + const EC_METHOD *meth; + EC_GROUP *ret; #if defined(OPENSSL_BN_ASM_MONT) - /* - * This might appear controversial, but the fact is that generic - * prime method was observed to deliver better performance even - * for NIST primes on a range of platforms, e.g.: 60%-15% - * improvement on IA-64, ~25% on ARM, 30%-90% on P4, 20%-25% - * in 32-bit build and 35%--12% in 64-bit build on Core2... - * Coefficients are relative to optimized bn_nist.c for most - * intensive ECDSA verify and ECDH operations for 192- and 521- - * bit keys respectively. Choice of these boundary values is - * arguable, because the dependency of improvement coefficient - * from key length is not a "monotone" curve. For example while - * 571-bit result is 23% on ARM, 384-bit one is -1%. But it's - * generally faster, sometimes "respectfully" faster, sometimes - * "tolerably" slower... What effectively happens is that loop - * with bn_mul_add_words is put against bn_mul_mont, and the - * latter "wins" on short vectors. Correct solution should be - * implementing dedicated NxN multiplication subroutines for - * small N. But till it materializes, let's stick to generic - * prime method... - * <appro> - */ - meth = EC_GFp_mont_method(); + /* + * This might appear controversial, but the fact is that generic + * prime method was observed to deliver better performance even + * for NIST primes on a range of platforms, e.g.: 60%-15% + * improvement on IA-64, ~25% on ARM, 30%-90% on P4, 20%-25% + * in 32-bit build and 35%--12% in 64-bit build on Core2... + * Coefficients are relative to optimized bn_nist.c for most + * intensive ECDSA verify and ECDH operations for 192- and 521- + * bit keys respectively. Choice of these boundary values is + * arguable, because the dependency of improvement coefficient + * from key length is not a "monotone" curve. For example while + * 571-bit result is 23% on ARM, 384-bit one is -1%. But it's + * generally faster, sometimes "respectfully" faster, sometimes + * "tolerably" slower... What effectively happens is that loop + * with bn_mul_add_words is put against bn_mul_mont, and the + * latter "wins" on short vectors. Correct solution should be + * implementing dedicated NxN multiplication subroutines for + * small N. But till it materializes, let's stick to generic + * prime method... + * <appro> + */ + meth = EC_GFp_mont_method(); #else - if (BN_nist_mod_func(p)) - meth = EC_GFp_nist_method(); - else - meth = EC_GFp_mont_method(); + if (BN_nist_mod_func(p)) + meth = EC_GFp_nist_method(); + else + meth = EC_GFp_mont_method(); #endif - - ret = EC_GROUP_new(meth); - if (ret == NULL) - return NULL; - if (!EC_GROUP_set_curve_GFp(ret, p, a, b, ctx)) - { - EC_GROUP_clear_free(ret); - return NULL; - } + ret = EC_GROUP_new(meth); + if (ret == NULL) + return NULL; - return ret; - } + if (!EC_GROUP_set_curve_GFp(ret, p, a, b, ctx)) { + EC_GROUP_clear_free(ret); + return NULL; + } + + return ret; +} #ifndef OPENSSL_NO_EC2M -EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx) - { - const EC_METHOD *meth; - EC_GROUP *ret; - - meth = EC_GF2m_simple_method(); - - ret = EC_GROUP_new(meth); - if (ret == NULL) - return NULL; +EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, + const BIGNUM *b, BN_CTX *ctx) +{ + const EC_METHOD *meth; + EC_GROUP *ret; + + meth = EC_GF2m_simple_method(); + + ret = EC_GROUP_new(meth); + if (ret == NULL) + return NULL; - if (!EC_GROUP_set_curve_GF2m(ret, p, a, b, ctx)) - { - EC_GROUP_clear_free(ret); - return NULL; - } + if (!EC_GROUP_set_curve_GF2m(ret, p, a, b, ctx)) { + EC_GROUP_clear_free(ret); + return NULL; + } - return ret; - } + return ret; +} #endif |