Re: [openssl-users] generating shared key
> On Nov 12, 2018, at 9:03 PM, Skip Carter wrote: > > I know this is simple but I can't seem to find find this little detail: > > I have Alice's public ECDH key in memory. And Bob's private ECDH key > in memory. How do I combine them to get the shared key? > > Is this step literally the same as conventional DH ? https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive.html -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] generating shared key
I know this is simple but I can't seem to find find this little detail: I have Alice's public ECDH key in memory. And Bob's private ECDH key in memory. How do I combine them to get the shared key? Is this step literally the same as conventional DH ? -- Skip Carter Taygeta Scientific Inc. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Win32 BIO server, no accept
Hello,
I'm pretty new to OpenSSL and need to implement a secure connection. It's a
Win32 application that uses a standard socket implementation up to now and
runs for some years already.
To implement SSL/TLS I downloaded 1.1 and compiled the DLLs for VS2015. The
tests are all "green".
Now I started to integrate OpenSSL into the application. First step for me
is to replace the socket implementation with BIO, no security stuff is
involved yet.
The app can be configured to act as a TCP server or a client. I was able to
get it to work via BIO as a client, but the problem is the server role. I
don't get a valid (second) accept call, no client is able to connect. Inside
the app this is done via a non-blocking listening socket (return value is
always -1 with "WOULDBLOCK" set), but I even copied the sample code from the
blog (blocking mode) into the app's initialization code and the second call
to BIO_do_accept never returns:
SSL_load_error_strings();
ERR_load_BIO_strings();
OpenSSL_add_all_algorithms();
BIO *abio, *cbio, *cbio2;
/* First call to BIO_accept() sets up accept BIO */
abio = BIO_new_accept("");
if (BIO_do_accept(abio) <= 0) {
fprintf(stderr, "Error setting up accept\n");
ERR_print_errors_fp(stderr);
exit(1);
}
/* Wait for incoming connection */
if (BIO_do_accept(abio) <= 0) {
fprintf(stderr, "Error accepting connection\n");
ERR_print_errors_fp(stderr);
exit(1);
}
fprintf(stderr, "Connection 1 established\n");
/* Retrieve BIO for connection */
cbio = BIO_pop(abio);
...
What's the problem here? I'm currently running under Win 8.1.
Best regards,
Karsten
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
OpenSSL Security Advisory [12 November 2018] Microarchitecture timing vulnerability in ECC scalar multiplication (CVE-2018-5407) === Severity: Low OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown to be vulnerable to a microarchitecture timing side channel attack. An attacker with sufficient access to mount local timing attacks during ECDSA signature generation could recover the private key. This issue does not impact OpenSSL 1.1.1 and is already fixed in the latest version of OpenSSL 1.1.0 (1.1.0i). OpenSSL 1.0.2 is affected but due to the low severity of this issue we are not creating a new release at this time. The 1.0.2 mitigation for this issue can be found in commit b18162a7c. OpenSSL 1.1.0 users should upgrade to 1.1.0i. This issue was reported to OpenSSL on 26th October 2018 by Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri. Note OpenSSL 1.1.0 is currently only receiving security updates. Support for this version will end on 11th September 2019. Users of this version should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20181112.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html signature.asc Description: OpenPGP digital signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] understanding ASN1_item_verify()
Zero,
my goal is to validate Certificate Signing Requests in ruby.
First,
https://www.openssl.org/docs/man1.1.1/man3/ASN1_item_verify.html
and
https://www.openssl.org/docs/man1.1.0/man3/ASN1_item_verify.html
.. do not seem to exist, but at least
https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_set_ctrl.html
points to such a page.
I'm not sure what this means for this function. It also does not
show up in doc/*, but it is exported in crypto.num.
Maybe it should not be used by new code?
Second,
I was looking at:
int X509_REQ_verify(X509_REQ *a, EVP_PKEY *r)
{
return (ASN1_item_verify(ASN1_ITEM_rptr(X509_REQ_INFO),
>sig_alg, a->signature, >req_info,
r));
}
as I'm not sure that I want to build a ruby wrapper for X509_REQ.
I just don't understand ASN1_ITEM_rptr. My understanding is that
it returns a function (or global) that would be named X509_REQ_INFO_it().
But, how does the "a" argument get connected with this?
I'm thinking that there is some global "current ASN1 thing" that is involved,
but surely that can't be...
If there is any non-generic documentation on X509_REQ_*(), I haven't found it.
signature.asc
Description: PGP signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Server-side visibility of signature algorithm and key exchange properties?
On 09/11/2018 19:42, Viktor Dukhovni wrote: > On Fri, Nov 09, 2018 at 06:42:28PM +, Matt Caswell wrote: > >>> I am having a bit of trouble finding the equivalent information for >>> the 3rd line on the server side. Anyone know how, in TLS 1.3 where >>> these are not implied by the ciphersuite, to determine the signature >>> algorithm (and curve for ECDSA), the hash algorithm and key exchange >>> public key (with bit count for DH or curve name for ECDSA)? >> >> I don't believe we currently expose the signature algorithm selected on >> the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only >> ever used internally. > > Thanks for confirming, it is then not surprising I failed to find > the relevant interfaces. :-) > >> Similarly the key exchange public key is held in s->s3->peer_tmp. We do >> expose that via SSL_get_server_tmp_key(), but its a client side only >> function. We explicitly check that and return 0 if called on the server >> side. > > Quick question about that, since the client may also sign the key > exchange when a client certificate is requested and returned, what > is held on the server in s->s3->tmp.sigalg? [ I expect still the > signature the server used in its CertificateVerify. And on the > client side, I would expect this to hold the algorithm used by the > client to sign its ClientVerify if a client cert was used. ] Right - exactly that. s->s3->tmp.sigalg always holds the sigalg the endpoint selected to sign its own CertificateVerify (whether that be client or server). > > And it seems that on the server side s->s3->peer_tmp does actually > hold the client's key exchange public key, which is necessarily for > the same group as the server, so all we'd need to do is remove that > 'explicit check' and that key be visible on the server side, right? > Right - although we might want to think about the name of the function. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
