summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/bn/bn_nist.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove the horror show that is bn_nist and ecp_nisttb2023-04-251-1332/+0
| | | | | | This code is full of problematic C and is also otherwise of questionable quality. It is far from constant time and jsing informs me it also isn't faster. Good riddance.
* Convert bn_nist.c to BN_copy()tb2023-03-271-6/+6
| | | | | | | Like everything else in this file, the use of BN_copy() needs to be ... special. Simplify using the new bn_copy(). ok jsing
* Mop up more BN_DEBUG related code.jsing2022-11-301-4/+1
|
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Tidy up some of BN_nist_mod_*jsing2022-07-311-22/+30
| | | | | | | Shuffle variables around for consistency, also ensuring appropriate and consistent initialisation. ok tb@
* Use named initialisers for BIGNUMs.jsing2022-07-301-61/+65
| | | | | | | Also move the _bignum_nist_p_.*_sqr static BIGNUMs out of individual functions. ok tb@
* Avoid strict aliasing violations in BN_nist_mod_*()jsing2022-05-071-86/+137
| | | | | | | | | | | | | | | | | | | | | | | The optimised code path switches from processing data via unsigned long to processing data via unsigned int, which requires type punning. This is currently attempted via a union (for one case), however this fails since a pointer to a union member is passed to another function (these unions were added to "fix strict-aliasing compiler warning" - it would seem the warnings stopped but the undefined behaviour remained). The second case does not use a union and simply casts from one type to another. Undefined behaviour is currently triggered when compiling with clang 14 using -03 and -fstrict-aliasing, while disabling assembly (in order to use this C code). The resulting binary produces incorrect results. Avoid strict aliasing violations by copying from an unsigned long array to an unsigned int array, then copying back the result. Any sensible compiler will omit the copies, while avoiding undefined behaviour that would result from unsafe type punning via pointer type casting. Thanks to Guido Vranken for reporting the issue and testing the fix. ok tb@
* Switch to <endian.h> from <machine/endian.h> for better portability.bcook2021-11-091-3/+2
| | | | ok tb@
* don't mix code and decls, ok tedu@bcook2016-07-181-2/+3
|
* use memset to initialize the unionbcook2016-07-171-2/+4
|
* Initialize buffers before use, noted by Kinichiro Inoguchi.bcook2016-07-171-7/+7
| | | | ok beck@
* deregister; no binary changejsg2014-10-281-6/+6
| | | | ok jsing@ miod@
* Only import cryptlib.h in the four source files that actually need it.jsing2014-07-111-4/+3
| | | | | | | | Remove the openssl public includes from cryptlib.h and add a small number of includes into the source files that actually need them. While here, also sort/group/tidy the includes. ok beck@ miod@
* Stop including standard headers via cryptlib.h - pull in the headers thatjsing2014-07-101-2/+3
| | | | | | are needed in the source files that actually require them. ok beck@ miod@
* Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to bemiod2014-07-091-2/+2
| | | | | more friendly to systems where the underscore flavours may be defined as empty. Found the hard way be bcook@; joint brainstrom with bcook beck and guenther
* tags as requested by miod and teduderaadt2014-06-121-1/+1
|
* knfectomie.jsing2014-05-081-653/+818
|
* Try to clean the maze of <openssl/bn.h> defines regarding the BN internals.miod2014-04-241-5/+3
| | | | | | | | | | | | | | | | | | | | | | | The intent of this change is to only keep support for two kind of architectures: - those with 32-bit int and long, and 64-bit long long, where ``long * long -> long long'' multiplication routines are available. - those with 64-bit int and long, and no 128-bit long long type. This gets rid of the SIXTY_FOUR_BIT_LONG, SIXTY_FOUR_BIT (not the same!), THIRTY_TWO_BIT, SIXTEEN_BIT and EIGHT_BIT defines. After this change, the types and defines are as follows: arch: 64bit 32bit rationale BN_LLONG undefined defined defined if l * l -> ll BN_ULLONG undefined u long long result of BN_LONG * BN_LONG BN_ULONG u long u int native register size BN_LONG long int the same, signed BN_BITS 128 64 size of 2*BN_ULONG in bits BN_BYTES 8 4 size of 2*BN_ULONG in bytes BN_BITS2 64 32 BN_BITS / 2 Tested on various 32-bit and 64-bit OpenBSD systems of various endianness.
* Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,miod2014-04-181-1/+3
| | | | | | | but rather figure out the endianness from <machine/endian.h> automagically; help from guenther@ ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'
* replace PTR_SIZE_INT (only used for VMS) with uintptr_t, tweaks from jca@,sthen2014-04-141-35/+31
| | | | makes sense to beck@
* Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.miod2014-04-131-24/+31
|
* resolve conflictsdjm2012-10-131-40/+298
|
* openssl-1.0.0e: resolve conflictsdjm2011-11-031-28/+36
|
* resolve conflictsdjm2009-01-091-323/+383
|
* update to openssl-0.9.8i; tested by several, especially krw@djm2009-01-051-50/+134
|
* import of OpenSSL 0.9.8hdjm2008-09-061-0/+692
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-07 23:15:28 +0000