Re: error: dereferencing pointer to incomplete type DH {aka struct dh_st}

[Viktor Dukhovni]

On Fri, Jun 28, 2019 at 09:22:48PM +, Mark Richter wrote:

> I've tried looking this up on the web, but there is no clear guidance on how 
> to get around this.

The documentation is a good place to start.

https://www.openssl.org/docs/man1.1.1/man3/DH_set0_pqg.html

If that's not it, look for other manpages that mention DH:

https://www.openssl.org/docs/man1.1.1/man3/

In Postfix I have some macros that simulate 1.1.x interfaces for
OpenSSL 1.0.2:


https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls.h#L87-L117

these are by no means a complete list, but my advice is to do
something similar, that is, switch to the 1.1.x APIs and define
forward-compatibility macros for 1.0.2.

-- 
Viktor.

Re: error: dereferencing pointer to incomplete type DH {aka struct dh_st}

[Salz, Rich via openssl-users]

>I'm attempting to build our RHEL 7 based product on RHEL 8 and running 
> into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 
> 8).  I haven't found a good guide to adapting the sources to these changes.

Web search for "openssl opaque accessors" turns up many hits; these two seem 
useful:
  
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
http://vega.pgw.jp/~kabe/vsd/migrate2openssl-1.1.html 
 
PS: A long confidential email disclaimer is silly, particularly when posting to 
a large public mailing list. :)

error: dereferencing pointer to incomplete type DH {aka struct dh_st}

[Mark Richter]

I've tried looking this up on the web, but there is no cleare guidance on how 
to get around this.


I'm attempting to build our RHEL 7 based product on RHEL 8 and running into a 
lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 8).  I 
haven't found a good guide to adapting the sources to these changes.


Where can I find one?


Thanks.

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

Re: Does openssl sanity check ALPN strings?

[Hal Murray]

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.

Re: ECDSA curves and certificates in 1.0.2X vs 1.1.x

[Michael Richardson]

Viktor Dukhovni  wrote:
> On Tue, Jun 25, 2019 at 10:38:50AM -0400, Michael Richardson wrote:

>> openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
>> -nodes -subj "/CN=${ULA_HOSTNAME}" \
>> -keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
>> -reqexts SAN \
>> -config /tmp/shg.ossl.cnf

> This generates a key that has explicit parameters (rather than a named
> curve) also in OpenSSL 1.0.2h, for example.  Since you probably want
> to use named curves, with 1.0.2 you'll have to generate the key 
separately,
> and explicitly indicate that you want a named curve key.  For that also
> include an additional:

> -pkeyopt ec_param_enc:named_curve

> option.  This was not on by default in OpenSSL 1.0.2.

Thank you again, this worked great.
(I wonder if we had that before, and it just got lost as we rebuild from source)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature

Re: Validating RSA Random Probably Prime KAT !!

[Hareesh D]

Looks like BN_is_prime_ex() is the API to check this test.

On Wed, 26 Jun 2019, 18:59 Hareesh D,  wrote:

> These is a testvector available in NIST Keyagrn_186-3_Random
> ProbablyPrime3_3_KAT.txt.
>
> Is it possible to verify this with OpenSSL1.1.1a. If yes, Can you please
> give the corresponding APIs to be used.
>
> I considered prandom, qrandom as factors p, q and tried checking RSA key
> generation with the mentioned exponent. But results are not as expected. I
> guess prandom, qrandom are to be used as only initial random prime numbers
> and see that key generation tries to generate a new random number when they
> are not meeting the criteria as mentioned in the *.txt file (reason as part
> of Result) .
> Just my assumption.
>
> Is this file really a test vector and implementations should comply? I see
> some info about this in rsa2vs.pdf (available in NIST) section 6.2.2.1.
>
> How OpenSSL complies to this.
>
> Thanks !!
>