Re: checking for enable-weak-ssl-ciphers at runtime?
On 23/05/2020 21:08, Daniel Lenski wrote: > When OpenConnect is explicitly requested to connect to an ancient > server, what I am currently trying to do is > SSL_CTX_set_cipher_list(ctx, "DEFAULT:+3DES:+RC4"). However, this > fails silently on subsequent connection if 3DES/RC4 support isn't > available. As long as at least one cipher is successfully set then this command will succeed. By setting "DEFAULT" you're getting all the ciphersuites in the default list and hence the command succeeds. If you want to test if you have any 3DES ciphersuites available then you can try this: SSL_CTX_set_cipher_list(ctx, "3DES") This will succeed if at least one 3DES cipersuite is available, and fail otherwise. Or you could do: SSL_CTX_set_cipher_list(ctx, "3DES:RC4") Which will succeed if there is at least one ciphersuite based on 3DES or RC4 available, and fail otherwise. > It was suggested that I should try EVP_get_ciphername(). The ciphers available via the EVP API are only indirectly related to the ciphersuites available in libssl. If there are no 3DES based ciphers available via EVP then there won't be any libssl 3DES based ciphersuites. But the reverse is not true, i.e. 3DES may not be available in libssl, but it is via EVP. So this is not a great test for your purposes. Matt
RE: checking for enable-weak-ssl-ciphers at runtime?
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Daniel Lenski
> Sent: Saturday, May 23, 2020 17:24
>
> > Other than looping through all of the ciphers with SSL_get_ciphers()
> > right after this… is there a better way to check for 3DES/RC4 support
> > right at startup, so we can give immediate feedback that connecting to
> > such a server cannot succeed?
>
> It was suggested that I should try EVP_get_ciphername().
>
> I tested both EVP_get_cipherbyname("DES-EDE3-CBC") == NULL, and
> EVP_des_ede3_cbc() == NULL, but unfortunately both of those APIs
> appear insensitive to whether or not 3DES is actually supported by the
> library.
>
> Is there another approach to check for 3DES support before actually
> creating an SSL_CTX?
Actually trying to encrypt something using 3DES and the EVP API? Maybe it would
even fail on EVP_CipherInit.
It's been a while since I used that, but something like:
static const unsigned char dummy[192] = {1};
unsigned char dummy_out[8];
int outlen = 0;
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
int tdes_enabled = EVP_CipherInit(ctx, EVP_des_ede3_cbc(), dummy, dummy) &&
EVP_EncryptUpdate(ctx, dummy_out, , dummy, 1) &&
EVP_EncryptFinal(ctx, dummy_out, );
EVP_CIPHER_CTX_free(ctx);
Untested.
--
Michael Wojcik
Distinguished Engineer, Micro Focus
Re: distributed secret key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Phillip,
On Sun, 24 May 2020, Phillip Hallam-Baker wrote:
In short, yes, I have stuff that works for this and I think it would be
particularly useful for code signing and for inside CAs. But it does need
some additional work to apply it to that application.
this sounds promising. :-)
I do indeed have running code but not (necessarily) for this particular
variant (yet).
What I have right now is a scheme that allows
1) An existing secret key to be split into (n,t) shares where the threshold
t < number of shares.
I suppose, this includes also the part to use/reconstruct the secret key?
May I ask, what we need to do to sign something with the splitted key?
2) A group of people who each have a secret to jointly create a composite
key with n shares and a threshold of n[*].
Is this a typo or is here really t=n? I'm asking, because we're actually
more concerned about redundancy (t1) -
though we do prefer a distributed key (e.g. t>1), if that is feasible.
These are currently specified for Ed448 or Ed25519 but conversion to the
NIST curves is straightforward
This might be a stupid question, but: Are there any restrictions imposed,
what algorithms are allowed to be used by a (root) CA? Or is this mainly a
matter of "taste"?
I do not currently have a version that supports t people coming together
with a set of Shamir secret parameters and jointly creating n Shamir secret
parameters. There is a proposal (FROST) to do that but the authors are not
ready for it to be used.
Ok, so we will probably say good bye to the separately-created-key
approach and split a given secret key which we will afterwards securely
erase (and only keep the parts).
[*] The particular concern here is that it is necessary to defeat a
malicious contribution attack in which Alice Bob and Mallet jointly create a
key but Mallet goes last and instead of contributing to the shared secret,
he instead generates a new key pair and calculates the public value that
will trick Alice and Bob into accepting his as the valid one. Whether this
attack is relevant or not depends on your intended protocol.
For example, lets say Alice and Bob's key pairs are {a.P, a}, {b.P, b}.
Mallet is supposed to contribute m.P from {m.P, m} and the composite key
will be {x.P, x} where x = a+b+m.
Instead Mallet contributes (z-a-b).P which he can calculate by generating z
and calculating z.P-a.P-B.P so the composite key x = a+b+m = a+b+z-a-b = z.
So Mallet knows the secret key and only Mallet can use it.
For the set of applications I care about, this attack is not actually that
important because while Mallet knows the secret key, he is the only person
who does. And so he won't be able to respond to any composite signature
request with a valid answer.
But he can still sign anything he wants, right? Or does he never see the
csr, but only the "preprocessed" csr, so he cannot sign it?
So for PKIX type applications, this is self defeating as only Mallet can
generate the CSR.
Why would they want to create CSRs? In our case, this is intended to be
the Root CA.
Regards,
Erich
On Sun, May 24, 2020 at 12:20 PM Michael Richardson
wrote:
Erich Eckner wrote:
> we're looking into setting up a CA with openssl, but we
would like to
> distribute the secret key amongst multiple persons. We're
aware of
> Shamir's secret sharing algorithm, but we'd like to know
if there is some
> algorithm supported by openssl, that fulfills the
following requirements
> (2 and 3 are not fulfilled by Shamir's algorithm):
> 1. Secret key shared amongst N persons, M the key.
> 2. No secret material (or parts thereof) needs to be sent
around,
> preferably not even during creation of the key.
So you want to split a secret, but then not send anything to
anyone?
I don't really understand this at all. I don't think it's
physically
possible. Maybe you could restate your requirement in another
way.
> 3. Secret key will not be assembled from the shares for
the acutal
> operation. E.g. each share operates independently, and the
intermediate
> result is sent around, after M keyparts operated on it,
the signature is
> complete and can be used.
I guess you want a system where the shares can be added after
"exponentiation" rather than before.
> If this is not supported by openssl, we're also open for
suggestions of
> other (open source, free-to-use) software, that can
achieve this and
> creates standard X.509 certificates (not sure if I termed
that correctly).
I believe that Phillip Hallam-Baker's
Threshold Modes in Elliptic Curves
draft-hallambaker-threshold-02
may fullfil
Re: distributed secret key
Actually, I was wrong about the prior one. https://patents.google.com/patent/US6411716 looks like it has a distributed CA function with multi-step, multi-fragment signatures. (This looks fascinating, and I'm going to study it over the weekend -- still in a lockdown, so no real Memorial Day party for me.) -Kyle H On Sun, May 24, 2020, 14:59 Kyle Hamilton wrote: > From glancing at the abstract, https://patents.google.com/patent/US5799086 > looks like it might be the one? It also says that it is expired, > expiration having been anticipated on 2014-01-13. > > -Kyle H > > On Sun, May 24, 2020, 11:54 Salz, Rich wrote: > >> >>- In any case, I am unaware of any existing system which meets your >>requirement 3. Admittedly, I haven't specifically searched for such. >> >> >> >> CertCo (now defunct, don’t know who has the intellectual property) had a >> patent that did ALL of the things. RSA keygen, split the key, each key >> signs the data, looks like an RSA signature, then when enough have been >> done, combine them and it matches the original pre-split public key. That, >> and the followon patents, are cool. Don’t know if they’re expired or not. >> >> >> >> To answer the main question: OpenSSL doesn’t do anything remotely in this >> area. The closest is multi-prime RSA. >> >
Re: distributed secret key
>From glancing at the abstract, https://patents.google.com/patent/US5799086 looks like it might be the one? It also says that it is expired, expiration having been anticipated on 2014-01-13. -Kyle H On Sun, May 24, 2020, 11:54 Salz, Rich wrote: > >- In any case, I am unaware of any existing system which meets your >requirement 3. Admittedly, I haven't specifically searched for such. > > > > CertCo (now defunct, don’t know who has the intellectual property) had a > patent that did ALL of the things. RSA keygen, split the key, each key > signs the data, looks like an RSA signature, then when enough have been > done, combine them and it matches the original pre-split public key. That, > and the followon patents, are cool. Don’t know if they’re expired or not. > > > > To answer the main question: OpenSSL doesn’t do anything remotely in this > area. The closest is multi-prime RSA. >
Re: distributed secret key
* In any case, I am unaware of any existing system which meets your requirement 3. Admittedly, I haven't specifically searched for such. CertCo (now defunct, don’t know who has the intellectual property) had a patent that did ALL of the things. RSA keygen, split the key, each key signs the data, looks like an RSA signature, then when enough have been done, combine them and it matches the original pre-split public key. That, and the followon patents, are cool. Don’t know if they’re expired or not. To answer the main question: OpenSSL doesn’t do anything remotely in this area. The closest is multi-prime RSA.
Re: distributed secret key
There are two ways to handle multiple authorizations needed: 1) Secret data is shared across multiple locations/holders, or 2) Secret data is stored in a trusted system which itself requires multiple authorizations. You could perhaps put together multiple trusted systems, each of which has a share of the secret data, and then have single authorizations for each of those multiple systems. But that that point, you're opening up a huge can of logistical worms that you seriously need to examine through the lens of a threat model evaluation, particularly against potentially rogue system administrators and backup operators. There is no possible way to have a distributed secret key without distributing secret data across multiple entities/systems, though. Whether those entities are in the custody of those who possess the authority to use them is unimportant, but if they are not then your threat model must include attacks by those whose custody those entities/systems are actually in. (Multiple encrypted containers/home directories for those shares might work on the same system, but you still need to "send the secret data around" to each of them.) In any case, I am unaware of any existing system which meets your requirement 3. Admittedly, I haven't specifically searched for such. -Kyle H On Sun, May 24, 2020, 05:04 Erich Eckner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > we're looking into setting up a CA with openssl, but we would like to > distribute the secret key amongst multiple persons. We're aware of > Shamir's secret sharing algorithm, but we'd like to know if there is some > algorithm supported by openssl, that fulfills the following requirements > (2 and 3 are not fulfilled by Shamir's algorithm): > > 1. Secret key shared amongst N persons, M the key. > > 2. No secret material (or parts thereof) needs to be sent around, > preferably not even during creation of the key. > > 3. Secret key will not be assembled from the shares for the acutal > operation. E.g. each share operates independently, and the intermediate > result is sent around, after M keyparts operated on it, the signature is > complete and can be used. > > If this is not supported by openssl, we're also open for suggestions of > other (open source, free-to-use) software, that can achieve this and > creates standard X.509 certificates (not sure if I termed that correctly). > > Thank you in advance! > > Regards, > Erich > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KRVMACgkQCu7JB1Xa > e1rhyBAAvzJUrwcyRLpdme/mWsF/ftuA8nqv/ccw4be9Q1Y/S72MU/7UhKW2dBE0 > jp2tBV4zq5D3i37ElCy+Mco97cCQ+Ikg3pOtYaMYkK0hoybBlyX6onX0Y7jQhP2W > N2v07HaN5RxtunxJgh7wUkWMy5arigKY9e645vJh5c8Ii5pwBb8QMwwMUJfb/1Hv > 5yrF4x8la3lmqQSsAwkj0FFhAAmh+Xe/v4D+uoEzmTHY7vi9hGJsAAYNmJkwsIAb > M/lK43wZRAXVbotFOVrud10wchBOSUtY0w6T5apmNJ/ArA61EbuFVtUUjjBYiv87 > oVxr+3pydjJLDW4WczcKLKQdNbhGPhmmz4DDHxvhLXSTrtFAPUm4Qb3VeM1AO0it > Gs943eoBkUrga6813sBmulbtM3fnfDbJro0/ZqQnh4/vRKQUy6LvMj2W/M/8Fn1C > M8um53J35/BAakZhOHaNvDrVty4bEJ0y1fNs7JNNpQfB+WjL8C04g2uExNJmAKgG > 0dmZxDNGrPLKrltz+R39j0gbA4P1hnYkcgAYFcGho0z468IV5sgleHN3FhAp1qr5 > /TAuD2rwuPxT9wXf726n09iYJpq6jVhpBuF74mBNbyDdTzeeJtVq9mqngmhWqOCw > KJcTXIhIem2wTA2yfhzf1PNK58hU55/lB36TnRryapp1rXLu1uU= > =+60v > -END PGP SIGNATURE- >
Re: distributed secret key
Erich Eckner wrote: > we're looking into setting up a CA with openssl, but we would like to > distribute the secret key amongst multiple persons. We're aware of > Shamir's secret sharing algorithm, but we'd like to know if there is some > algorithm supported by openssl, that fulfills the following requirements > (2 and 3 are not fulfilled by Shamir's algorithm): > 1. Secret key shared amongst N persons, M the key. > 2. No secret material (or parts thereof) needs to be sent around, > preferably not even during creation of the key. So you want to split a secret, but then not send anything to anyone? I don't really understand this at all. I don't think it's physically possible. Maybe you could restate your requirement in another way. > 3. Secret key will not be assembled from the shares for the acutal > operation. E.g. each share operates independently, and the intermediate > result is sent around, after M keyparts operated on it, the signature is > complete and can be used. I guess you want a system where the shares can be added after "exponentiation" rather than before. > If this is not supported by openssl, we're also open for suggestions of > other (open source, free-to-use) software, that can achieve this and > creates standard X.509 certificates (not sure if I termed that correctly). I believe that Phillip Hallam-Baker's Threshold Modes in Elliptic Curves draft-hallambaker-threshold-02 may fullfil your needs. It might even satisfy (2), but I'm not sure it satisfies (1). It may be that you don't need to satisfy (1). I know that Phil has running code, but I don't think it's based upon openssl. -- ] 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
Openssl Libraries ssleay32.lib and libeay32.lib for Microsoft code signing.
Hi, I am working with an application that uses OpenSSL version 1.0.2h, Where application need to be certified and code signing by Microsoft Secure boot compatibility(UEFI). These openssl libraries ssleay32.lib and libeay32.lib also need to be certified. Can we send these openssl libraries for certification to Microsoft directly? or Do we have any Openssl binaries which are certified and code signed by Microsoft?. Thanks Suresh kotte -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
distributed secret key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, we're looking into setting up a CA with openssl, but we would like to distribute the secret key amongst multiple persons. We're aware of Shamir's secret sharing algorithm, but we'd like to know if there is some algorithm supported by openssl, that fulfills the following requirements (2 and 3 are not fulfilled by Shamir's algorithm): 1. Secret key shared amongst N persons, Mthe key. 2. No secret material (or parts thereof) needs to be sent around, preferably not even during creation of the key. 3. Secret key will not be assembled from the shares for the acutal operation. E.g. each share operates independently, and the intermediate result is sent around, after M keyparts operated on it, the signature is complete and can be used. If this is not supported by openssl, we're also open for suggestions of other (open source, free-to-use) software, that can achieve this and creates standard X.509 certificates (not sure if I termed that correctly). Thank you in advance! Regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KRVMACgkQCu7JB1Xa e1rhyBAAvzJUrwcyRLpdme/mWsF/ftuA8nqv/ccw4be9Q1Y/S72MU/7UhKW2dBE0 jp2tBV4zq5D3i37ElCy+Mco97cCQ+Ikg3pOtYaMYkK0hoybBlyX6onX0Y7jQhP2W N2v07HaN5RxtunxJgh7wUkWMy5arigKY9e645vJh5c8Ii5pwBb8QMwwMUJfb/1Hv 5yrF4x8la3lmqQSsAwkj0FFhAAmh+Xe/v4D+uoEzmTHY7vi9hGJsAAYNmJkwsIAb M/lK43wZRAXVbotFOVrud10wchBOSUtY0w6T5apmNJ/ArA61EbuFVtUUjjBYiv87 oVxr+3pydjJLDW4WczcKLKQdNbhGPhmmz4DDHxvhLXSTrtFAPUm4Qb3VeM1AO0it Gs943eoBkUrga6813sBmulbtM3fnfDbJro0/ZqQnh4/vRKQUy6LvMj2W/M/8Fn1C M8um53J35/BAakZhOHaNvDrVty4bEJ0y1fNs7JNNpQfB+WjL8C04g2uExNJmAKgG 0dmZxDNGrPLKrltz+R39j0gbA4P1hnYkcgAYFcGho0z468IV5sgleHN3FhAp1qr5 /TAuD2rwuPxT9wXf726n09iYJpq6jVhpBuF74mBNbyDdTzeeJtVq9mqngmhWqOCw KJcTXIhIem2wTA2yfhzf1PNK58hU55/lB36TnRryapp1rXLu1uU= =+60v -END PGP SIGNATURE-
