| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
No change to generated assembly.
|
|
|
|
| |
No change in generated assembly.
|
|
|
|
| |
ok jsing tb beck
|
|
|
|
| |
No functional change.
|
| |
|
|
|
|
| |
No change in generated assembly.
|
| |
|
| |
|
|
|
|
| |
No change in generated assembly.
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace macros with static inline functions and use names that follow
the spec more closely. Unlike SHA256/SHA512, the functions and constants do
not align with the number of words loaded, which means we cannot easily loop
and just end up just unrolling everything.
ok joshua@ tb@
|
| |
|
|
|
|
|
| |
No assembly implementations remain, hence we can clean the mess up and
replace it with a single static void function.
|
|
|
|
| |
ok tb@
|
| |
|
|
|
|
| |
No change to generated assembly.
|
|
|
|
| |
No functional change.
|
|
|
|
| |
No change to generated assembly.
|
| |
|
| |
|
|
|
|
| |
This is now built on all platforms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
| |
The function call can't actually fail, but all other calls check its
return value.
ok joshua jsing
|
|
|
|
|
| |
Now that all platforms use a C des implementation, move it to the primary
Makefile.
|
| |
|
|
|
|
|
|
| |
This one was hiding behind an m4 script.
Build tested by tb@
|
| |
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
Discussed with tb@
|
| |
|
|
|
|
| |
This is already disabled since it is "about 35% slower than C code".
|
| |
|
|
|
|
| |
Discussed with tb@
|
|
|
|
|
| |
The stitched modes have been removed, so having assembly for them is of
little use.
|
|
|
|
| |
Discussed with tb@
|
|
|
|
| |
This does not exist in libcrypto.
|
|
|
|
|
|
| |
This removes the unused Intel special version of BF_ENC().
ok tb@
|
| |
|
|
|
|
| |
Requested by tb@
|
|
|
|
|
|
|
|
| |
Replace GETU32 with crypto_load_be32toh() and PUTU32 with
crypto_store_htobe32(). Make the offset handling cleaner at the
same time.
ok beck@ joshua@ tb@
|
| |
|
|
|
|
|
| |
Now that all architectures are using bf_enc.c, it does not make sense to
have it in every Makefile.inc file.
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently three ways in which AES is implemented - all in
assembly (amd64 et al), all in C (aarch64 et al) and, half in C and
half in assembly (hppa and sparc64). The last of these cases currently
makes use of a near duplicate AES_set_{encrypt,decrypt}_key()
implementation that avoids using the AES tables.
Remove the near duplicate version and if only a half assembly version is
implemented, use the same C version of AES_set_{encrypt,decrypt}_key() as
everyone else. This adds around 8KB of rodata to libcrypto on these two
platforms.
Discussed with beck and tb.
|
|
|
|
| |
with jsing
|
| |
|
|
|
|
| |
ok tb@
|
| |
|