summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch/i386/Makefile.inc (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Replace Makefile based SHA*_ASM defines with HAVE_SHA_* defines.jsing2025-02-141-4/+1
| | | | | | | | | | | | | | | | Currently, SHA{1,256,512}_ASM defines are used to remove the C implementation of sha{1,256,512}_block_data_order() when it is provided by assembly. However, this prevents the C implementation from being used as a fallback. Rename the C sha*_block_data_order() to sha*_block_generic() and provide a sha*_block_data_order() that calls sha*_block_generic(). Replace the Makefile based SHA*_ASM defines with two HAVE_SHA_* defines that allow these functions to be compiled in or removed, such that machine specific verisons can be provided. This should effectively be a no-op on any platform that defined SHA{1,256,512}_ASM. ok tb@
* Provide crypto_cpu_caps_init() for i386.jsing2024-10-181-9/+3
| | | | | | | This is the same CPU capabilities code that is now used for amd64. Like amd64 we now only populate OPENSSL_ia32cap_P with bits used by perlasm. Discussed with tb@
* Provide and use crypto_arch.h.jsing2024-08-111-8/+1
| | | | | | | | Provide a per architecture crypto_arch.h - this will be used in a similar manner to bn_arch.h and will allow for architecture specific #defines and static inline functions. Move the HAVE_AES_* and HAVE_RC4_* defines here. ok tb@
* Always use C functions for AES_{encrypt,decrypt}().jsing2024-03-291-1/+3
| | | | | | | Always provide AES_{encrypt,decrypt}() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Move camellia to primary Makefile.jsing2024-03-291-5/+1
| | | | These files are now built on all platforms.
* Stop building camellia assembly on amd64 and i386.jsing2024-03-291-2/+4
| | | | | | | This is a legacy algorithm and the assembly is only marginally faster than the C code. Discussed with beck@ and tb@
* Move aes_core.c to the primary Makefile.jsing2024-03-291-2/+1
| | | | This is now built on all platforms.
* Always use C functions for AES_set_{encrypt,decrypt}_key().jsing2024-03-291-1/+4
| | | | | | | | Always include aes_core.c and provide AES_set_{encrypt,decrypt}_key() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Move wp_block.c to the primary Makefile.jsing2024-03-291-3/+1
| | | | This is now built on all platforms.
* Stop building whirlpool assembly on amd64 and i386.jsing2024-03-291-3/+1
| | | | | | | This is a legacy algorithm and the assembly is only marginally faster than the C code. Discussed with beck@ and tb@
* Merge aes_cbc.c into aes.c now that aes_cbc.c is used on all platforms.jsing2024-03-281-2/+1
|
* Make AES_cbc_encrypt() always be a C function.jsing2024-03-281-1/+3
| | | | | | | | Rename the assembly generated functions from AES_cbc_encrypt() to aes_cbc_encrypt_internal(). Always include aes_cbc.c and change it to use defines that are similar to those used in BN. ok tb@
* Move rc4.c to primary Makefile.jsing2024-03-281-2/+1
| | | | This is now built on all platforms.
* Use C functions for RC4 public API.jsing2024-03-281-1/+4
| | | | | | | | | | | | | | Rather than having public API switch between C and assembly, always use C functions as entry points, which then call an assembly implementation (if available). This makes it significantly easier to deal with symbol aliasing/namespaces and it also means we benefit from vulnerability prevention provided by the C compiler. Rename the assembly generated functions from RC4() to rc4_internal() and RC4_set_key() to rc4_set_key_internal(). Always include rc4.c and change it to use defines that are similar to those used in BN. ok beck@ joshua@ tb@
* Move des sources to primary Makefile.jsing2024-03-281-3/+1
| | | | | Now that all platforms use a C des implementation, move it to the primary Makefile.
* Stop building the assembly implementation of des and ripemd on i386.jsing2024-03-281-6/+2
| | | | | | | | This is the only architecture that has an assembly implementation for these algorithms. There is little to gain from accelerating legacy algorithms on a legacy architecture. Discussed with beck@ and tb@
* Move bf_enc.c to the primary Makefile.jsing2024-03-271-3/+1
| | | | | Now that all architectures are using bf_enc.c, it does not make sense to have it in every Makefile.inc file.
* Stop building the assembly implementation of blowfish on i386.jsing2024-03-271-3/+2
| | | | | | | | This is the only architecture that has an assembly implementation. There is little to gain from accelerating a legacy algorithm on a legacy architecture. ok beck@ tb@
* Stop building GF2m assemblytb2023-04-151-3/+1
| | | | | | | GF2m support will be removed shortly. In the interim drop some of this unused code already and let it fall back to the C implementation. ok jsing
* Replace bn_sub_part_words() with bn_sub().jsing2023-02-221-2/+1
| | | | | | | | Now that bn_sub() handles word arrays with potentially different lengths, we no longer need bn_sub_part_words() - call bn_sub() instead. This allows us to entirely remove the unnecessarily complex bn_sub_part_words() code. ok tb@
* Remove unused Elliptic Curve code.jsing2023-01-141-5/+1
| | | | | | | | | | | | | For various reasons, the ecp_nistp* and ecp_nistz* code is unused. While ecp_nistp* was being compiled, it is disabled due to OPENSSL_NO_EC_NISTP_64_GCC_128 being defined. On the other hand, ecp_nistz* was not even being built. We will bring in new versions or alternative versions of such code, if we end up enabling it in the future. For now it is just causing complexity (and grep noise) while trying to improve the EC code. Discussed with tb@
* sprinkle a few missing dependencies on perl scripts internal bits.espie2017-08-201-3/+6
| | | | 'it works' deraadt@
* Ride the current major bump and enable assembler code for nist 256p curve,miod2016-11-041-1/+5
| | | | | | | | on amd64 only for now. Stanzas to enable it on arm, i386 and sparc64 are provided but commented out for lack of testing due to the machine room being currently in storage. ok jsing@
* Add the Cammelia cipher to libcrypto.miod2014-11-171-1/+3
| | | | | | | | | | | | | | | | | | There used to be a strong reluctance to provide this cipher in LibreSSL in the past, because the licence terms under which Cammelia was released by NTT were free-but-not-in-the-corners, by restricting the right to modify the source code, as well retaining the right to enforce their patents against anyone in the future. However, as stated in http://www.ntt.co.jp/news/news06e/0604/060413a.html , NTT changed its mind and made this code truly free. We only wish there had been more visibility of this, for we could have had enabled Cammelia earlier (-: Licence change noticed by deraadt@. General agreement from the usual LibreSSL suspects. Crank libcrypto.so minor version due to the added symbols.
* miod forgot about fcrypt_b.c being needed, before he went off to get hisderaadt2014-05-071-1/+2
| | | | | beauty sleep. He's probably having a nightmare about this right now.... ok tedu
* Sort CFLAGS, SRC and SSLASM stanzas by the directories they apply to, to makemiod2014-05-061-31/+36
| | | | | these files similar in layout to the other md Makefile.inc; no functional change.
* Move the machine-specific parts of the libcrypto Makefile to per-arch makefilemiod2014-04-171-0/+58
fragments, to ease maintainance, and see through the fog of bugs. "looks good" deraadt@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 03:44:03 +0000