Your technical arguments are sound, indeed.
From: Andy Polyakov via RT
Sent: Friday, June 17, 2016 5:13:50 PM
To: Loic Etienne
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request:
Configuration option no-hw-aes
> 1) Ope
1) Openssl works correctly (no crash, correct detection), as far as I can
judge. By error-prone I mean, very defensively, that I (or others) could make a
mistake, or that future versions of openssl could not work exactly the same way.
2) I would agree with your argumentation. But some customers
Thanks for the explanations.
In the code I am working with, I see:
$ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c
unsigned long *OPENSSL_ia32cap_loc(void)
You may want to verify it.
I happen to be using features introduced for testing and debugging, without
knowing it. For debatable reasons,
Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is hidden, I
still have to try over environment variables, which are not as flexible for arm
as for x86).
Anyway, it would be helpful to exclude hardware aes instructions at
compile-time:
1) Runtime checking is error prone (op
Two more observations.
OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not
fitting into the expected integer size being zeroed. I do not know if it is
practically relevant, but it is strange that a read has side effects. It would
be a good reason for dedicated, architect
Identifying the bits relevant to openssl for each architecture and making them
available through architecture-independent functions (getter and setters) would
be very convenient, indeed. At the risk that future architectures do not fit
into the pattern defined today.
If this approach is implem
Define a configuration option no-hw-aes.
No aes processor instruction should be compiled if one of the configuration
options no-hw or no-hw-aes is given.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted
--
openssl-dev mai
For x86, define macros for capability bits (like for arm and pcc), according to
https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html:
#define X86_TSCNT (1UL << 4 )
#define X86_CLFLUSH(1UL << 19)
#define X86_RC4PATH(1UL << 20)
#define X86_MMX(1UL << 23)
#define X8
For arm and ppc, define functions corresponding to unsigned long
*OPENSSL_ia32cap(), returning a pointer to the capability vector, or NULL on an
unsuitable architecture:
unsigned int *OPENSSL_armcap_loc();
unsigned int *OPENSSL_ppccap_loc();
Otherwise, an extern declaration of OPENSSL_armcap_P (
My claim about portability issues was wrong (sorry): The C-standard ensures
that positive values are handled in the two's complement system, indeed.
However, inl % block_size == inl & (block_size-1) is true if and only if
block_size is a power of two, which happens to be true under the current
crypto/evp/evp_enc.c, EVP_EncryptUpdate
line 337: inl & (ctx->block_mask)
line 367: inl & (bl - 1) /* with bl = ctx->cipher->block_size */
Instead, the more portable inl % ctx->cipher->block_size should be used;
or, alternatively, unsigned integers should be used.
--
Ticket here: http://rt.open
crypto/evp/evp_enc.c, EVP_CipherInit_ex, line 172
const EVP_CIPHER *fcipher;
if (cipher)
fcipher = evp_get_fips_cipher(cipher);
if (fcipher)
cipher = fcipher;
return FIPS_cipherinit(ctx, cipher, key, iv, enc);
problem:
if (!cipher), fcipher is not initialized bu
12 matches
Mail list logo
