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
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.
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
> 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
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
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
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
> 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
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
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
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
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)
> 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
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.
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
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
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
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
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
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:
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
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
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 |
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);
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
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
I didn't find any mention of threads in their man pages.
--
These are my opinions. I hate spam.
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
> 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.
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
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
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.
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
> 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
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:
35 matches
Mail list logo
