kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
d4a5ecd869
boringssl/crypto/bn/internal.h

306 lines
12 KiB
C
Raw Normal View History

Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
/* Copyright (C) 1995-1997 Eric Young (eay@cryptsoft.com)
* All rights reserved.
*
* This package is an SSL implementation written
* by Eric Young (eay@cryptsoft.com).
* The implementation was written so as to conform with Netscapes SSL.
*
* This library is free for commercial and non-commercial use as long as
* the following conditions are aheared to. The following conditions
* apply to all code found in this distribution, be it the RC4, RSA,
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
* included with this distribution is covered by the same copyright terms
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
*
* Copyright remains Eric Young's, and as such any Copyright notices in
* the code are not to be removed.
* If this package is used in a product, Eric Young should be given attribution
* as the author of the parts of the library used.
* This can be in the form of a textual message at program startup or
* in documentation (online or textual) provided with the package.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the copyright
* 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 the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* "This product includes cryptographic software written by
* Eric Young (eay@cryptsoft.com)"
* The word 'cryptographic' can be left out if the rouines from the library
* being used are not cryptographic related :-).
* 4. If you include any Windows specific code (or a derivative thereof) from
* the apps directory (application code) you must include an acknowledgement:
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
*
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.]
*/
/* ====================================================================
* Copyright (c) 1998-2006 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* 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
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* openssl-core@openssl.org.
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com).
*
*/
/* ====================================================================
* Copyright 2002 Sun Microsystems, Inc. ALL RIGHTS RESERVED.
*
* 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 Eric Young open source
* license provided above.
*
* The binary polynomial arithmetic software is originally written by
* Sheueling Chang Shantz and Douglas Stebila of Sun Microsystems
* Laboratories. */
#ifndef OPENSSL_HEADER_BN_INTERNAL_H
#define OPENSSL_HEADER_BN_INTERNAL_H
#include <openssl/base.h>
Define __STDC_FORMAT_MACROS before inttypes.h. It seems Android's inttypes.h refuses to define those macros on C++ unless __STDC_FORMAT_MACROS is set. This unbreaks the roll on Android. Change-Id: Iad6c971b4789f0302534d9e5022534c6124e0ff0 Reviewed-on: https://boringssl-review.googlesource.com/4202 Reviewed-by: Adam Langley <agl@google.com>
2015-04-02 19:09:03 +01:00
/* Some versions of inttypes.h will not define print macros in C++ unless
* __STDC_FORMAT_MACROS is set. */
#if !defined(__STDC_FORMAT_MACROS)
#define __STDC_FORMAT_MACROS
#endif
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
2014-06-24 19:15:12 +01:00
#include <inttypes.h>
Switch crypto/bn back to _umul128 on Windows clang. Upstream (impressively quickly) fixed the missing intrinsic. Switch Windows clang back to building the same code as MSVC. Also include the intrin.h header rather than forward-declare the intrinsic. clang only works if the header is explicitly included. Chromium forcibly includes it to work around these kinds of issues, but we shouldn't rely on it. BUG=crbug.com/438382 Change-Id: I0ff6d48e1a3aa455cff99f8dc4c407e88b84d446 Reviewed-on: https://boringssl-review.googlesource.com/2461 Reviewed-by: Adam Langley <agl@google.com>
2014-12-03 22:57:04 +00:00
#if defined(OPENSSL_X86_64) && defined(_MSC_VER) && _MSC_VER >= 1400
Fix standalone build on Win64. Win64 fires significantly more warnings than Win32. Also some recent changes made it grumpy. (We might want to reconsider enabling all of MSVC's warnings. Given the sorts of warnings some of these are, I'm not sure MSVC's version of -Wall -Werror is actually tenable. Plus, diverging from the Chromium build, especially before the bots are ready, is going to break pretty readily.) Change-Id: If3b8feccf910ceab4a233b0731e7624d7da46f87 Reviewed-on: https://boringssl-review.googlesource.com/3420 Reviewed-by: Adam Langley <agl@google.com>
2015-02-11 20:12:05 +00:00
#pragma warning(push, 3)
Switch crypto/bn back to _umul128 on Windows clang. Upstream (impressively quickly) fixed the missing intrinsic. Switch Windows clang back to building the same code as MSVC. Also include the intrin.h header rather than forward-declare the intrinsic. clang only works if the header is explicitly included. Chromium forcibly includes it to work around these kinds of issues, but we shouldn't rely on it. BUG=crbug.com/438382 Change-Id: I0ff6d48e1a3aa455cff99f8dc4c407e88b84d446 Reviewed-on: https://boringssl-review.googlesource.com/2461 Reviewed-by: Adam Langley <agl@google.com>
2014-12-03 22:57:04 +00:00
#include <intrin.h>
Fix standalone build on Win64. Win64 fires significantly more warnings than Win32. Also some recent changes made it grumpy. (We might want to reconsider enabling all of MSVC's warnings. Given the sorts of warnings some of these are, I'm not sure MSVC's version of -Wall -Werror is actually tenable. Plus, diverging from the Chromium build, especially before the bots are ready, is going to break pretty readily.) Change-Id: If3b8feccf910ceab4a233b0731e7624d7da46f87 Reviewed-on: https://boringssl-review.googlesource.com/3420 Reviewed-by: Adam Langley <agl@google.com>
2015-02-11 20:12:05 +00:00
#pragma warning(pop)
Switch crypto/bn back to _umul128 on Windows clang. Upstream (impressively quickly) fixed the missing intrinsic. Switch Windows clang back to building the same code as MSVC. Also include the intrin.h header rather than forward-declare the intrinsic. clang only works if the header is explicitly included. Chromium forcibly includes it to work around these kinds of issues, but we shouldn't rely on it. BUG=crbug.com/438382 Change-Id: I0ff6d48e1a3aa455cff99f8dc4c407e88b84d446 Reviewed-on: https://boringssl-review.googlesource.com/2461 Reviewed-by: Adam Langley <agl@google.com>
2014-12-03 22:57:04 +00:00
#pragma intrinsic(__umulh, _umul128)
#endif
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#if defined(__cplusplus)
extern "C" {
#endif
/* bn_expand acts the same as |BN_wexpand|, but takes a number of bits rather
* than a number of words. */
BIGNUM *bn_expand(BIGNUM *bn, unsigned bits);
#if defined(OPENSSL_64_BIT)
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#if !defined(_MSC_VER)
/* MSVC doesn't support two-word integers on 64-bit. */
#define BN_LLONG __int128_t
#define BN_ULLONG __uint128_t
#endif
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_BITS 128
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#define BN_BITS2 64
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_BYTES 8
#define BN_BITS4 32
#define BN_MASK (0xffffffffffffffffffffffffffffffffLL)
#define BN_MASK2 (0xffffffffffffffffL)
#define BN_MASK2l (0xffffffffL)
#define BN_MASK2h (0xffffffff00000000L)
#define BN_MASK2h1 (0xffffffff80000000L)
#define BN_TBIT (0x8000000000000000L)
#define BN_DEC_CONV (10000000000000000000UL)
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
2014-06-24 19:15:12 +01:00
#define BN_DEC_FMT1 "%" PRIu64
#define BN_DEC_FMT2 "%019" PRIu64
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_DEC_NUM 19
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
2014-06-24 19:15:12 +01:00
#define BN_HEX_FMT1 "%" PRIx64
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#elif defined(OPENSSL_32_BIT)
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#define BN_LLONG int64_t
#define BN_ULLONG uint64_t
#define BN_MASK (0xffffffffffffffffLL)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_BITS 64
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#define BN_BITS2 32
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_BYTES 4
#define BN_BITS4 16
#define BN_MASK2 (0xffffffffL)
#define BN_MASK2l (0xffff)
#define BN_MASK2h1 (0xffff8000L)
#define BN_MASK2h (0xffff0000L)
#define BN_TBIT (0x80000000L)
#define BN_DEC_CONV (1000000000L)
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
2014-06-24 19:15:12 +01:00
#define BN_DEC_FMT1 "%" PRIu32
#define BN_DEC_FMT2 "%09" PRIu32
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define BN_DEC_NUM 9
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
2014-06-24 19:15:12 +01:00
#define BN_HEX_FMT1 "%" PRIx32
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#else
#error "Must define either OPENSSL_32_BIT or OPENSSL_64_BIT"
#endif
/* Pentium pro 16,16,16,32,64 */
/* Alpha 16,16,16,16.64 */
#define BN_MULL_SIZE_NORMAL (16) /* 32 */
#define BN_MUL_RECURSIVE_SIZE_NORMAL (16) /* 32 less than */
#define BN_SQR_RECURSIVE_SIZE_NORMAL (16) /* 32 */
#define BN_MUL_LOW_RECURSIVE_SIZE_NORMAL (32) /* 32 */
#define BN_MONT_CTX_SET_SIZE_WORD (64) /* 32 */
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#if defined(BN_LLONG)
#define Lw(t) (((BN_ULONG)(t))&BN_MASK2)
#define Hw(t) (((BN_ULONG)((t)>>BN_BITS2))&BN_MASK2)
#endif
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
BN_ULONG bn_mul_add_words(BN_ULONG *rp, const BN_ULONG *ap, int num, BN_ULONG w);
BN_ULONG bn_mul_words(BN_ULONG *rp, const BN_ULONG *ap, int num, BN_ULONG w);
void bn_sqr_words(BN_ULONG *rp, const BN_ULONG *ap, int num);
BN_ULONG bn_div_words(BN_ULONG h, BN_ULONG l, BN_ULONG d);
BN_ULONG bn_add_words(BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int num);
BN_ULONG bn_sub_words(BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int num);
void bn_mul_comba4(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b);
void bn_mul_comba8(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b);
void bn_sqr_comba8(BN_ULONG *r, const BN_ULONG *a);
void bn_sqr_comba4(BN_ULONG *r, const BN_ULONG *a);
/* bn_cmp_words returns a value less than, equal to or greater than zero if
* the, length |n|, array |a| is less than, equal to or greater than |b|. */
int bn_cmp_words(const BN_ULONG *a, const BN_ULONG *b, int n);
/* bn_cmp_words returns a value less than, equal to or greater than zero if the
* array |a| is less than, equal to or greater than |b|. The arrays can be of
* different lengths: |cl| gives the minimum of the two lengths and |dl| gives
* the length of |a| minus the length of |b|. */
int bn_cmp_part_words(const BN_ULONG *a, const BN_ULONG *b, int cl, int dl);
int bn_mul_mont(BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,
const BN_ULONG *np, const BN_ULONG *n0, int num);
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#if !defined(BN_LLONG)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define LBITS(a) ((a) & BN_MASK2l)
#define HBITS(a) (((a) >> BN_BITS4) & BN_MASK2l)
#define L2HBITS(a) (((a) << BN_BITS4) & BN_MASK2)
#define LLBITS(a) ((a) & BN_MASKl)
#define LHBITS(a) (((a) >> BN_BITS2) & BN_MASKl)
#define LL2HBITS(a) ((BN_ULLONG)((a) & BN_MASKl) << BN_BITS2)
#define mul64(l, h, bl, bh) \
{ \
BN_ULONG m, m1, lt, ht; \
\
lt = l; \
ht = h; \
m = (bh) * (lt); \
lt = (bl) * (lt); \
m1 = (bl) * (ht); \
ht = (bh) * (ht); \
m = (m + m1) & BN_MASK2; \
if (m < m1) \
ht += L2HBITS((BN_ULONG)1); \
ht += HBITS(m); \
m1 = L2HBITS(m); \
lt = (lt + m1) & BN_MASK2; \
if (lt < m1) \
ht++; \
(l) = lt; \
(h) = ht; \
}
aarch64 support. This is an initial cut at aarch64 support. I have only qemu to test it however—hopefully hardware will be coming soon. This also affects 32-bit ARM in that aarch64 chips can run 32-bit code and we would like to be able to take advantage of the crypto operations even in 32-bit mode. AES and GHASH should Just Work in this case: the -armx.pl files can be built for either 32- or 64-bit mode based on the flavour argument given to the Perl script. SHA-1 and SHA-256 don't work like this however because they've never support for multiple implementations, thus BoringSSL built for 32-bit won't use the SHA instructions on an aarch64 chip. No dedicated ChaCha20 or Poly1305 support yet. Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c Reviewed-on: https://boringssl-review.googlesource.com/2801 Reviewed-by: Adam Langley <agl@google.com>
2015-01-09 23:44:37 +00:00
#endif /* !defined(BN_LLONG) */
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#if !defined(OPENSSL_NO_ASM) && defined(OPENSSL_X86_64)
Switch crypto/bn back to _umul128 on Windows clang. Upstream (impressively quickly) fixed the missing intrinsic. Switch Windows clang back to building the same code as MSVC. Also include the intrin.h header rather than forward-declare the intrinsic. clang only works if the header is explicitly included. Chromium forcibly includes it to work around these kinds of issues, but we shouldn't rely on it. BUG=crbug.com/438382 Change-Id: I0ff6d48e1a3aa455cff99f8dc4c407e88b84d446 Reviewed-on: https://boringssl-review.googlesource.com/2461 Reviewed-by: Adam Langley <agl@google.com>
2014-12-03 22:57:04 +00:00
# if defined(__GNUC__) && __GNUC__ >= 2
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
# define BN_UMULT_HIGH(a,b) ({ \
register BN_ULONG ret,discard; \
__asm__ ("mulq %3" \
: "=a"(discard),"=d"(ret) \
: "a"(a), "g"(b) \
: "cc"); \
ret; })
# define BN_UMULT_LOHI(low,high,a,b) \
__asm__ ("mulq %3" \
: "=a"(low),"=d"(high) \
: "a"(a),"g"(b) \
: "cc");
Switch crypto/bn back to _umul128 on Windows clang. Upstream (impressively quickly) fixed the missing intrinsic. Switch Windows clang back to building the same code as MSVC. Also include the intrin.h header rather than forward-declare the intrinsic. clang only works if the header is explicitly included. Chromium forcibly includes it to work around these kinds of issues, but we shouldn't rely on it. BUG=crbug.com/438382 Change-Id: I0ff6d48e1a3aa455cff99f8dc4c407e88b84d446 Reviewed-on: https://boringssl-review.googlesource.com/2461 Reviewed-by: Adam Langley <agl@google.com>
2014-12-03 22:57:04 +00:00
# elif defined(_MSC_VER) && _MSC_VER >= 1400
# define BN_UMULT_HIGH(a, b) __umulh((a), (b))
# define BN_UMULT_LOHI(low, high, a, b) ((low) = _umul128((a), (b), &(high)))
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
# endif
#elif !defined(OPENSSL_NO_ASM) && defined(OPENSSL_AARCH64)
# if defined(__GNUC__) && __GNUC__>=2
# define BN_UMULT_HIGH(a,b) ({ \
register BN_ULONG ret; \
__asm__ ("umulh %0,%1,%2" \
: "=r"(ret) \
: "r"(a), "r"(b)); \
ret; })
# endif
#endif
#if defined(__cplusplus)
} /* extern C */
#endif
#endif /* OPENSSL_HEADER_BN_INTERNAL_H */
Reference in New Issue Copy Permalink