X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS
man X509_check_host says: If set, X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS restricts name values which start with ".", that would otherwise match any sub-domain in the peer certificate, to only match direct child sub-domains. Thus, for instance, with this flag set a name of ".example.com" would match a peer certificate with a DNS name of "www.example.com", but would not match a peer certificate with a DNS name of "www.sub.example.com"; this flag only applies to X509_check_host. I haven't see the idea of ".example.com" being special in any of the RFCs I've been looking at. Can somebody give me a lesson in this area? Is there any way to turn it off totally while still allowing * type wildcards? -- These are my opinions. I hate spam.
Re: How does a client get the server's SAN/DNS strings
openssl-us...@dukhovni.org said: > Can you explain *why* you want the list of DNS names? > Is this just for logging.. Yes, just for logging. -- These are my opinions. I hate spam.
How does a client get the server's SAN/DNS strings
I can get the subject and issuer with X509_get_subject_name and X509_get_issuer_name I'm looking for something similar to get the SAN/DNS strings used to verify that this certificate is valid for the hostname provided via SSL_set1_host Any API will be slightly complicated since there may be more than one SAN/DNS string. -- These are my opinions. I hate spam.
Re: Confusion Configuring
> It is very likely that your binary is actually loading the system's shared > libraries instead of the ones you just compiled. You can verify whether this > using the `ldd` command, That was it. Thanks. > There is a shared library wrapper called `shlib_wrap.sh` which can be used to > run the compiled application correctly without installing it: > util/shlib_wrap.sh apps/openssl version -d That works too. Thanks again. - > I just reread your initial post and noticed that my explanation is somewhat > inconsistent with your observations, since in your case the system openssl > prints the expected path. No, you got it right. Fedora is shipping 1.1.1l so openssl version -d gets the system code and system libraries. I have 3.0.1 installed in /usr/local/ssl The build stuff for the code I'm testing knows to look there. My attempt to check things by running ./apps/openssl version -d was picking up the old 3.0.1 libraries which were built with an old buggy --openssldir= My code is happy now that I have installed the new libraries built with the correct --openssldir= -- These are my opinions. I hate spam.
Confusion Configuring
I've been happily testing/using alpha, beta, 3.0.0 and 3.0.1, but I've run
into
an interesting quirk.
My problem is that it's not finding/using the default certificates that I'd
like it to use.
I'm running on Fedora. The installed version says:
$openssl version
OpenSSL 1.1.1l FIPS 24 Aug 2021
$openssl version -d
OPENSSLDIR: "/etc/pki/tls
$
So I plug that into Configure and build with:
make clean
./Configure --prefix=/usr/local/ssl --openssldir=/etc/pki/tls shared
make -j4
All seems OK. make test is happy.
But when I run
./apps/openssl version -d
it says:
OPENSSLDIR: "/usr/local/ssl"
I was expecting /etc/pki/tls from the Configure line above.
What am I missing? How do I tell it where to find the default certificates?
grep etc/pki/tls Makefile finds:
OPTIONS=--prefix=/usr/local/ssl --openssldir=/etc/pki/tls/ enable-shared (and
a lot more)
CONFIGURE_ARGS=("--prefix=/usr/local/ssl", "--openssldir=/etc/pki/tls/",
"shared")
OPENSSLDIR=/etc/pki/tls/
--
These are my opinions. I hate spam.
Re: Re: Compile opensslß1.1.1k on CentOS8
janj...@nikhef.nl said: > As you found out, it is nearly impossible to swap out the existing openssl > 1.1.1g with a "stock" openssl version, as RedHat/CentOS have applied patches > to it. My advice would be: don't even try. If you *have to* use openssl > 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS releases). But keep > in mind: - debian 10 uses openssl 1.1.1d - ubuntu seems to be at openssl > 1.1.1j etc. There are two cases. One is where you want to replace the system libraries so that all the installed programs that use libssl will now use your new version. I agree doing that is crazy. That's what distros are for. But if you are working on a program and you want that one program to use a new version, that's not so hard. The trick is to install your new version of openssl in /usr/local/ (or wherever). Then you have to patch the build recipe for your program to look there. This is how you would get your program ready for 3.0.0 or get a program that needs TLS1.3 to work on a distro that is stuck in the dark ages. I use: ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared to build and install OpenSSL, then, for waf: ctx.env.INCLUDES = ["/usr/local/ssl/include"] ctx.env.LIBPATH = ["/usr/local/ssl/lib"] I don't remember where I found that config line. -- These are my opinions. I hate spam.
Re: EVP_MAC_init() in 3.0 alpha 13
to...@openssl.org said: > We would have to introduce the special semantics similar to EVP_CipherInit() > with EVP_MAC_init(). I.e., that the EVP_CipherInit() with NULL key keeps the > key schedule from the previous initialization. Seems like a good idea to me. The current code doesn't crash and doesn't generate an error return. Is there any other useful thing that a NULL key could do? I don't have a big picture view. Is there any reason that all of the crypto init type procedures can't keep the current key schedule if called with a NULL key? Am I the only one (so far) that is interested in reusing the current key schedule to save CPU cycles? -- These are my opinions. I hate spam.
Re: EVP_MAC_init() in 3.0 alpha 13
> Did you attempt to pass NULL for the key and zero for it's length to the > EVP_MAC_init() call? Yes. We can do better. If we have to use dup/free, we can move the EVP_MAC_init() to before the dup, out of the timing path. My model is that initialization is 2 parts. The first is turning the key into a big table. The second is initializing a small amount of state that is whatever is needed/updated by EVP_MAC_update(). I was hoping that EVP_MAC_init() with NULL key would bypass the first step and do the second. If the second step involves a lot of computation we get into the space/time tradeoff of computing it during step one and saving it in case EVP_MAC_init is called with NULL key. If there was a copy operation we could use it instead of dup/free. Where is the code that does the key setup? I expect it will be obvious after I see it, but I don't know my way around that linkage yet. I'm using the default AES-128-CBC. - I don't think I've said it explicitly, but thanks for the change to the API for EVP_MAC_init() -- Should PKEY be a potentially interesting approach for something like this? I think it was suggested months ago. One advantage is that the code works with 1.1.1. It's horribly slow in 3.0 alpha14: 0.777 CMAC 7.533 PKEY 3.323 PKEY preload 0.392 EVP_MAC 0.308 EVP_MAC Preload with dup+free 0.102 EVP_MAC Preload (no dup, wrong answer) 1.1.1k: 0.285 CMAC 0.550 PKEY 0.196 PKEY preload -- These are my opinions. I hate spam.
Re: EVP_MAC_init() in 3.0 alpha 13
pa...@openssl.org said: > Does EVP_MAC_CTX_dup() after the MAC context has been initialised > do what you want? Thanks. Adding a dup/free gets the right answer, but isn't much of a speedup. Is there a way to copy the critical bits into a working ctx? I looked in the header file but didn't see anything suspicious. i5-3570 CPU @ 3.40GHz AES-128-CBC, 48 byte packets Times in microseconds. 1.1.1k: 0.339 CMAC 0.676 PKEY 0.236 PKEY preload alpha12: 0.933 CMAC 1.091 EVP_MAC 0.185 EVP_MAC Preload alpha13: 0.905 CMAC 0.463 EVP_MAC 0.359 EVP_MAC Preload with dup/free 0.123 EVP_MAC Preload without dup/free, WRONG ANSWER -- These are my opinions. I hate spam.
EVP_MAC_init() in 3.0 alpha 13
It used to take just a ctx. Now it also wants a key+length and a params. I have some simple/hack code to time 2 cases. The first gives it the key each time. The second preloads the key. That would require an evp per key, but I might we willing to make that space/time tradeoff. The each time mode of my old code put the cipher and key into a params array, then called EVP_MAC_CTX_set_params(ctx, params) and then EVP_MAC_init(ctx) That's easy to change. I just drop putting the key into a params slot and drop calling set_parms and add the key and parms to EVP_MAC_init. That worked. Is there a way to use a preloaded key? I tried using NULL for key and params when calling EVP_MAC_init. It compiles and runs but doesn't get the right answer. Is that, or something like it supposed to work? EVP_MAC_CTX_set_params() seems ugly to me. My inner loop looks like: EVP_MAC_CTX_set_params() EVP_MAC_init() EVP_MAC_update() EVP_MAC_final() I'm trying to make things go fast. It's going to have to do string compares to figure out what I want to do. I'm working with small blocks of data (48 bytes) so the setup cost is important. Or I think it is, so I'm trying to measure it. The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out of the loop. -- These are my opinions. I hate spam.
How can I tell if a name for a cipher/digest is implemented?
I think that checking for NULL from EVP_get_ciphername() works in 1.1.1 but that changed for 3.0.0 Is there anything better/cleaner than actually calling EVP_CipherInit() or such? I'm curious. What does it mean to have a non-NULL cipher that doesn't work? I'm using default Engines and Providers. Is that something like we have allocated a slot in the name space but this engine doesn't support it? Should there be something like EVP_get_ciphername that takes the engine parameter? -- These are my opinions. I hate spam.
Re: PKEY CMAC timings
In the context of making things go fast/clean, do I need a reset? If so, why? My straw man is that setup has 3 stages: 1: get storage and whatever for the cipher 2: setup tables and such for a key 3: init internal data In the same key case, the basic operation is Init (does step 3) Update Final I think setup steps 1 and 2 can be done with something like Setup(ctx, cipher, key+length) A NULL cipher means keep using the current one - no allocs. With something like that, I'd be happy to have a ctx per cipher. Setup and Init can be merged into one function if a NULL key means keep using the old one. I think it's slightly cleaner (and faster) to leave them split. -- These are my opinions. I hate spam.
Re: PKEY CMAC timings
> How does it look for large input? As in many kilobytes or megabytes? 16K is all I was willing to wait for. Timing for really long blocks turns into a memory test. The right unit is ns/byte. If that's an interesting case, I'll hack some code to do longer blocks. 1.1.1g AES-128 16 48 16225 0.225 475ac1c053379e7dbd4ce80b87d2178e AES-128 16 1024 16 1682 1.682 159d6d5c13f35d37c72efc5f6dbf40ad AES-128 16 16384 16 24566 24.566 581f7b133ad6f3697f33c3f836fdb6e6 3.0.0 alpha3 AES-128 16 48 16496 0.496 475ac1c053379e7dbd4ce80b87d2178e AES-128 16 1024 16 1953 1.953 159d6d5c13f35d37c72efc5f6dbf40ad AES-128 16 16384 16 24820 24.820 581f7b133ad6f3697f33c3f836fdb6e6 --- 3.0.0 alpha3: CMAC AES-128 16 16384 16 25270 25.270 581f7b133ad6f3697f33c3f836fdb6e6 PKEY AES-128 16 16384 16 24839 24.839 581f7b133ad6f3697f33c3f836fdb6e6 EVP_MAC AES-128 16 16384 16 25462 25.462 581f7b133ad6f3697f33c3f836fdb6e6 EVP_MAC with Preload cipher and key AES-128 16 16384 16 24567 24.567 581f7b133ad6f3697f33c3f836fdb6e6 -- These are my opinions. I hate spam.
PKEY CMAC timings
Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz After Kurt's improvement, with our usage patterns (48 bytes), PKEY mode on 3.0.0 takes 2x as many cycles as 1.1.1 That factor probably depends on how good the hardware AES support is in your CPU. I think it's significantly faster in newer CPU chips. 1.1.1g: AES-128 16 48 16434 0.434 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16442 0.442 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16453 0.453 991f4017858de97515260dd9ae440b06 1.1.1g improved: AES-128 16 48 16230 0.230 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16252 0.252 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16252 0.252 991f4017858de97515260dd9ae440b06 3.0.0 alpha3: AES-128 16 48 16815 0.815 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16831 0.831 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16846 0.846 991f4017858de97515260dd9ae440b06 3.0.0-alpha3 improved: AES-128 16 48 16500 0.500 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16515 0.515 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16530 0.530 991f4017858de97515260dd9ae440b06 Thanks again. -- These are my opinions. I hate spam.
Re: CMAC timings
Thanks. > The manpage documents: The call to EVP_DigestSignFinal() internally finalizes > a copy of the digest context. This means that calls to EVP_DigestSignUpdate() > and EVP_DigestSignFinal() can be called later to digest and sign additional > data. I saw that, but couldn't figure out what it meant. "additional" suggests that it would keep going and sign the current data plus new data. That didn't seem very relevant for my use case. "another" might be a better word. Is the idea that it makes the internal state so it is the same as after EVP_DigestSignInit()? If so, that would allow significant CPU savings in the request/response case where we sign twice with the same key. > - alloc/free. 12 alloc and 16 free calls per signature I'm curious. 12 seems like a huge number. I'd expect 1. What's going on? > And: >EVP_MD_CTX_FLAG_FINALISE >Some functions such as EVP_DigestSign only finalise >copies of internal contexts so additional data can be >included after the finalisation call. This is >inefficient if this functionality is not required, and >can be disabled with this flag. Now that you have explained it, I can try to read between the lines. That "only" seems misleading. "inefficient if this functionality is not required" doesn't make much sense (too me) in the context of finalize. The inefficiency is that you will have to repeat the setup if you want to do another run with the same key. -- These are my opinions. I hate spam.
Typos in man pages
There are 3 cases of "structure of NULL" where the "of" should be "or".
The "NULL" is actually "B" in the pod file.
doc/man3/EVP_PKEY_CTX_new.pod
doc/man3/X509_NAME_add_entry_by_txt.pod
doc/man3/X509V3_get_d2i.pod
--
There are several bugs/typos in the example code at the end of
doc/man3/EVP_MAC.pod
These lines have an extra NULL parameter.
OSSL_PARAM_construct_utf8_string("cipher", cipher, 0, NULL);
OSSL_PARAM_construct_utf8_string("digest", digest, 0, NULL);
OSSL_PARAM_construct_octet_string("key", key, strlen(key), NULL);
--
That man page describes EVP_MAC_set_ctx_params and uses it in the example:
|| EVP_MAC_set_ctx_params(ctx, params) <= 0)
evp.h has:
int EVP_MAC_CTX_set_params(EVP_MAC_CTX *ctx, const OSSL_PARAM params[]);
That's "set_ctx" vs "CTX_set" in case your eyes doesn't instantly lock on to
the difference.
There are similar problems with many other ctx routines.
EVP_MAC_new_ctx => EVP_MAC_CTX_new
EVP_MAC_free_ctx => EVP_MAC_CTX_free
EVP_MAC_get_ctx_params ...
--
These are my opinions. I hate spam.
Re: CMAC timings
Thanks. levi...@openssl.org said: > Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st, which > you find in crypto/evp/evp_local.h. It's quite small (smaller than > EVP_MD_CTX and EVP_PKEY_CTX): How much space does the crypto stuff take? The idea is to do all of the setup calculations ahead of time. I expect there are some tables in there. > Regarding preloaded cipher and key, that tells me that the actual computation > of a MAC is quick enough, that most of the slowdown is parameter overhead. > That was expected. There are 2 sorts of overhead. One is turning the key into a table, or something like that. The other is collecting the parameters and turning them into something that can be processed. Using strings as keys in the params tables seems like an invitation for not-fast. It's probably not significant if it is being used from deep inside SSL processing but the total processing time for an NTP packet is ballpark of 10 microseconds so difference on that scale become interesting. -- These are my opinions. I hate spam.
Re: CMAC timings
levi...@openssl.org said:
> What does surprise me, though, is that direct EVP_MAC calls would be slower
> than going through the PKEY bridge. I would very much like to see your code
> to see what's going on.
Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...
Richard's message said "I", so I sent him a copy off list. Correcting that...
/* Last modified on Sat Aug 28 14:30:11 PDT 1999 by murray */
/* Hack to time various implementations of CMAC.
*
* This is just the CMAC timing.
* It doesn't include the copy or compare or finding the right key.
*
* Beware of overflows in the timing computations.
*
* Disable AES-NI (Intel hardware: NI == New Instruction) with:
*OPENSSL_ia32cap="~0x202"
* Check /proc/cpuinfo flags for "aes" to see if you have it.
*/
#define CMAC_VERSION_CUTOFF 0x1003
#include
#include
#include
#include
#include
#include
/* Silence warnings from CMAC routines in OpenSSL 3.0.0 */
#define OPENSSL_SUPPRESS_DEPRECATED 1
#include
#include
#include
#include
#include
#include
#include
#if OPENSSL_VERSION_NUMBER > 0x2000L
#include
#endif
#define UNUSED_ARG(arg) ((void)(arg))
int NUM = 100;
#define PACKET_LENGTH 48
#define MAX_KEY_LENGTH 64
CMAC_CTX *cmac;
#if OPENSSL_VERSION_NUMBER > 0x2000L
EVP_MAC_CTX *evp;
#endif
unsigned char answer[EVP_MAX_MD_SIZE];
static void ssl_init(void)
{
#if OPENSSL_VERSION_NUMBER > 0x2000L
EVP_MAC *mac;
#endif
ERR_load_crypto_strings();
OpenSSL_add_all_digests();
OpenSSL_add_all_ciphers();
cmac = CMAC_CTX_new();
#if OPENSSL_VERSION_NUMBER > 0x2000L
mac = EVP_MAC_fetch(NULL, "cmac", NULL);
if (NULL == mac)
printf("## Oops, EVP_MAC_fetch() failed.\n");
evp = EVP_MAC_CTX_new(mac);
if (NULL == evp)
printf("## Oops, EVP_MAC_CTX_new() failed.\n");
#endif
}
static const EVP_CIPHER *CheckCipher(const char *name) {
const EVP_CIPHER *cipher;
char cbc[100];
snprintf(cbc, sizeof(cbc), "%s-CBC", name);
cipher = EVP_get_cipherbyname(cbc);
if (0 && NULL == cipher) {
/* no error available */
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops: EVP_get_cipherbyname() failed: %s\n%s\n",
cbc, str);
return NULL;
}
return cipher;
}
static void PrintHex(const unsigned char* bytes, int length) {
printf(" ");
for (int i=0; i 0x10101000L
static size_t One_PKEY(
EVP_PKEY *pkey,
EVP_MD_CTX *ctx, /* context */
uint8_t *pkt, /* packet pointer */
int pktlength /* packet length */
) {
size_t len = EVP_MAX_MD_SIZE;
if (1 != EVP_DigestSignInit(ctx, NULL, NULL, NULL, pkey)) {
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops, EVP_DigestSignInit() failed:\n%s.\n", str);
return 0;
}
EVP_DigestSign(ctx, answer, , pkt, pktlength);
return len;
}
static void DoPKEY(
const char *name, /* name of cipher */
uint8_t *key, /* key pointer */
int keylength, /* key length */
uint8_t *pkt, /* packet pointer */
int pktlength /* packet length */
)
{
struct timespec start, stop;
double fast;
unsigned long digestlength = 0;
const EVP_CIPHER *cipher = CheckCipher(name);
EVP_PKEY *pkey;
EVP_MD_CTX *ctx;
if (NULL == cipher) {
return;
}
pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher);
if (NULL == pkey) {
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops, EVP_PKEY_new_CMAC_key() failed: %s\n
%s.\n", \
name, str);
return;
}
ctx = EVP_MD_CTX_new();
if (NULL == ctx) {
printf("## Oops, EVP_MD_CTX_new() failed.\n");
return;
}
clock_gettime(CLOCK_MONOTONIC, );
for (int i = 0; i < NUM; i++) {
digestlength = One_PKEY(pkey, ctx, pkt, pktlength);
}
clock_gettime(CLOCK_MONOTONIC, );
fast = (stop.tv_sec-start.tv_sec)*1E9 + (stop.tv_nsec-start.tv_nsec);
printf("%12s %2d %2d %2lu %6.0f %6.3f",
name, keylength, pktlength, digestlength, fast/NUM, fast/1E9);
PrintHex(answer, digestlength);
printf("\n");
EVP_MD_CTX_free(ctx);
EVP_PKEY_free(pkey);
}
#endif
#if OPENSSL_VERSION_NUMBER > 0x2000L
static size_t One_EVP_MAC(
EVP_MAC_CTX *ctx, /* context */
char *cipher,
uint8_t *key, /* key pointer */
int keylength,/* key length */
uint8_t
CMAC timings
In general, things have slowed down. The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1. The new PKEY code takes twice as long as the old CMAC code on 1.1.1 The one ray of hope is that the API for EVP_MAC has split the part of the setup that uses the key out of the init routine. If we can hang on to a ctx for each key, we can cut the time in half - that's new ECP_MAC vs CMAC on 1.1.1 So how much memory does a ctx take? How can I find out? Even if I can't allocate a ctx per key, I can at least keep one around from recv to send. That makes the slowdown 1.7 instead of 3. -- Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz # KL=key length, PL=packet length, CL=CMAC length # OpenSSL 1.1.1g FIPS 21 Apr 2020 # CMACKL PL CL ns/op sec/run AES-128 16 48 16366 0.366 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16381 0.381 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16407 0.407 991f4017858de97515260dd9ae440b06 # PKEYKL PL CL ns/op sec/run AES-128 16 48 16436 0.436 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16448 0.448 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16461 0.461 991f4017858de97515260dd9ae440b06 - # OpenSSL 3.0.0-alpha3 4 Jun 2020 # CMACKL PL CL ns/op sec/run AES-128 16 48 16973 0.973 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16987 0.987 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16 1011 1.011 991f4017858de97515260dd9ae440b06 # PKEYKL PL CL ns/op sec/run AES-128 16 48 16817 0.817 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16824 0.824 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16842 0.842 991f4017858de97515260dd9ae440b06 # EVP_MAC KL PL CL ns/op sec/run AES-128 16 48 16 1136 1.136 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16 1153 1.153 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16 1181 1.181 991f4017858de97515260dd9ae440b06 Preload cipher and key. AES-128 16 48 16170 0.170 475ac1c053379e7dbd4ce80b87d2178e AES-192 24 48 16182 0.182 c906422bfe0963de6df50e022b4aa7d4 AES-256 32 48 16196 0.196 991f4017858de97515260dd9ae440b06 -- These are my opinions. I hate spam.
Re: PKEY for CMAC: operation not supported for this keytype.
Thanks. It's working now. Timings soon. The first paragraph in the man page for EVP_DigestSign and friends says: The EVP signature routines are a high level interface to digital signatures. Input data is digested first before the signing takes place. Down at the bottom, under CMAC, it says: Will ignore any digest provided. So I assume the first paragraph doesn't apply for CMAC. -- These are my opinions. I hate spam.
PKEY for CMAC: operation not supported for this keytype.
I can't get CMAC to work via PKEY. I get the same error on 1.1.1g and 3.0.0
I'm using a cipher that works with the CMAC interface.
Can anybody see what I'm missing?
/* hack to demonstrate pkey troubles */
/* build with:
* cc -Wall -I/usr/local/ssl/include \
* -L/usr/local/ssl/lib -lcrypto -o pkey pkey.c
*/
#include
#include
#include
#include
int main(int argc, char *argv[])
{
const unsigned char key[16];
const EVP_CIPHER *cipher;
EVP_PKEY *pkey;
EVP_PKEY_CTX *ctx;
printf("Build: %lx, %s\n", \
OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT);
printf("Run: %lx, %s\n", \
OpenSSL_version_num(), OpenSSL_version(OPENSSL_VERSION));
cipher = EVP_aes_128_cbc();
pkey = EVP_PKEY_new_CMAC_key(NULL, key, sizeof(key), cipher);
if (NULL == pkey) {
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops, EVP_PKEY_new_CMAC_key() failed:\n%s.\n", str);
return 1;
}
ctx = EVP_PKEY_CTX_new(pkey, NULL);
if (NULL == ctx) {
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops, EVP_PKEY_CTX_new() failed:\n%s.\n", str);
return 1;
}
if (1 != EVP_PKEY_sign_init(ctx)) {
unsigned long err = ERR_get_error();
char * str = ERR_error_string(err, NULL);
printf("## Oops, EVP_PKEY_sign_init() failed:\n%s.\n", str);
return 1;
}
/* More here when we get that far. */
return 0;
}
--
These are my opinions. I hate spam.
Re: freefunc - name clash with Python.h
Does my test program do anything interesting on your system? rs...@akamai.com said: > I dlon't lnow about Python's freefunc, no idea what it is, but the OpenSSL > line is defining a function with a local parameter named freefunc. Those > names shouldn't clash; what compiler and flags? Python has: typedef void (*freefunc)(void *); That looks weird to me, but I'm not a language guy. $ cc --version cc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1) (Fedora) cc -Wshadow -I/usr/include/python3.8 -I/usr/local/ssl/include -o freefunc-shadow freefunc-shadow.c > Can you switch the include order? That solves my problem. I was assuming this should get sorted out before release so other users don't get confused. There are 24 warnings, 535 lines. Here is everything from the last one. /usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] 124 |sk_##t1##_freefunc freefunc) \ |~~~^~~~ /usr/local/ssl/include/openssl/safestack.h:135:29: note: in expansion of macro âSKM_DEFINE_STACK_OFâ 135 | # define DEFINE_STACK_OF(t) SKM_DEFINE_STACK_OF(t, t, t) | ^~~ /usr/local/ssl/include/openssl/safestack.h:175:40: note: in expansion of macro âDEFINE_STACK_OFâ 175 | # define DEFINE_OR_DECLARE_STACK_OF(s) DEFINE_STACK_OF(s) |^~~ /usr/local/ssl/include/openssl/asn1.h:591:1: note: in expansion of macro âDEFINE_OR_DECLARE_STACK_OFâ 591 | DEFINE_OR_DECLARE_STACK_OF(ASN1_GENERALSTRING) | ^~ In file included from /usr/include/python3.8/pytime.h:6, from /usr/include/python3.8/Python.h:85, from freefunc-shadow.c:9: /usr/include/python3.8/object.h:156:16: note: shadowed declaration is here 156 | typedef void (*freefunc)(void *); |^~~~ Looking closer, there are 12 repeated pairs. ... | grep warning /usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] /usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] /usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] /usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] ... /usr/local/ssl/include/openssl/safestack.h:90:97: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] /usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of âfreefuncâ shadows a global declaration [-Wshadow] -- These are my opinions. I hate spam.
freefunc - name clash with Python.h
I get a blizzard of shadow warnings if Pyhton.h is included along with evp.h.
No problems on 1.1.1g from Fedora.
They go away if I include evp.h first.
/usr/local/ssl/include/openssl/safestack.h:124:72: warning: declaration of
âfreefuncâ shadows a global declaration [-Wshadow]
124 | sk_##t1##_freefunc freefunc) \
| ~~~^~~~
I don't know anything about that area. Is Python's freefunc the same as
OpenSSL's? Is this really a warning or a disaster waiting to happen?
Trivial test program attached.
/* hack to demonstrate freefunc name clash */
/* Build with:
* cc -Wall -Wshadow -I/usr/include/python3.8 \
* -I/usr/local/ssl/include -o freefunc-shadow freefunc-shadow.c
*/
#define PY_SSIZE_T_CLEAN
#include
#include
int main(int argc, char *argv[])
{
return 0;
}
--
These are my opinions. I hate spam.
Re: Cleaning up usage of CMAC_xxx
Thanks. > and a CMAC key using the function EVP_PKEY_new_CMAC_key(): That's the step I was missing. Right in front of my eyes. I'm still missing something though. Does this look reasonable: cipher = EVP_aes_128_cbc(); pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher); ctx = EVP_PKEY_CTX_new(pkey, NULL); EVP_PKEY_sign_init(ctx); The last step dies with: error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not supported for this keytype. [It will probably be obvious after somebody points me in the right direction.] That cipher work with CMAC. -- These are my opinions. I hate spam.
Re: Cleaning up usage of CMAC_xxx
levi...@openssl.org said: > In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to > "sign" with a MAC. We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge > the gap. Thanks, but... The EVP_PKEY seems to assume a public/private key environment. The man page for EVP_PKEY_new() says: The structure returned by EVP_PKEY_new() is empty. To add a private or public key to this empty structure use the appropriate functions described in EVP_PKEY_set1_RSA(3), EVP_PKEY_set1_DSA, EVP_PKEY_set1_DH or EVP_PKEY_set1_EC_KEY. We don't have public/private keys. Perhaps it will help if I describe our environment. The context is NTP. NTP is a classic client/server, request/response protocol. It uses UDP which is easily forged. Basic packets are 48 bytes. Shared-key authentication is optional. Out of band, the client and server agree on a key, algorithm, and key ID. The ID is an index into a (hash?) table of algorithm and key. Authenticated packets have the ID and MAC appended to the packet. The length of the MAC depends on the algorithm. Key info comes from the keyboard or a text file with 1 line per key. NIST uses USPS to distribute keys. Busy servers process 10K-100K packets per second. On the server, each packet requires 2 passes through the MAC algorithm, one to verify the MAC when receiving a request and another to compute the MAC when sending the response. The NTP protocol is simple. The MAC calculations are a significant fraction of the per packet CPU load. I'd like a fast/clean API to the low level MAC routines. The CMAC API was good. - I'm willing to do a reasonable amount of setup work during initialization, for example turning "AES" from a file to a EVP_CIPHER* to feed to CMAC_Init() Clean is more important than fast. I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if that's the cleanest way to go. I'm slightly concerned that the params API will be slow. It's moving string lookups into the mainline. I don't have any numbers yet. - We also have a similar HMAC like digest mode using MD5 and SHA1 via EVP_Digest. Will that API be around long term? -- These are my opinions. I hate spam.
Cleaning up usage of CMAC_xxx
CMAC_* have been DEPRECATED for 3.0.0 CHANGES.md suggests using EVP_MAC_xxx. Mostly, that seems reasonable, but there is one loose end. CMAC_Init includes a key and cipher. What's the equivalent in EVP_MAC_xxx? --- I found the params stuff, but that's new in 3.0.0 How do I do it in 1.1.1 or earlier? -- These are my opinions. I hate spam.
Are RAND_bytes and RAND_priv_bytes thread safe?
I didn't find any mention of threads in their man pages. -- These are my opinions. I hate spam.
Clutter in log files, bogus connections
I see a lot of clutter in log files from things like error:1408F10B:SSL routines:ssl3_get_record:wrong version number I assume they are from bad guys probing for openings. Is the error code returned by ERR_get_error() constant across releases? Can I compile magic constants like 1408F10B into my code? If not, is there a suggested approach? Is there a list of well known attacks and their error codes? -- These are my opinions. I hate spam.
Re: 1.1.1d LD_LIBRARY_PATH
> Would someone let me know how to add this path permanently, as currently i > need to re-add on restart ? man ld, search for rpath -- These are my opinions. I hate spam.
Re: logarithm in OpenSSL
guidovran...@gmail.com said: > If you require logarithms of large numbers, you'll have to resort to a > library that supports this, like the one I linked to. Or scale the large number so it fits and add the log of the scale factor which you can compute by hand from the scale factor. For example, log10(1234) is log10(1.234)+3*log10(10). -- These are my opinions. I hate spam.
Re: Does openssl sanity check ALPN strings?
w...@omnigroup.com said: > I don't think OpenSSL does any checking on the client side --- whatever bytes > you supply get sent to the server. > On the server side it does some checking before calling the alpn callback but > I don't know that it makes any guarantees of validity. Thanks. Does out/outlen as returned by the server side alpn callback include the length byte? man page says: cb is the application defined callback. The in, inlen parameters are a vector in protocol-list format. The value of the out, outlen vector should be set to the value of a single protocol selected from the in, inlen vector. The out buffer may point directly into in, or to a buffer that outlives the handshake. The arg parameter is the pointer set via SSL_CTX_set_alpn_select_cb(). -- These are my opinions. I hate spam.
Does openssl sanity check ALPN strings?
If a client passes {99, "a", "z" } with a length of 3 to
SSL_CTX_set_alpn_protos,
does that get rejected or sent to the server?
If a somebody sends that to a server, does it get passed to the alpn callback?
--
These are my opinions. I hate spam.
Re: Performance Issue With OpenSSL 1.1.1c
jayf0s...@roadrunner.com said: > I think I have tracked down the change in 1.1.1c that is causing this. It > is the addition of the DEVRANDOM_WAIT functionality for linux in e_os.h and > crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in a select() call > on /dev/random. ... I have seen similar delays that don't involve OpenSSL. [ 10.585102] [drm] Initialized qxl 0.1.0 20120117 for :00:02.0 on minor 0 [ 10.605881] EDAC sbridge: Seeking for: PCI ID 8086:3ca0 [ 10.605887] EDAC sbridge: Ver: 1.1.2 [ 540.286117] random: crng init done [ 540.287631] random: 7 urandom warning(s) missed due to ratelimiting May 18 20:59:00 ntp1 kernel: [drm] Initialized qxl 0.1.0 20120117 for :00:02.0 on minor 0 May 18 21:09:55 ntp1 kernel: random: crng init done -- These are my opinions. I hate spam.
Re: How to disable TLS 1.3 in OpenSSL 1.1.1
> But I want to use TLS 1.2 only for my application with curl 7.58 in Ubuntu > 18.04. So while using openssl 1.1.1 how to disable default TLS 1.3 and how > to enable TLS 1.2? Just curious. Why do you want to disable TLS 1.3? It will automagically use 1.2 if that's all the other end supports. Why not use 1.3 if both ends support it? > Can I set any flags while building openssl 1.1.1 to disable TLS 1.3 or can > i get any package from ubuntu to disable TLS 1.3 ? You can do it at run time using SSL_set_max_proto_version -- These are my opinions. I hate spam.
[openssl-users] Man page suggestion - SSL_get_verify_result
Is there a better place for things like this? Please add X509_verify_cert_error_string to the SEE ALSO section of the man page for SSL_get_verify_result Thanks. -- These are my opinions. I hate spam. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
