Fix error handling in bn_exp

[openssl.git] / crypto / bn / bn_exp.c

diff --git a/crypto/bn/bn_exp.c b/crypto/bn/bn_exp.c
index eebcb96b55ebb7261a510cbd469d7e125545b733..8c46e50bdcc9783d6bdd3ab056cae2547a62c92b 100644 (file)
--- a/crypto/bn/bn_exp.c
+++ b/crypto/bn/bn_exp.c
@@ -185,10 +185,10 @@ int BN_exp(BIGNUM *r, const BIGNUM *a, const BIGNUM *p, BN_CTX *ctx)
                 goto err;
         }
     }
-    ret = 1;
- err:
     if (r != rr)
         BN_copy(r, rr);
+    ret = 1;
+ err:
     BN_CTX_end(ctx);
     bn_check_top(r);
     return (ret);
@@ -203,36 +203,36 @@ int BN_mod_exp(BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m,
     bn_check_top(p);
     bn_check_top(m);
 
-        /*-
-         * For even modulus  m = 2^k*m_odd,  it might make sense to compute
-         * a^p mod m_odd  and  a^p mod 2^k  separately (with Montgomery
-         * exponentiation for the odd part), using appropriate exponent
-         * reductions, and combine the results using the CRT.
-         *
-         * For now, we use Montgomery only if the modulus is odd; otherwise,
-         * exponentiation using the reciprocal-based quick remaindering
-         * algorithm is used.
-         *
-         * (Timing obtained with expspeed.c [computations  a^p mod m
-         * where  a, p, m  are of the same length: 256, 512, 1024, 2048,
-         * 4096, 8192 bits], compared to the running time of the
-         * standard algorithm:
-         *
-         *   BN_mod_exp_mont   33 .. 40 %  [AMD K6-2, Linux, debug configuration]
-         *                     55 .. 77 %  [UltraSparc processor, but
-         *                                  debug-solaris-sparcv8-gcc conf.]
-         *
-         *   BN_mod_exp_recp   50 .. 70 %  [AMD K6-2, Linux, debug configuration]
-         *                     62 .. 118 % [UltraSparc, debug-solaris-sparcv8-gcc]
-         *
-         * On the Sparc, BN_mod_exp_recp was faster than BN_mod_exp_mont
-         * at 2048 and more bits, but at 512 and 1024 bits, it was
-         * slower even than the standard algorithm!
-         *
-         * "Real" timings [linux-elf, solaris-sparcv9-gcc configurations]
-         * should be obtained when the new Montgomery reduction code
-         * has been integrated into OpenSSL.)
-         */
+    /*-
+     * For even modulus  m = 2^k*m_odd,  it might make sense to compute
+     * a^p mod m_odd  and  a^p mod 2^k  separately (with Montgomery
+     * exponentiation for the odd part), using appropriate exponent
+     * reductions, and combine the results using the CRT.
+     *
+     * For now, we use Montgomery only if the modulus is odd; otherwise,
+     * exponentiation using the reciprocal-based quick remaindering
+     * algorithm is used.
+     *
+     * (Timing obtained with expspeed.c [computations  a^p mod m
+     * where  a, p, m  are of the same length: 256, 512, 1024, 2048,
+     * 4096, 8192 bits], compared to the running time of the
+     * standard algorithm:
+     *
+     *   BN_mod_exp_mont   33 .. 40 %  [AMD K6-2, Linux, debug configuration]
+     *                     55 .. 77 %  [UltraSparc processor, but
+     *                                  debug-solaris-sparcv8-gcc conf.]
+     *
+     *   BN_mod_exp_recp   50 .. 70 %  [AMD K6-2, Linux, debug configuration]
+     *                     62 .. 118 % [UltraSparc, debug-solaris-sparcv8-gcc]
+     *
+     * On the Sparc, BN_mod_exp_recp was faster than BN_mod_exp_mont
+     * at 2048 and more bits, but at 512 and 1024 bits, it was
+     * slower even than the standard algorithm!
+     *
+     * "Real" timings [linux-elf, solaris-sparcv9-gcc configurations]
+     * should be obtained when the new Montgomery reduction code
+     * has been integrated into OpenSSL.)
+     */
 
 #define MONT_MUL_MOD
 #define MONT_EXP_WORD