Re: Quantum-Resistant Cryptographic Algorithms
The project will once they are formally standardised. In the meantime, the Open Quantum Safe project has a provider that implements all of the candidate algorithms (https://github.com/open-quantum-safe/oqs-provider). Pauli On 1/11/22 15:14, ad...@redtile.com wrote: Will OpenSSL persue/support the four new NIST Quantum Cryptographic Algorithms? https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
Quantum-Resistant Cryptographic Algorithms
Will OpenSSL persue/support the four new NIST Quantum Cryptographic Algorithms? https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
Quantum-Resistant Cryptographic Algorithms
Will OpenSSL persue/support the four new NIST Quantum Cryptographic Algorithms? https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
Re: command 'openssl ciphers -v -provider fips' shows not complain algorithms
On 26/01/2022 11:27, Jan Lana wrote: Hi, When I run openssl ciphers -v -provider fips | grep TLS_CHACHA20_POLY1305_SHA256 it shows this non complain cipher is available. This looks correct behaviour to me. Your openssl.cnf file is explicitly activating the default provider. The "-provider" option is additive. Since your config file activates the default provider, you end up with both the default and fips providers active. To add '-propquery fips=yes' argument does not help. IMHO it is not correct behavior. This is a bug. Fix here: https://github.com/openssl/openssl/pull/17595 Matt I have the default and fips providers enabled in openssl.cnf: openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect default = default_sect [default_sect] activate = 1 For testing I use docker.io/salrashid123/openssl:fips image with modified /usr/local/ssl/openssl.cnf. When I add 'alg_section = algorithm_sect' to [openssl_init] section defined as follows: [algorithm_sect] default_properties = fips=yes the command 'openssl cipher -v' shows just fips compliant ciphers. I found it when I try to build stunnel 5.62 and one of their test fails. The test uses OSSL_PROVIDER_load() to load fips provider and then set ciphersuite to TLS_CHACHA20_POLY1305_SHA256. Expected results is that there is no complain cipher. (https://github.com/mtrojnar/stunnel/blob/178822afdefb0798fb937f6b5f43b47c5ab77613/tests/plugins/p11_fips_cipher.py#L78) Thanks in advance, - jenda
command 'openssl ciphers -v -provider fips' shows not complain algorithms
Hi, When I run openssl ciphers -v -provider fips | grep TLS_CHACHA20_POLY1305_SHA256 it shows this non complain cipher is available. To add '-propquery fips=yes' argument does not help. IMHO it is not correct behavior. I have the default and fips providers enabled in openssl.cnf: openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect default = default_sect [default_sect] activate = 1 For testing I use docker.io/salrashid123/openssl:fips image with modified /usr/local/ssl/openssl.cnf. When I add 'alg_section = algorithm_sect' to [openssl_init] section defined as follows: [algorithm_sect] default_properties = fips=yes the command 'openssl cipher -v' shows just fips compliant ciphers. I found it when I try to build stunnel 5.62 and one of their test fails. The test uses OSSL_PROVIDER_load() to load fips provider and then set ciphersuite to TLS_CHACHA20_POLY1305_SHA256. Expected results is that there is no complain cipher. (https://github.com/mtrojnar/stunnel/blob/178822afdefb0798fb937f6b5f43b47c5ab77613/tests/plugins/p11_fips_cipher.py#L78) Thanks in advance, - jenda
enable/disable algorithms at build time
I want to reduce the size of EDK2 CryptoPkg by enabling, at build time, only the OpenSSL algorithms I want supported in my code. Is this possible via a configuration mechanism? I can't find anything in documentation. Does this violate the GPL license? Thanks.Lee
Algorithms Used for openssl- pkcs12
Hello We're unable to find documentation on the specific standards/algorithms used by the openssl -pkcs12 command for OpenSSL version 1.1.1k. Specifically, when a password is used (-password) for private key wrap key derivation, is the algorithm compliant with NIST SP 800-132? Also, when the AES-256 is selected for private key wrap (-aes256), is the implementation compliant with NIST 800-38F? Any help will be greatly appreciated! --Vlad
modern algorithms performance in TLS 1.3
Dear,
Actually I'm doing the final project degree about modern algorithms performance
in TLS 1.3.
I would like to know if you can confirm some questions:
-The calculation of the shared secret of ECDH/DH for TLS 1.3 in the library
openssl is calculated in the function ssl_derive from the class s3_lib.c in the
part of the code:
if (EVP_PKEY_derive(pctx, pms, ) <= 0) {
SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_SSL_DERIVE,
ERR_R_INTERNAL_ERROR);
goto err; }
Is it correct to calculate the keygen performance using the EVP_PKEY_keygen
function?
Is it correct to calculate the performance of signing and verifying using
EVP_PKEY_verify and EVP_PKEY_sign function? And in the case of ED25519 using
ED25519_sign and ED25519_verify from curve25519.c?
Thanks for all.
Jesus
Useable digest algorithms with signature
Dear All, Which digest algorithms can be used for signature with a RSA key ? sha and ripemd160 work well, but - whirlpool that works in 1.0.2o, doesn't anymore (1.1.1j) - the same applies to blake, shake Error setting context 6116:error:0408C09D:rsa routines:check_padding_md:invalid digest:crypto\rsa\rsa_pmeth.c:390: What is the reason ? (intellectual curiosity ?) Thanks. Patrice.
Re: Integration of new algorithms
Kris, Dynamically allocate yourself a block of NIDs, one for each algorithm, using OBJ_new_nid(). Note also, that there is a preferable option if you are working against the upcoming 3.0. Instead of developing an engine, create a provider. This avoids NIDs completely and was designed from the ground up to support what you want. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 27 Aug 2020, at 2:21 am, Kris Kwiatkowski wrote: > > Hello, > > I'm working on development of OpenSSL ENGINE that integrates > post-quantum algorithms (new NIDs). During integration I > need to modify OpenSSL code to add custom function, but would > prefer not to need add anything to OpenSSL code (so engine > can be dynmicaly loaded by any modern OpenSSL). > > So, In three cases, namely when the code is in callbacks for keygen, > encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt > and EVP_PKEY_keygen) I need to get NID of the scheme. The problem > is that, those functions are called with EVP_PKEY_CTX object > provided as an argument. The NID is stored in the > EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API > which would return that value. > > I've added a simple function that returns pkey_id from the ctx, but > that means that I need to change OpenSSL code. Is there any way > to get NID without changing OpenSSL? > > Kind regards, > Kris > > > >
Integration of new algorithms
Hello, I'm working on development of OpenSSL ENGINE that integrates post-quantum algorithms (new NIDs). During integration I need to modify OpenSSL code to add custom function, but would prefer not to need add anything to OpenSSL code (so engine can be dynmicaly loaded by any modern OpenSSL). So, In three cases, namely when the code is in callbacks for keygen, encryption and ctrl (called by EVP_PKEY_CTX_ctrl, EVP_PKEY_encrypt and EVP_PKEY_keygen) I need to get NID of the scheme. The problem is that, those functions are called with EVP_PKEY_CTX object provided as an argument. The NID is stored in the EVP_PKEY_CTX->pmeth->pkey_id. I think (AFAIK) there is no API which would return that value. I've added a simple function that returns pkey_id from the ctx, but that means that I need to change OpenSSL code. Is there any way to get NID without changing OpenSSL? Kind regards, Kris
Re: Digest algorithms for Ruby
Thanks everyone, your replies were most helpful. On Sat, 2 Nov 2019 at 06:42, Jordan Brown wrote: > On 10/31/2019 7:35 AM, Viktor Dukhovni wrote: > > My advice would be to avoid specific support for any *particular* digest > algorithm. Instead, provide bindings to: > > - EVP_get_digestbyname(), > - EVP_MD_CTX_create(3), > - EVP_DigestInit_ex(3), > - EVP_DigestUpdate(3), > - EVP_DigestFinal_ex(3), > - EVP_MD_CTX_destroy(3) > > which can they use *any* available digest algorithm (by name). > > > That avoids having *your* software be dependent on the digest algorithms, > but it does so by exporting the dependency out to your caller. > > The bottom line for somebody trying to maintain compatibility is that when > you remove some algorithm X, there's always a risk that something in the > stack - be it software or user configuration - explicitly depends on X and > so will fail on upgrade. > > -- > Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris > >
Re: Digest algorithms for Ruby
On 10/31/2019 7:35 AM, Viktor Dukhovni wrote: > My advice would be to avoid specific support for any *particular* > digest algorithm. Instead, provide bindings to: > - EVP_get_digestbyname(), > - EVP_MD_CTX_create(3), > - EVP_DigestInit_ex(3), > - EVP_DigestUpdate(3), > - EVP_DigestFinal_ex(3), > - EVP_MD_CTX_destroy(3) > > which can they use *any* available digest algorithm (by name). > That avoids having *your* software be dependent on the digest algorithms, but it does so by exporting the dependency out to your caller. The bottom line for somebody trying to maintain compatibility is that when you remove some algorithm X, there's always a risk that something in the stack - be it software or user configuration - explicitly depends on X and so will fail on upgrade. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
Re: Digest algorithms for Ruby
On 31/10/2019 11:59, Samuel Williams wrote:
> I am maintaining the OpenSSL bindings for Ruby, and I'm considering
> exposing SHA3 and BLAKE digests.
>
> In addition, for the first time, I wrote some tests to test ALL
> algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer
> exist.
>
> I'm going to assume this algorithm is removed because it's old and/or
> insecure. But I would like to seek some clarification on this because it
> represents a breaking change in semantic versioning, to the extent that
> we exposed these digests explicitly.
>
> So:
>
> - Did they exist?
Yes, they did exist. EVP_sha() (aka SHA0) and EVP_dss() (aka DSS0) were
removed by commit 474e469bb. It had this commit description:
commit 474e469bbd056aebcf7e7d3207ef820f2faed4ce
Author: Rich Salz
AuthorDate: Tue Jan 27 12:34:45 2015 -0500
Commit: Rich Salz
CommitDate: Tue Jan 27 12:34:45 2015 -0500
OPENSSL_NO_xxx cleanup: SHA
Remove support for SHA0 and DSS0 (they were broken), and remove
the ability to attempt to build without SHA (it didn't work).
For simplicity, remove the option of not building various SHA
algorithms;
you could argue that SHA_224/256/384/512 should be kept, since they're
like crypto algorithms, but I decided to go the other way.
So these options are gone:
GENUINE_DSA OPENSSL_NO_SHA0
OPENSSL_NO_SHA OPENSSL_NO_SHA1
OPENSSL_NO_SHA224 OPENSSL_NO_SHA256
OPENSSL_NO_SHA384 OPENSSL_NO_SHA512
Reviewed-by: Richard Levitte
EVP_dss1() was removed by commit 7f572e958b with this commit description:
commit 7f572e958b13041056f377a62d3219633cfb1e8a
Author: Dr. Stephen Henson
AuthorDate: Wed Dec 2 13:57:04 2015 +
Commit: Dr. Stephen Henson
CommitDate: Wed Dec 2 17:52:01 2015 +
Remove legacy sign/verify from EVP_MD.
Remove sign/verify and required_pkey_type fields of EVP_MD: these are a
legacy from when digests were linked to public key types. All signing is
now handled by the corresponding EVP_PKEY_METHOD.
Only allow supported digest types in RSA EVP_PKEY_METHOD: other
algorithms
already block unsupported types.
Remove now obsolete EVP_dss1() and EVP_ecdsa().
Reviewed-by: Richard Levitte
> - When did they stop existing?
The first release that contained the above commits was OpenSSL 1.1.0.
That was a major release that did not claim backwards source
compatibility. Most notably because of the structures becoming opaque,
but it did impact some other areas too.
> - Are they still relevant?
Since 1.1.0 has been around for nearly 4 years now, and this is the
first time I recall anyone ever noticing this, I would say "No".
Re: Digest algorithms for Ruby
> On Oct 31, 2019, at 7:59 AM, Samuel Williams > wrote: > > I am maintaining the OpenSSL bindings for Ruby, and I'm considering exposing > SHA3 and BLAKE digests. > > In addition, for the first time, I wrote some tests to test ALL algorithms we > expose, and found that "DSS", "DSS1" and "SHA" no longer exist. > > I'm going to assume this algorithm is removed because it's old and/or > insecure. But I would like to seek some clarification on this because it > represents a breaking change in semantic versioning, to the extent that we > exposed these digests explicitly. My advice would be to avoid specific support for any *particular* digest algorithm. Instead, provide bindings to: - EVP_get_digestbyname(), - EVP_MD_CTX_create(3), - EVP_DigestInit_ex(3), - EVP_DigestUpdate(3), - EVP_DigestFinal_ex(3), - EVP_MD_CTX_destroy(3) which can they use *any* available digest algorithm (by name). -- Viktor.
Digest algorithms for Ruby
I am maintaining the OpenSSL bindings for Ruby, and I'm considering exposing SHA3 and BLAKE digests. In addition, for the first time, I wrote some tests to test ALL algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer exist. I'm going to assume this algorithm is removed because it's old and/or insecure. But I would like to seek some clarification on this because it represents a breaking change in semantic versioning, to the extent that we exposed these digests explicitly. So: - Did they exist? - When did they stop existing? - Are they still relevant? Kind regards, Samuel.
Re: new algorithms
HI Giovanni Depending on the country you are located in, you may need to check the current status of your countries regulatory legislation regarding encryption technologies. Participating countries : https://www.wassenaar.org/participating-states/ <https://www.wassenaar.org/participating-states/> [ contacts ] & encryption is listed under Dual List Technologies : https://www.wassenaar.org/ <https://www.wassenaar.org/> is always a good place to start before drilling into your own locations specific regulations on encryption technologies. All the best mate and hoping your invention prospers. -- Regards, Mark A. Lane © Mark A. Lane 1980 - 2019, All Rights Reserved. © FooCrypt 1980 - 2019, All Rights Reserved. © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved. © Cryptopocalypse 1980 - 2019, All Rights Reserved. > On 9 Apr 2019, at 03:50, Giovanni Fontana > wrote: > > Thank you every one for the answers and tips, really a great and active group! > > Thank you also to Teja and Tobias who has just wrote some suggestion on how I > can have a technical shortcut to prove the functionality of my algorithms in > very limited environment. > What I asked is to move a first step (after the algorithms) to have a demo > before to setup a company. > For my limited knowledge I know the algorithms need to be published and > security must be proved for some authorities. All I need to prove is the > algorithms works in the real world and openSSL is one of the most used tool > to do that, then the other steps > > Thank you again for your answer, this is what I really need. > > Giovanni > > > > Il giorno lun 8 apr 2019 alle ore 19:23 Teja Prabhu <213...@gmail.com > <mailto:213...@gmail.com>> ha scritto: > 1. dasync_aes128_cbc_cipher (search for this in > https://github.com/openssl/openssl/blob/master/engines/e_dasync.c > <https://github.com/openssl/openssl/blob/master/engines/e_dasync.c>) || > replace it with your symmetric cipher, and do the same for RSA. > 2. setup a server and client and hard-code the symmetric & asymmetric ciphers > to your ciphers > 3. your idea is simply not going to work. Like Tobias said, you have to add > them manually. I suggest you simply not use OpenSSL or any TLS library, > unless you have a lot of clout in the International Communication Union. > > You can take Mega's approach and use javascript since every browser under the > sun has it (as an additional layer over TLS). > > Teja Prabhu > > > On Mon, Apr 8, 2019 at 7:06 PM Tobias Nießen <mailto:tnies...@tnie.de>> wrote: > > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL > > connection always with algo1 and algo2 > As far as I know, you will need to have an OID assigned for each > algorithm for x509 certificates. You can add those to OpenSSL manually, > but you won't be able to communicate with any other software that does > not implement them. (And as Rich said, there is little reason for people > to trust and use non-standard algorithms.)
Re: new algorithms
>> creation of x509 certificate with algo1 and algo2, and/or TLS and SSL >> connection always with algo1 and algo2 Tobias Nießen wrote: > As far as I know, you will need to have an OID assigned for each > algorithm for x509 certificates. You can add those to OpenSSL manually, > but you won't be able to communicate with any other software that does > not implement them. (And as Rich said, there is little reason for > people to trust and use non-standard algorithms.) But, if your goal is private testing of your stuff, then any OID will do, including one you allocate with a Private Enterprise Number, which you can get from IANA by filling out a simple form. You'll likely have to add the OIDs to the object.txt and run some scripts. -- ] 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: new algorithms
Thank you every one for the answers and tips, really a great and active group! Thank you also to Teja and Tobias who has just wrote some suggestion on how I can have a technical shortcut to prove the functionality of my algorithms in very limited environment. What I asked is to move a first step (after the algorithms) to have a demo before to setup a company. For my limited knowledge I know the algorithms need to be published and security must be proved for some authorities. All I need to prove is the algorithms works in the real world and openSSL is one of the most used tool to do that, then the other steps Thank you again for your answer, this is what I really need. Giovanni Il giorno lun 8 apr 2019 alle ore 19:23 Teja Prabhu <213...@gmail.com> ha scritto: > 1. dasync_aes128_cbc_cipher (search for this in > https://github.com/openssl/openssl/blob/master/engines/e_dasync.c) || > replace it with your symmetric cipher, and do the same for RSA. > 2. setup a server and client and hard-code the symmetric & asymmetric > ciphers to your ciphers > 3. your idea is simply not going to work. Like Tobias said, you have to > add them manually. I suggest you simply not use OpenSSL or any TLS library, > unless you have a lot of clout in the International Communication Union. > > You can take Mega's approach and use javascript since every browser under > the sun has it (as an additional layer over TLS). > > Teja Prabhu > > > On Mon, Apr 8, 2019 at 7:06 PM Tobias Nießen wrote: > >> > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL >> > connection always with algo1 and algo2 >> As far as I know, you will need to have an OID assigned for each >> algorithm for x509 certificates. You can add those to OpenSSL manually, >> but you won't be able to communicate with any other software that does >> not implement them. (And as Rich said, there is little reason for people >> to trust and use non-standard algorithms.) >> >
Re: new algorithms
1. dasync_aes128_cbc_cipher (search for this in https://github.com/openssl/openssl/blob/master/engines/e_dasync.c) || replace it with your symmetric cipher, and do the same for RSA. 2. setup a server and client and hard-code the symmetric & asymmetric ciphers to your ciphers 3. your idea is simply not going to work. Like Tobias said, you have to add them manually. I suggest you simply not use OpenSSL or any TLS library, unless you have a lot of clout in the International Communication Union. You can take Mega's approach and use javascript since every browser under the sun has it (as an additional layer over TLS). Teja Prabhu On Mon, Apr 8, 2019 at 7:06 PM Tobias Nießen wrote: > > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL > > connection always with algo1 and algo2 > As far as I know, you will need to have an OID assigned for each > algorithm for x509 certificates. You can add those to OpenSSL manually, > but you won't be able to communicate with any other software that does > not implement them. (And as Rich said, there is little reason for people > to trust and use non-standard algorithms.) >
Re: new algorithms
creation of x509 certificate with algo1 and algo2, and/or TLS and SSL connection always with algo1 and algo2 As far as I know, you will need to have an OID assigned for each algorithm for x509 certificates. You can add those to OpenSSL manually, but you won't be able to communicate with any other software that does not implement them. (And as Rich said, there is little reason for people to trust and use non-standard algorithms.)
Re: new algorithms
* Sure, I want to publish the algorithm, but not yet... waiting for establishing a company. This is a bit off-topic, but trying to make money from a cryptographic algorithm isn’t really done any more. RSA was locked up by patents, and there were some elliptic curve patents that have since expired, but nobody really trusts private algorithms any more. There’s too much good stuff readily available. To answer your other question: OpenSSL is covered by the Apache license and any contributions should also use the same license or they will not be accepted. And cryptography, in particular, has to be used by a recognized standards body. Good luck.
Re: new algorithms
On Mon, Apr 08, 2019 at 05:48:56PM +0200, Giovanni Fontana wrote: > my name is Giovanni Fontana. I made a new symmetric crypto algorithm (let’s > call it *algo1*) and a new asymmetric crypto algorithm (let’s call it > *algo2*). Recent additions to OpenSSL include X25519, Ed25519 and ChaCha20. If, for some reason, you believe that an important security problem we're facing is an insufficient number of available algorithms, you can study how these recent algorithms are integrated into OpenSSL generally, X.509, CMS and TLS, and integrate your algorithms in a similar manner. You might also take a look at the OpenSSL master (3.0) development branch, which introduces changes to the internal architecture that are intended to better facilitate integration of external cryptographic modules. -- Viktor.
Re: new algorithms
Hi Clarke, Thanks for the email. Sure, I want to publish the algorithm, but not yet... waiting for establishing a company. For similar reasons no github usage at moment. Giovanni Il giorno lun 8 apr 2019 alle 18:06 Dennis Clarke ha scritto: > On 4/8/19 11:48 AM, Giovanni Fontana wrote: > > Hello everybody, > > > > my name is Giovanni Fontana. I made a new symmetric crypto algorithm > > (let’s call it *algo1*) and a new asymmetric crypto algorithm (let’s > > call it *algo2*). > > > > I use algo2 for key exchange and with that I can create a session key to > > cipher and decipher with algo1, so Alice and Bob can communicate each > > other in secure way. > > I think you would need to publish the algorithm at some point. Is there > a github link perhaps? > > Dennis > > >
Re: new algorithms
On 4/8/19 11:48 AM, Giovanni Fontana wrote: > Hello everybody, > > my name is Giovanni Fontana. I made a new symmetric crypto algorithm > (let’s call it *algo1*) and a new asymmetric crypto algorithm (let’s > call it *algo2*). > > I use algo2 for key exchange and with that I can create a session key to > cipher and decipher with algo1, so Alice and Bob can communicate each > other in secure way. I think you would need to publish the algorithm at some point. Is there a github link perhaps? Dennis
new algorithms
Hello everybody, my name is Giovanni Fontana. I made a new symmetric crypto algorithm (let’s call it *algo1*) and a new asymmetric crypto algorithm (let’s call it *algo2*). I use algo2 for key exchange and with that I can create a session key to cipher and decipher with algo1, so Alice and Bob can communicate each other in secure way. I wish to import those algorithms inside OpenSSL in order to use some features of this suite (i.e. creation of x509 certificate with algo1 and algo2, and/or TLS and SSL connection always with algo1 and algo2). My first tries were not successful. Could you please tell me each step I have to do in order to achieve my targets? Or share with me some Internet links where those steps are already defined? Below some info that may help you in answer me: - The version of OpenSSL I’m playing with is 1.1.1b - The OS is Linux Ubuntu 14.04 - Of course my algorithms are written in C. Further question (probably to ask elsewhere inside OpenSSL organisation): If in the next future with my algorithms I can have some business, which kind of license I need to have with OpenSSL then? Thank in advance Kind regards
[openssl-users] How to select supported signature algorithms
Hello, I am developing a simple client/server application with openSSL. Using wireshark, I can see in the Client Hello message that there is an extension signature_algorithms, in which are fields Signature Hash Algorithms. I can see a lot of supported algorithms, such as RSA, DSA, ECDSA in the fields *Signature Hash Algorithm Signature* ,and SHA1, SHA256, MD5, ... for *Signature Hash Algorithm Hash*. The same behavior happens in the Server Key Exchange message. My question is: how can I restrict this list of algorithms to use only one? Note that I am already using the function set_cipher_list(), and as a consequence, the field *Cipher Suites* in those messages only contains the suite I want to use. So I don't know what is the API function to use instead of ssl_ctx_set_cipher_list(). I didn't find anything in the documentation. Thank you for your help, Jack ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to select supported signature algorithms
On Mon, Mar 16, 2015, Jacques FLORENCE wrote: Hello, I am developing a simple client/server application with openSSL. Using wireshark, I can see in the Client Hello message that there is an extension signature_algorithms, in which are fields Signature Hash Algorithms. I can see a lot of supported algorithms, such as RSA, DSA, ECDSA in the fields *Signature Hash Algorithm Signature* ,and SHA1, SHA256, MD5, ... for *Signature Hash Algorithm Hash*. The same behavior happens in the Server Key Exchange message. My question is: how can I restrict this list of algorithms to use only one? Note that I am already using the function set_cipher_list(), and as a consequence, the field *Cipher Suites* in those messages only contains the suite I want to use. So I don't know what is the API function to use instead of ssl_ctx_set_cipher_list(). I didn't find anything in the documentation. You need OpenSSL 1.0.2 to set a custom supported signature algorithms extension. You can use the macro SSL_CTX_set1_sigalgs_list(ctx, sigstring) where sigstring has the format of SignatureAlgorithms documented at: https://www.openssl.org/docs/ssl/SSL_CONF_cmd.html For example SSL_CTX_set1_sigalgs_list(ctx, RSA+SHA256); For the signature algorithm associated with client authentication you use SSL_CTX_set1_client_sigalgs_list instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
BN_GF2m algorithms
Hey. Can I somehow know which algorithms are used in functions BN_GF2m_* For example Montgomery reduction, Barrett reduction or something else for BN_GF2m_mod_arr function.
RE: SSL/TLS encryption algorithms
From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Friday, November 01, 2013 18:12 snip: differences between $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 $ openssl ciphers -v AES128-SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 Does your application need to perform faster, offer forward-secrecy, be most interoperable, ... ? these was the result of using 2 different browsers with the same SSL website ... (1) an old firefox (2) the latest IE - IE11 on Win 8.1 Different browsers (or sometimes versions) offer different lists of supported cipher suites, in different orders. In some cases the same browser can be reconfigured to offer different suites; Firefox in particular can do this in about:config. I don't know about Windows/IE but it wouldn't surprise me at all if there's a registry hack. Some servers, and particularly OpenSSL and thus Apache by default (unless you configure HonorCipherOrder), will agree the first suite in client preference order that the server supports. In practice this tends to be the first one, or in the first few, of the client preferences. Firefox is the only client I know that prefers Camellia to AES at same strength, and thus tends to get a Camellia suite from a server that supports them, as OpenSSL and thus Apache do unless disabled. https://ssl.mathemainzel.info/info/ you can try your browser ... how would I define forward-secrecy on Apache webserver? If the server negotiated both ciphers, it already supports forward-secrecy (aka PFS) if the client does too. Not necessarily. In principle either end could implement and be configured to support each PFS suite individually; even if both ends support some PFS suite or suites, they may not intersect and allow actual PFS session. In practice this mostly breaks down by authkx; there would be no sensible reason to exclude an implementable suite that is otherwise strong enough. In particular IE/Windows through the latest I have (IE9/Seven) supports DHE-DSS but not DHE-RSA. If an OpenSSL server has RSA keycert, and dh_tmp but not ecdh_tmp params, it supports DHE-RSA but not DHE-DSS. That means both ends support PFS, but they still can't negotiate it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
On 01.11.2013 23:12, Viktor Dukhovni wrote: $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 $ openssl ciphers -v AES128-SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 Does your application need to perform faster, offer forward-secrecy, be most interoperable, ... ? these was the result of using 2 different browsers with the same SSL website ... (1) an old firefox (2) the latest IE - IE11 on Win 8.1 https://ssl.mathemainzel.info/info/ you can try your browser ... how would I define forward-secrecy on Apache webserver? If the server negotiated both ciphers, it already supports forward-secrecy (aka PFS) if the client does too. What about a browser that shows this SSL_CIPHER=RC4-MD5 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 SSL_COMPRESS_METHOD=NULL SSL_PROTOCOL=TLSv1 SSL_SECURE_RENEG=true Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
On Sun, Nov 03, 2013 at 06:18:38PM +0100, Walter H. wrote: how would I define forward-secrecy on Apache webserver? If the server negotiated both ciphers, it already supports forward-secrecy (aka PFS) if the client does too. What about a browser that shows this SSL_CIPHER=RC4-MD5 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 SSL_COMPRESS_METHOD=NULL SSL_PROTOCOL=TLSv1 SSL_SECURE_RENEG=true Your server supports PFS, some browsers don't. Or prefer non-PFS cipher-suites to PFS. Default settings of OpenSSL 1.0.0 or later have sensibly ordered ciphersuites. Sufficiently recent versions of Apache enable EDH/EECDH (aka PFS) cipher-suites by setting appropriate parameters ((p,g) pairs or named curves). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
On 03.11.2013 18:27, Viktor Dukhovni wrote: On Sun, Nov 03, 2013 at 06:18:38PM +0100, Walter H. wrote: how would I define forward-secrecy on Apache webserver? If the server negotiated both ciphers, it already supports forward-secrecy (aka PFS) if the client does too. What about a browser that shows this SSL_CIPHER=RC4-MD5 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 SSL_COMPRESS_METHOD=NULL SSL_PROTOCOL=TLSv1 SSL_SECURE_RENEG=true Your server supports PFS, some browsers don't. Or prefer non-PFS cipher-suites to PFS. Default settings of OpenSSL 1.0.0 or later have sensibly ordered ciphersuites. Sufficiently recent versions of Apache enable EDH/EECDH (aka PFS) cipher-suites by setting appropriate parameters ((p,g) pairs or named curves). Ok, I understand; how good is this encryption in comparison to the other two I mentioned before? what does SSL_SECURE_RENEG say to me? some browsers show true, some show false ... Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL/TLS encryption algorithms
Hello, Which one of the following two is better (1) or (2)? (1) SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA SSL_CIPHER_ALGKEYSIZE=256 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=256 SSL_COMPRESS_METHOD=NULL SSL_PROTOCOL=TLSv1 SSL_SECURE_RENEG=true (2) SSL_CIPHER=AES128-SHA256 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 SSL_COMPRESS_METHOD=NULL SSL_PROTOCOL=TLSv1.2 SSL_SECURE_RENEG=true Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
On Fri, Nov 01, 2013 at 09:56:10PM +0100, Walter H. wrote: Which one of the following two is better (1) or (2)? (1) SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 (2) SSL_CIPHER=AES128-SHA256 $ openssl ciphers -v AES128-SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 They're both fine. Your question has no answer, except that neither is known to be weak enough that you should avoid it. The latter requires OpenSSL 1.0.1 which (IIRC) introduces support for TLSv1.2. - These are available at different minimum protocol versions. - These use different bulk crypt algorithms - At different key lengths - With different key exchange algorithms. Does your application need to perform faster, offer forward-secrecy, be most interoperable, ... ? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
Hello, On 01.11.2013 22:34, Viktor Dukhovni wrote: On Fri, Nov 01, 2013 at 09:56:10PM +0100, Walter H. wrote: Which one of the following two is better (1) or (2)? (1) SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 (2) SSL_CIPHER=AES128-SHA256 $ openssl ciphers -v AES128-SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 They're both fine. Does your application need to perform faster, offer forward-secrecy, be most interoperable, ... ? these was the result of using 2 different browsers with the same SSL website ... (1) an old firefox (2) the latest IE - IE11 on Win 8.1 https://ssl.mathemainzel.info/info/ you can try your browser ... how would I define forward-secrecy on Apache webserver? Thanks, Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS encryption algorithms
$ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 $ openssl ciphers -v AES128-SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 Does your application need to perform faster, offer forward-secrecy, be most interoperable, ... ? these was the result of using 2 different browsers with the same SSL website ... (1) an old firefox (2) the latest IE - IE11 on Win 8.1 https://ssl.mathemainzel.info/info/ you can try your browser ... how would I define forward-secrecy on Apache webserver? If the server negotiated both ciphers, it already supports forward-secrecy (aka PFS) if the client does too. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
List of available digest algorithms
OBJ_sn2nid() doesn't contain the full list of supported digest methods. How can I find this list using the library? I cannot fork/exec 'openssl list-digest-algorithms' and crack the output as a solution. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Encumbered EC crypto algorithms in openssl?
On 08/16/2013 08:02 PM, Michael Sierchio wrote: On Fri, Aug 16, 2013 at 10:40 PM, Nico Williams n...@cryptonector.com mailto:n...@cryptonector.com wrote: If only we could agree to use DJB's Curve25519... +1 That's actually a handy reference, for in looking at Curve25519, I came across... http://cr.yp.to/ecdh/patents.html It helps. :) Should I have brought this up with the developers, instead? -- -Scott Doty Co-founder, Co-owner, CTO: Sonic.net, Inc.
Re: Encumbered EC crypto algorithms in openssl?
On Sat, Aug 17, 2013 at 8:49 PM, Scott Doty scott+open...@sonic.net wrote: That's actually a handy reference, for in looking at Curve25519, I came across... http://cr.yp.to/ecdh/patents.html That's half the point, yes. It'd be all of the point if Curve25519 didn't also rock perf-wise. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Encumbered EC crypto algorithms in openssl?
Hello, As you may or may not know, Red Hat has vetoed use of ECC in openssl in their stock Fedora. The bug regarding this is here: https://bugzilla.redhat.com/show_bug.cgi?id=319901 https://bugzilla.redhat.com/show_bug.cgi?id=319901 In a nutshell: Red Hat is so afraid of patent trolls, they don't want to enable ECC -- or even discuss the IP issues publically. (And who can blame them? Legislative relief is definitely needed here -- so far, it hasn't been enough. But I digress...) I see some references to standards in the sources for crypto/ec*, such as ANSI X9.62 and IEEE 1363. However, I'm not sure that that list is inclusive -- and I certainly wouldn't be able to recognize whose algorithm was being used by inspecting C code. So I'm hoping for some help with this, to allay Red Hat's fears of patent trolls. Toward this goal, there is an informational RFC 6090 that outlines how to implement ECC without patent encumbrance. I'm wondering if we can safely say that openssl's ECC is implemented in a way compatible with RFC 6090 -- or at least, in a way that enabling it on Red Hat software wouldn't open them up to a patent troll flawsuit? http://www.rfc-editor.org/rfc/rfc6090.txt I checked the FAQ, and it does reference the README regarding patents. However, it doesn't specifically mention ECC, and that would seem to be the sticking point with Red Hat. With more and more software systems requiring ECC to operate, I See A Great Need in getting this resolved. Thank you for any information you can provide. Also, if this belongs on the dev list, my apologies for coming here first. -- -Scott Doty Co-founder, Co-owner, CTO: Sonic.net, Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Encumbered EC crypto algorithms in openssl?
If only we could agree to use DJB's Curve25519... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Encumbered EC crypto algorithms in openssl?
On Fri, Aug 16, 2013 at 10:40 PM, Nico Williams n...@cryptonector.comwrote: If only we could agree to use DJB's Curve25519... +1
Re: KDF algorithms
Thanks so much for answering my question, Matthew. -- View this message in context: http://openssl.6102.n7.nabble.com/KDF-algorithms-tp45762p45779.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
KDF algorithms
Hi All, I am working on a product using Certicom KDF function. In fact, we use HU_KDF_IEEE_KDF1_SHA1 and HU_KDF_ANSI_SHA256 only. The function hu_KDFDerive() has an argument specifying which KDF algorithm to use to compute a cryptographic key. This is referred to as a key derivation algorithm ID. The following constants are defined in hukdf.h: • HU_KDF_IEEE_KDF1_SHA1 (IEEE 1363-2000 KDF1 based on SHA-1) • HU_KDF_ANSI_SHA1 (ANSI X9.42/X9.63 KDF based on SHA-1) • HU_KDF_ANSI_SHA224 (ANSI X9.42/X9.63 KDF based on SHA-224) • HU_KDF_ANSI_SHA256 (ANSI X9.42/X9.63 KDF based on SHA-256) • HU_KDF_ANSI_SHA384 (ANSI X9.42/X9.63 KDF based on SHA-384) • HU_KDF_ANSI_SHA512 (ANSI X9.42/X9.63 KDF based on SHA-512) • HU_KDF_NIST_ALT1_SHA1 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA224 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA256 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA384 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA512 (SP 800-56A) Now my company is going to use OpenSSL instead. I checked OpenSSL and it seems to me that OpenSSL doesn't support these KDF algorithms. My question is - is there any way to implement these algorithms in OpenSSL? Thanks so much in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/KDF-algorithms-tp45762.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: KDF algorithms
Ansi X9.63 is pretty trivial to implement using the OpenSSL libraries - less than a days work. The algorithm is defined in SEC1 §3.6.1.http://www.secg.org/collateral/sec1.pdf From memory, the main logic was only around 50LOC, with another 50-100LOC wrapping various library calls. There's not much to it. Matthew On 3 July 2013 18:28, Aaron wang...@alumni.nus.edu.sg wrote: Hi All, I am working on a product using Certicom KDF function. In fact, we use HU_KDF_IEEE_KDF1_SHA1 and HU_KDF_ANSI_SHA256 only. The function hu_KDFDerive() has an argument specifying which KDF algorithm to use to compute a cryptographic key. This is referred to as a key derivation algorithm ID. The following constants are defined in hukdf.h: • HU_KDF_IEEE_KDF1_SHA1 (IEEE 1363-2000 KDF1 based on SHA-1) • HU_KDF_ANSI_SHA1 (ANSI X9.42/X9.63 KDF based on SHA-1) • HU_KDF_ANSI_SHA224 (ANSI X9.42/X9.63 KDF based on SHA-224) • HU_KDF_ANSI_SHA256 (ANSI X9.42/X9.63 KDF based on SHA-256) • HU_KDF_ANSI_SHA384 (ANSI X9.42/X9.63 KDF based on SHA-384) • HU_KDF_ANSI_SHA512 (ANSI X9.42/X9.63 KDF based on SHA-512) • HU_KDF_NIST_ALT1_SHA1 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA224 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA256 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA384 (SP 800-56A) • HU_KDF_NIST_ALT1_SHA512 (SP 800-56A) Now my company is going to use OpenSSL instead. I checked OpenSSL and it seems to me that OpenSSL doesn't support these KDF algorithms. My question is - is there any way to implement these algorithms in OpenSSL? Thanks so much in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/KDF-algorithms-tp45762.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Fwd: [openssl-users] OpenSSL: RC4 and IDEA algorithms
Thanks for information. just confirmation: In OpenSSL 0.98x, is RC5 and Camellia disabled in Configure file ? *code* # All of the following is disabled by default (RC5 was enabled before 0.9.8): my %disabled = ( # what = comment [or special keyword experimental] camellia = default, ~~ mdc2 = default, rc5= default, ~~ ~~ rfc3779= default, Regards, Sarju On Thu, Jan 24, 2013 at 12:18 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: Camellia is freely available on several licenses (BSD, GPL, MPL). IDEA's patent has expired (2011 un Europe, 2012 in Japan+USA). RC4 is an RSA trademark, no patent has been asked on the algorithm itself__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] OpenSSL: RC4 and IDEA algorithms
Camellia is freely available on several licenses (BSD, GPL, MPL). IDEA's patent has expired (2011 un Europe, 2012 in Japan+USA). RC4 is an RSA trademark, no patent has been asked on the algorithm itself. RC5 is still patented, by RSA. -- Erwann ABALEA - aquadiemoctus: aujourd'hui (oui, je sais, celui-là est particulièrement capillotracté) Le 23/01/2013 17:36, sarju tambe a écrit : In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. Thanks, Sarju __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL: RC4 and IDEA algorithms
RC4 is not patented - RC4 is a Trademark of RSA Security. On Wed, Jan 23, 2013 at 8:36 AM, sarju tambe sarjuta...@gmail.com wrote: In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL: RC4 and IDEA algorithms
(I am not a lawyer, this is not legal advise) On 1/23/2013 5:36 PM, sarju tambe wrote: In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. Because OpenSSL 0.9.8 is old, the information in that README file is no longer up to date. The IDEA patent expired no later than January 7, 2012. No patent license is needed anymore. (IDEA NXT is a different algorithm not in OpenSSL). The date is from Wikipedia, feel free to check other sources yourself. As for ARCFOUR, I don't think it has any legal protection anymore. It used to be a trade secret of RSADSI, but someone (not me and probably not you) leaked the secret to the general public and it has been freely discussed ever since. Wikipedia even alleges that the inventor of the algorithm (Ron Rivest, whose name is the R in both RC4 and RSA) has even publicly referenced the copy of the leaked information included on the Wikipedia page itself. Thus the trade secret protection of ARCFOUR should be gone by now and I think (I am not a lawyer, this is not legal advise) that the only people RSADSI can now sue over ARCFOUR would be the person or persons who leaked the description years ago, possibly violating an NDA contract clause. There may also be trade mark for the specific name RC4, which is why many people refer to it by alternate names. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL: RC4 and IDEA algorithms
I also have questions about this issue. Am I correct in saying that IDEA, which is a patented algorithm, has legal restrictions from our implementing it in a commercial solution of any kind without first getting permissions from Ascom representatives. However, making use of OpenSSL to decrypt a message encrypted with IDEA would not require obtaining legal permissions when it falls within a context of personal use? For instance, if someone with rights to use IDEA sent me a personal message encrypted with it, there are no legal restrictions preventing me from making use of OpenSSL to decrypt said message. Does that sound right? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of sarju tambe Sent: Wednesday, January 23, 2013 10:36 AM To: openssl-users@openssl.org Subject: OpenSSL: RC4 and IDEA algorithms In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. Thanks, Sarju __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL: RC4 and IDEA algorithms
On Wed, Jan 23, 2013 at 3:02 PM, John A. Wallace jw72...@verizon.net wrote: I also have questions about this issue. Am I correct in saying that IDEA, which is a patented algorithm, has legal restrictions from our implementing I believe IDEA is no longer encumbered in the US. I seem to recall it expired around 2010 or so. Plus, there are modern algorithms with improved designs, faster speeds, and better security. There's no need to live 20 years in the past. With improved cipher's, there's no need to waste time with that sales department either (I actually spent some time trying to acquire licenses from them back in 2000 or so). Any particular reason you want to use IDEA in production? Jeff -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of sarju tambe Sent: Wednesday, January 23, 2013 10:36 AM To: openssl-users@openssl.org Subject: OpenSSL: RC4 and IDEA algorithms In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL: RC4 and IDEA algorithms
Sorry for the confusion. I have no desire to use IDEA for encryption. Conversely, my interest was purely in the legitimacy of using it for decryption in case I were sent a message encrypted with it. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Wednesday, January 23, 2013 7:27 PM To: openssl-users@openssl.org Subject: Re: OpenSSL: RC4 and IDEA algorithms On Wed, Jan 23, 2013 at 3:02 PM, John A. Wallace jw72...@verizon.net wrote: I also have questions about this issue. Am I correct in saying that IDEA, which is a patented algorithm, has legal restrictions from our implementing I believe IDEA is no longer encumbered in the US. I seem to recall it expired around 2010 or so. Plus, there are modern algorithms with improved designs, faster speeds, and better security. There's no need to live 20 years in the past. With improved cipher's, there's no need to waste time with that sales department either (I actually spent some time trying to acquire licenses from them back in 2000 or so). Any particular reason you want to use IDEA in production? Jeff -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of sarju tambe Sent: Wednesday, January 23, 2013 10:36 AM To: openssl-users@openssl.org Subject: OpenSSL: RC4 and IDEA algorithms In OpenSSL(README File, openssl version-0.98x), there are 4 patented algorithms RC5, RC4, IDEA, Camellia out of which RC5 and Camellia are disabled in Configure file. In README file, for RC4 we need to take RSA Security's permission. IDEA algorithm is patented by Ascom and they should be contacted if that algorithm is to be used. Here I have queries: 1. In OpenSSL RC4 and IDEA are not disable so do we need to take separate permission to use them? if yes, then do you have any idea as to how to get the permission? please correct me if i am wrong. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to disable non-FIPS approved algorithms - DH and RAND_bytes?
Hi, I have an application which uses RSA or Diffie Hellman (DH) algorithms for key exchange and RAND_seed and RAND_bytes to generate pseudo random number. Now, I have added FIPS_mode_set(1) to enable FIPS. As per openSSL-fips security policy document, my expectation is DH and RAND_seed and RAND_bytesfunction should not be loaded in FIPS mode. However, these functions are loaded and still working fine even in FIPS mode. Is this expected behaviour? If I want to disable all the non FIPS approved algorithms what is the best practice? I am consuming openSSL-fips-1.2.0 and openSSL-9.8r. Thanks, ~Vimol
Re: How to disable non-FIPS approved algorithms - DH and RAND_bytes?
On Mon, Jan 23, 2012, Vimol Kshetrimayum wrote: Hi, I have an application which uses RSA or Diffie Hellman (DH) algorithms for key exchange and RAND_seed and RAND_bytes to generate pseudo random number. Now, I have added FIPS_mode_set(1) to enable FIPS. As per openSSL-fips security policy document, my expectation is DH and RAND_seed and RAND_bytesfunction should not be loaded in FIPS mode. However, these functions are loaded and still working fine even in FIPS mode. Is this expected behaviour? If I want to disable all the non FIPS approved algorithms what is the best practice? I am consuming openSSL-fips-1.2.0 and openSSL-9.8r. When FIPS mode is enabled the RAND functions are redirected to an FIPS approved PRNG. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to disable non-FIPS approved algorithms - DH and RAND_bytes?
Thanks Steve. So, that means, I don't need to add FIPS_rand_* function. For DH key exchange algorithm, do I need to explicitly disable calling of DH function in my code if it is in FIPS? Or is there any DH algorithms loading issue in openssl-fips-1.2 that I am consuming? Thanks, ~Vimol On Mon, Jan 23, 2012 at 10:21 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Mon, Jan 23, 2012, Vimol Kshetrimayum wrote: Hi, I have an application which uses RSA or Diffie Hellman (DH) algorithms for key exchange and RAND_seed and RAND_bytes to generate pseudo random number. Now, I have added FIPS_mode_set(1) to enable FIPS. As per openSSL-fips security policy document, my expectation is DH and RAND_seed and RAND_bytesfunction should not be loaded in FIPS mode. However, these functions are loaded and still working fine even in FIPS mode. Is this expected behaviour? If I want to disable all the non FIPS approved algorithms what is the best practice? I am consuming openSSL-fips-1.2.0 and openSSL-9.8r. When FIPS mode is enabled the RAND functions are redirected to an FIPS approved PRNG. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
cryptographic algorithms
Hello, Please list all encryption algorithms supported by OpenSSL 0.9.8e, 0.9.8m and 1.0.0d. It looks like that http://www.openssl.org/docs/crypto/crypto.html has not been updated for a while and does not list ECC and possibly some other algorithms. Thank you, Alona
Re: cryptographic algorithms
On Thu, May 05, 2011 at 02:29:07PM -0400, Alona Rossen wrote: Please list all encryption algorithms supported by OpenSSL 0.9.8e, 0.9.8m and 1.0.0d. To list all ciphers $ openssl ciphers -v ALL:eNULL:@STRENGTH just use the appropriate openssl(1) binary to find which ciphers are supported by which release. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cryptographic algorithms
On Thu, May 05, 2011, Alona Rossen wrote: Hello, Please list all encryption algorithms supported by OpenSSL 0.9.8e, 0.9.8m and 1.0.0d. It looks like that http://www.openssl.org/docs/crypto/crypto.html has not been updated for a while and does not list ECC and possibly some other algorithms. openssl list-cipher-commands openssl list-message-dogest-algorithms openssl list-public-key-algorithms Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL algorithms vs. all algorithms...
On Tue, 6 Apr 2010 21:17:01 +0200 Dr. Stephen Henson st...@openssl.org wrote: Well that actual manual page is rather old and it still talks about PRNG initialisation which dates from the time OpenSSL didn't handle that automatically on many platforms. So are you saying there is no need to seed PRNG? Is there a way to check on a given platform if OpenSSL initialised PRNG? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL algorithms vs. all algorithms...
On Wed, Apr 07, 2010, Sad Clouds wrote: On Tue, 6 Apr 2010 21:17:01 +0200 Dr. Stephen Henson st...@openssl.org wrote: Well that actual manual page is rather old and it still talks about PRNG initialisation which dates from the time OpenSSL didn't handle that automatically on many platforms. So are you saying there is no need to seed PRNG? Is there a way to check on a given platform if OpenSSL initialised PRNG? I'm saying that many platforms (Windows, those with /dev/urandom or /dev/random) no longer need to seed the PRNG. Some others may need to add an entropy daemon such as EGD. You can check with RAND_status() (see manual page). Also any attempt to use an unseeded PRNG will fail with an error code. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Symmetric algorithms with Cell architecture
Is there anyone working with symmetric algorithms in Cell platform, i want suggestions to work with AES, taking advantage of the IBM Cell SPUs Thanks in advance smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
SSL algorithms vs. all algorithms...
http://cvs.openssl.org/chngview?cn=19536 -SSL_library_init() only registers ciphers. Another important initialization -is the seeding of the PRNG (Pseudo Random Number Generator), which has to -be performed separately. +SSL_library_init() mainly adds ciphers and digests used directly by SSL/TLS. +In some cases this is not sufficient and errors about unknown algorithms +will occur: for example when an attempt is made to use a certificate using +SHA256. This can be resolved by also calling OpenSSL_add_all_algorithms(). I find the last two sentences a bit confusing. Are certificates that use SHA-2 digests conformant with TLS 1.0 (AFAIK OpenSSL does not support TLS 1.1 or later)? If such certificates are valid, should not SHA-2 digests be initialized by SSL_library_init()? If such certificates are not valid with TLS 1.0, which applications need to worry about SHA-2 and OpenSSL_add_all_algorithms()? Postfix only calls SSL_library_init(), with the expectation that everything required for interoperable TLS/SSL support will be initialized via this call without resort to OpenSSL_add_all_algorithms(), is this the wrong expectation? Specifically, I would expect that SHA-2 will automatically be initialized as soon as OpenSSL implements support for a version of the protocol in which SHA-2 certificate signatures are valid. If TLS 1.0 is such a protocol version, then I would expect SSL_library_init() to initialize SHA-2 message digests. Has the guidance to developers who use OpenSSL for TLS/SSL rather than as general-purpose cryptography toolkit changed wrt. library initialization? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL algorithms vs. all algorithms...
On Tue, Apr 06, 2010, Victor Duchovni wrote: http://cvs.openssl.org/chngview?cn=19536 -SSL_library_init() only registers ciphers. Another important initialization -is the seeding of the PRNG (Pseudo Random Number Generator), which has to -be performed separately. +SSL_library_init() mainly adds ciphers and digests used directly by SSL/TLS. +In some cases this is not sufficient and errors about unknown algorithms +will occur: for example when an attempt is made to use a certificate using +SHA256. This can be resolved by also calling OpenSSL_add_all_algorithms(). I find the last two sentences a bit confusing. Are certificates that use SHA-2 digests conformant with TLS 1.0 (AFAIK OpenSSL does not support TLS 1.1 or later)? If such certificates are valid, should not SHA-2 digests be initialized by SSL_library_init()? If such certificates are not valid with TLS 1.0, which applications need to worry about SHA-2 and OpenSSL_add_all_algorithms()? Postfix only calls SSL_library_init(), with the expectation that everything required for interoperable TLS/SSL support will be initialized via this call without resort to OpenSSL_add_all_algorithms(), is this the wrong expectation? Specifically, I would expect that SHA-2 will automatically be initialized as soon as OpenSSL implements support for a version of the protocol in which SHA-2 certificate signatures are valid. If TLS 1.0 is such a protocol version, then I would expect SSL_library_init() to initialize SHA-2 message digests. Has the guidance to developers who use OpenSSL for TLS/SSL rather than as general-purpose cryptography toolkit changed wrt. library initialization? Well that actual manual page is rather old and it still talks about PRNG initialisation which dates from the time OpenSSL didn't handle that automatically on many platforms. Traditionally SSL_library_init() added all the algorithms you were most likely to encounter for SSL/TLS. There was always the possibility that additional algorithms could be encountered in certificates and private key encryption. You could for example find a certificate using RIPEMD and encrypt the private key with Blowfish. SHA2 is starting to be used in certifcates and as a result SSL_library_init() is not always sufficient any more. I suppose it makes sense to add the SHA2 algorithms to SSL_library_init() (40 bit RC2 was added so PKCS#12 still worked), they'll be needed for TLS 1.2 anyway. The dev version of OpenSSL (which will be 1.1.0) does support TLS 1.1 and it is something likely to be backported to 1.0.x for x = 1. TLS 1.2 is not under development yet. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL algorithms vs. all algorithms...
On Tue, Apr 06, 2010 at 09:17:01PM +0200, Dr. Stephen Henson wrote: Has the guidance to developers who use OpenSSL for TLS/SSL rather than as general-purpose cryptography toolkit changed wrt. library initialization? [...] I suppose it makes sense to add the SHA2 algorithms to SSL_library_init() (40 bit RC2 was added so PKCS#12 still worked), they'll be needed for TLS 1.2 anyway. That would be my naive expectation and preference... Thanks. By the way, does anyone have an insight on my recent AES speed question? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PKCS#7 SignedData and multiple digest algorithms
Hi, I'm investigating upgrading the applications I'm responsible for from SHA1 as the default PKCS#7 SignedData digest algorithm to stronger digests such as SHA256, in ways that preserve backwards compatibility for signature verifiers which do not support digest algorithms other than SHA1. I want to check my understanding of the PKCS#7 format and available options. What think I want to do is digest message content with both SHA1 and SHA256 (or more generally, a set of digest algorithms) such that older applications can continue to verify via the SHA1, and upgraded applications can begin verifying via the SHA256 (more generally, the strongest digest provided), ignoring the weaker algorithm(s). [If there is a better approach, please let me know.] It appears that within the PKCS#7 standard, the only way to provide multiple digests is to provide multiple SignerInfos, one for each digest algorithm. Unfortunately, this would seem to lead to a net *decrease* in security, as an attacker is able to strip all but the the SignerInfo with the weakest digest algorithm, which alone will still form a valid signature. Is this understanding correct? If so, my idea was to use custom attributes within the authenticatedAttributes field of SignerInfo to provide additional message-digests for the additional digest algorithms (leaving SHA1 as the default algorithm for backwards compatibility). Since this field is authenticated as a single block, this would prevent the above attack. Does this seem like a viable approach? Is there a way to accomplish this or something similar without going outside of the PKCS standard? Thanks, John __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
Hi All, Will the Openssl community will release all the openssl with fips support ie next release of openssl will support fips capability? Thanks Joshi Chandran On Mon, Jan 12, 2009 at 7:23 PM, Steve Marquess marqu...@oss-institute.orgwrote: PGNet wrote: On Sun, Jan 11, 2009 at 3:42 PM, Steve Marquess marqu...@oss-institute.org wrote: Long story short, OpenSSH really needs some source mods to gracefully invoke and run in FIPS mode. Hrm ... I'd have thought that openssh would be amoong the 1st/best @ compliance. Me too. I embarked on this FIPS validation adventure some six years ago because my DoD client at the time wanted a FIPS validated OpenSSH. I wrote a patch several years ago but didn't push it at the time because the first OpenSSL FIPS Object Module validation was still pending, and encountering some significant opposition that took all my attention. Now the OpenSSH patch is not a priority for any of my clients and I don't have the spare time to pursue it. I'd love to see someone else follow it through. To my knowledge Stunnel is the first application to formally support the FIPS object Module. I've been told ProFTP has baselined support as well. I've heard privately from many people who have done local mods of various applications, but have been disappointed in how slowly this support is appearing publicly. Several people, myself included, have created patches to that end. Are those specific patches sourced in the openssl trees, the openssh trees, or somewhere else? I'll google, but if you have URLs ... I could point you to my original very dated patch but I know there are some more recent updates. Check the OpenSSH mail archives. Of course, if you don't plan to actually run in FIPS mode and just need buzzword compliance (often the case) then what you plan should work. We've gotten a heads-up that a gov't client will require in the next (soon, tho hasn't occurred just yet ...) contract that SSH/VPN/IPSec/etc comms will be required. Of course, detailed spec, verification, etc is not yet available. $10 says it's for _their_ buzzword compliance Very typical for DoD. The mandates for *procurement* of validated software are (increasingly) enforced, but there doesn't seem to be any effective push to actually *use* a runtime FIPS mode. That lack of pressure plus the interoperability issues that FIPS mode can cause means program managers have zero incentive to actually run anything in FIPS mode. It's a paper chase. My goal is to get an all-ssh-in-fips-mode setup demo'd locally, then hand it off to our tech folks so that we can then respond document when the demand occurs. Please consider posting your patches to the OpenSSH lists... -Steve M. -- Steve Marquess Open Source Software Institute marqu...@oss-institute.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Regards Joshi Chandran
Re: which algorithms are enabled by default with fips?
It has already been released. Pick up the openssl-fips-1.2.tar.gz distribution, and the openssl-0.9.8j.tar.gz distribution. Also be aware that you MUST configure the openssl-fips package *EXACTLY* as described in the Security Policy. I am not going to try to reiterate the rules here, nor the commands you have to type. http://openssl.org/docs/fips/SecurityPolicy-1.2.pdf There is also a User Guide available, but anything that it contains that conflicts with the Security Policy is wrong. http://openssl.org/docs/fips/UserGuide-1.2.pdf After you build and install the openssl-fips package, then you can configure openssl-0.9.8j. Use the 'fips' option to ./config. (If you're looking for absolutely every version of OpenSSL that's released to have FIPS validation, you're not going to get it. The process for validation is expensive, on the order of $200,000 for each validation; the OpenSSL team members are already donating their time to the project and most likely don't have the cash to donate to the cause. As well, the vendor (for validation purposes) is the Open Source Software Institute, which does not directly manage the OpenSSL programmers or development effort. As well, it's taken on average over a year for each validation. This is why there's a separate tarball just for the FIPS-validated module; when in FIPS mode, all cryptography done by the library is redirected to be performed by the code in the module.) -Kyle H On Mon, Jan 19, 2009 at 8:34 AM, joshi chandran joshichandran...@gmail.com wrote: Hi All, Will the Openssl community will release all the openssl with fips support ie next release of openssl will support fips capability? Thanks Joshi Chandran On Mon, Jan 12, 2009 at 7:23 PM, Steve Marquess marqu...@oss-institute.org wrote: PGNet wrote: On Sun, Jan 11, 2009 at 3:42 PM, Steve Marquess marqu...@oss-institute.org wrote: Long story short, OpenSSH really needs some source mods to gracefully invoke and run in FIPS mode. Hrm ... I'd have thought that openssh would be amoong the 1st/best @ compliance. Me too. I embarked on this FIPS validation adventure some six years ago because my DoD client at the time wanted a FIPS validated OpenSSH. I wrote a patch several years ago but didn't push it at the time because the first OpenSSL FIPS Object Module validation was still pending, and encountering some significant opposition that took all my attention. Now the OpenSSH patch is not a priority for any of my clients and I don't have the spare time to pursue it. I'd love to see someone else follow it through. To my knowledge Stunnel is the first application to formally support the FIPS object Module. I've been told ProFTP has baselined support as well. I've heard privately from many people who have done local mods of various applications, but have been disappointed in how slowly this support is appearing publicly. Several people, myself included, have created patches to that end. Are those specific patches sourced in the openssl trees, the openssh trees, or somewhere else? I'll google, but if you have URLs ... I could point you to my original very dated patch but I know there are some more recent updates. Check the OpenSSH mail archives. Of course, if you don't plan to actually run in FIPS mode and just need buzzword compliance (often the case) then what you plan should work. We've gotten a heads-up that a gov't client will require in the next (soon, tho hasn't occurred just yet ...) contract that SSH/VPN/IPSec/etc comms will be required. Of course, detailed spec, verification, etc is not yet available. $10 says it's for _their_ buzzword compliance Very typical for DoD. The mandates for *procurement* of validated software are (increasingly) enforced, but there doesn't seem to be any effective push to actually *use* a runtime FIPS mode. That lack of pressure plus the interoperability issues that FIPS mode can cause means program managers have zero incentive to actually run anything in FIPS mode. It's a paper chase. My goal is to get an all-ssh-in-fips-mode setup demo'd locally, then hand it off to our tech folks so that we can then respond document when the demand occurs. Please consider posting your patches to the OpenSSH lists... -Steve M. -- Steve Marquess Open Source Software Institute marqu...@oss-institute.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Regards Joshi Chandran __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Re: which algorithms are enabled by default with fips?
PGNet wrote: On Sun, Jan 11, 2009 at 3:42 PM, Steve Marquess marqu...@oss-institute.org wrote: Long story short, OpenSSH really needs some source mods to gracefully invoke and run in FIPS mode. Hrm ... I'd have thought that openssh would be amoong the 1st/best @ compliance. Me too. I embarked on this FIPS validation adventure some six years ago because my DoD client at the time wanted a FIPS validated OpenSSH. I wrote a patch several years ago but didn't push it at the time because the first OpenSSL FIPS Object Module validation was still pending, and encountering some significant opposition that took all my attention. Now the OpenSSH patch is not a priority for any of my clients and I don't have the spare time to pursue it. I'd love to see someone else follow it through. To my knowledge Stunnel is the first application to formally support the FIPS object Module. I've been told ProFTP has baselined support as well. I've heard privately from many people who have done local mods of various applications, but have been disappointed in how slowly this support is appearing publicly. Several people, myself included, have created patches to that end. Are those specific patches sourced in the openssl trees, the openssh trees, or somewhere else? I'll google, but if you have URLs ... I could point you to my original very dated patch but I know there are some more recent updates. Check the OpenSSH mail archives. Of course, if you don't plan to actually run in FIPS mode and just need buzzword compliance (often the case) then what you plan should work. We've gotten a heads-up that a gov't client will require in the next (soon, tho hasn't occurred just yet ...) contract that SSH/VPN/IPSec/etc comms will be required. Of course, detailed spec, verification, etc is not yet available. $10 says it's for _their_ buzzword compliance Very typical for DoD. The mandates for *procurement* of validated software are (increasingly) enforced, but there doesn't seem to be any effective push to actually *use* a runtime FIPS mode. That lack of pressure plus the interoperability issues that FIPS mode can cause means program managers have zero incentive to actually run anything in FIPS mode. It's a paper chase. My goal is to get an all-ssh-in-fips-mode setup demo'd locally, then hand it off to our tech folks so that we can then respond document when the demand occurs. Please consider posting your patches to the OpenSSH lists... -Steve M. -- Steve Marquess Open Source Software Institute marqu...@oss-institute.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
which algorithms are enabled by default with fips?
With the addition of fips object to the 'mix' of available build options, is openssl configure with ./Configure ... enable-rc5 enable-mdc2 fips (iiuc, CHANGES' stmt that 'idea' *is* enabled by default still holds?) sufficient to enable _all_ available algorithms, with the option to disable per-algorithm still as no-xxx? Reading SecuritPolicy-1.2.pdf @ 4.5 Cryptographic Algorithms, I note, The Module supports the following FIPS approved or allowed algorithms: ... but am unclear as to which (any? all? none?) algos are enabled by default, per specification. Is that specifically stated somewhere? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
PGNet wrote: With the addition of fips object to the 'mix' of available build options, is openssl configure with ./Configure ... enable-rc5 enable-mdc2 fips (iiuc, CHANGES' stmt that 'idea' *is* enabled by default still holds?) sufficient to enable _all_ available algorithms, with the option to disable per-algorithm still as no-xxx? Here you are presumably using a FIPS compatible standard OpenSSL distribution, i.e. 0.9.8j. The fips option means find and reference the FIPS object module that has already been built and installed. The other options continue to mean what they always have. Note that if FIPS mode is *not* enabled at runtime (FIPS_mode_Set() function not called) then this FIPS compatible OpenSSL should continue to behave as it always has, so it still make sense to reference algorithms that are incompatible with FIPS 140-2. Our philosophy has been to allow generation and use of one set of OpenSSL dependent binaries for both normal use as before, and (when FPS mode is enabled) to satisfy FIPS 140-2 validation requirements. We do this by providing one relatively small specialized piece of code -- the FIPS Object Module -- that provides functionality specific to FIPS 140-2, and modifying the standard OpenSSL to enable or disable use of that module at runtime. When that module is not enabled OpenSSL behaves as always (even though the module is present it is dormant), when FIPS mode is enabled then OpenSSL disables non-allowed algorithms and references the module for the allowed ones. Note this means that a FIPS compatible OpenSSL subsumes two separate implementations of each FIPS allowed algorithm -- the standard implementation in OpenSSL and the FIPS validated one within the FIPS object module. Which one is used depends on the FIPS mode of operation. Reading SecuritPolicy-1.2.pdf @ 4.5 Cryptographic Algorithms, I note, The Module supports the following FIPS approved or allowed algorithms: ... but am unclear as to which (any? all? none?) algos are enabled by default, per specification. Is that specifically stated somewhere? The OpenSSL FIPS Object Module *itself* doesn't have the concept of enabling algorithms -- it supports only and exactly the algorithms mentioned in the Security Policy and validation. But, as noted above the FIPS Object Module typically isn't used by itself, usually it is used in conjunction with a FIPS compatible OpenSSL distribution which does have the concept of enabling or disabling algorithms. When FIPS mode is enabled at runtime that FIPS compatible distribution will automatically disable the use of non-allowed algorithms. -Steve M. -- Steve Marquess Open Source Software institute marqu...@oss-institute.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
Hi Steve, On Sun, Jan 11, 2009 at 10:14 AM, Steve Marquess marqu...@oss-institute.org wrote: Here you are presumably using a FIPS compatible standard OpenSSL distribution, i.e. 0.9.8j. yes, openssl version OpenSSL 0.9.8j-fips 07 Jan 2009 The fips option means find and reference the ... ... Clear thorough. Thanks. The OpenSSL FIPS Object Module *itself* doesn't have the concept of enabling algorithms ... When FIPS mode is enabled at runtime that FIPS compatible distribution will automatically disable the use of non-allowed algorithms. Ok. So , e.g. (reading the UserGuide now ...), to ensure that all ssh - ssh comms between boxes were limited correctly to fips-only algo usages, in openssl.cnf, I'd specifically add: # Openssh section openssh_conf = openssh_options ... [ openssh_options ] alg_section = algs ... [ algs ] fips_mode = yes yes? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
FIPS-capable builds are not subject to any restrictions as to the algorithms they can implement. The only restriction is that, while in FIPS mode (enabled by FIPS_mode_set()), the code within the fipscanister is used for all cryptographic operations (including encryption, decryption, hashing, and random number generation). When they're not in FIPS mode, they don't have to use the Module's code. This means that they can implement whatever they want. -Kyle H On Sun, Jan 11, 2009 at 9:28 AM, PGNet pgnet.trash+...@gmail.com wrote: With the addition of fips object to the 'mix' of available build options, is openssl configure with ./Configure ... enable-rc5 enable-mdc2 fips (iiuc, CHANGES' stmt that 'idea' *is* enabled by default still holds?) sufficient to enable _all_ available algorithms, with the option to disable per-algorithm still as no-xxx? Reading SecuritPolicy-1.2.pdf @ 4.5 Cryptographic Algorithms, I note, The Module supports the following FIPS approved or allowed algorithms: ... but am unclear as to which (any? all? none?) algos are enabled by default, per specification. Is that specifically stated somewhere? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
PGNet wrote: ... Ok. So , e.g. (reading the UserGuide now ...), to ensure that all ssh - ssh comms between boxes were limited correctly to fips-only algo usages, in openssl.cnf, I'd specifically add: # Openssh section openssh_conf = openssh_options ... [ openssh_options ] alg_section = algs ... [ algs ] fips_mode = yes yes? Yes, though with a caveat: the application (OpenSSH in this instance) still begs for some source modifications to handle exceptions. For one thing the ssh_config and sshd_config files might contain illegal ciphersuite specifications at runtime. Stock OpenSSH doesn't even default to a FIPS compatible ciphersuite. The FIPS capable OpenSSL with FIPS mode enabled will reject attempts to use non-allowed algorithms, but that rejection will not necessarily occur at the appropriate place from the perspective of the end user. Worse, we (or at least I) do not know that OpenSSH correctly checks the return codes from all OpenSSL API calls; if not some very undesirable behavior could result. Long story short, OpenSSH really needs some source mods to gracefully invoke and run in FIPS mode. Several people, myself included, have created patches to that end. Note I also specifically discuss OpenSSH in the User Guide. Of course, if you don't plan to actually run in FIPS mode and just need buzzword compliance (often the case) then what you plan should work. -Steve M. -- Steve Marquess Open Source Software institute marqu...@oss-institute.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: which algorithms are enabled by default with fips?
On Sun, Jan 11, 2009 at 3:42 PM, Steve Marquess marqu...@oss-institute.org wrote: Long story short, OpenSSH really needs some source mods to gracefully invoke and run in FIPS mode. Hrm ... I'd have thought that openssh would be amoong the 1st/best @ compliance. Several people, myself included, have created patches to that end. Are those specific patches sourced in the openssl trees, the openssh trees, or somewhere else? I'll google, but if you have URLs ... Note I also specifically discuss OpenSSH in the User Guide. Yes. Found that. Still, to my read, the needs patches bit was a surpise. Of course, if you don't plan to actually run in FIPS mode and just need buzzword compliance (often the case) then what you plan should work. We've gotten a heads-up that a gov't client will require in the next (soon, tho hasn't occurred just yet ...) contract that SSH/VPN/IPSec/etc comms will be required. Of course, detailed spec, verification, etc is not yet available. $10 says it's for _their_ buzzword compliance My goal is to get an all-ssh-in-fips-mode setup demo'd locally, then hand it off to our tech folks so that we can then respond document when the demand occurs. Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please help: very urgent: Query on patented algorithms
At 01:20 PM 6/16/2008, Michael Sierchio wrote: RC4 is owned (and trademarked) by RSA Security Inc, but they are no longer enforcing the patent, RC4 was never protected by patent, but by trade secret. When the details of the algorithm were published, Ron Rivest himself suggested calling the alleged RC4 ARCFOUR. It is indeed a trademark of RSA Security. Michael is right. No patent. RSA subsequently switched to patent protection for RC5 and RC5. Some ancient history might offer context. RC4, developed by Rivest in 1987, was originally sold, under contractual constraints, as a proprietary RSA trade secret -- a mode of IP protection which soon proved to be frail and toothless in Cyberspace, where anonymous publication on the Net broke the trade secret contract but allowed the perpetrator to escape all liability. RSADSI initially filed for US trademark protection on RC4 in 1993, and the trademark -- as a mark of origin, a mark that identified the source of the distributed code -- became the last line defense for the RC4 IP when the RC4 algorithm was reverse engineered and published on the Cypherpunks List in September of 1994. In a swirl of ironies, this was a critical event in public crypto history, because the illicit publication of RC4 made it possible for non-US developers to do their own versions of SSL. SSLea, ancestor of OpenSSL, soon broke the NSA's restrictive policies on the international use of strong-crypto SSL for browsers and web-based transactions. Many versions of alleged RC4 (ARC4 or ArcFour) were soon in widespread use, even in IETF standards. Anyone can code or use ACR4, but EMC/RSA still defends its monopoly on the RC4 trademark because undefended trademarks become invalid. _Vin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Please help: very urgent: Query on patented algorithms
Hi, I have openssl dlls(i.e.libeay32.dll, ssleay32.dll). I need to know if these libaries are using any of the patented algorithms like IDEA, RC4, RC5,MDC2 etc. Can you please let me know if there is any way to find out this? Any help would be highly appreciated. Thanks in adavance, Bagavathy
Re: Please help: very urgent: Query on patented algorithms
Hi, Use the tool Dependency Walker (http://www.dependencywalker.com/) to look at the exported functions of libeay32.dll. If it exports RC5, you will see exported symbols starting with RC5. For MDC2, you'll find symbols starting with MDC2 and etc... Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On Mon, June 16, 2008 3:55 pm, bagavathy raj wrote: Hi, I have openssl dlls(i.e.libeay32.dll, ssleay32.dll). I need to know if these libaries are using any of the patented algorithms like IDEA, RC4, RC5,MDC2 etc. Can you please let me know if there is any way to find out this? Any help would be highly appreciated. Thanks in adavance, Bagavathy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Please help: very urgent: Query on patented algorithms
Hi, Is there any binary distribution where I can find SSL dlls without patented algorithms like IDEA,MCD2,RC4,RC5 etc. I tried compiling without them. I could exclude other algos but not RC4. Some linking issues. So i need to know if there is any ssl release without the patented algorithms. On 6/16/08, Mounir IDRASSI [EMAIL PROTECTED] wrote: Hi, Use the tool Dependency Walker (http://www.dependencywalker.com/) to look at the exported functions of libeay32.dll. If it exports RC5, you will see exported symbols starting with RC5. For MDC2, you'll find symbols starting with MDC2 and etc... Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On Mon, June 16, 2008 3:55 pm, bagavathy raj wrote: Hi, I have openssl dlls(i.e.libeay32.dll, ssleay32.dll). I need to know if these libaries are using any of the patented algorithms like IDEA, RC4, RC5,MDC2 etc. Can you please let me know if there is any way to find out this? Any help would be highly appreciated. Thanks in adavance, Bagavathy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Please help: very urgent: Query on patented algorithms
On 6/16/08, bagavathy raj [EMAIL PROTECTED] wrote: Hi, Is there any binary distribution where I can find SSL dlls without patented algorithms like IDEA,MCD2,RC4,RC5 etc. I tried compiling without them. I could exclude other algos but not RC4. Some linking issues. So i need to know if there is any ssl release without the patented algorithms. RC4 is owned (and trademarked) by RSA Security Inc, but they are no longer enforcing the patent, and will allow free usage of the OpenSSL implementation of this cipher to those that ask. However they do require that OpenSSL toolkit users either do not call it RC4, or call it Alleged RC4 cipher to avoid trademark infringement. If you even mention the words RC4 in your documentation you may need to mention that it is Alleged and that RC4 is a trademark of RSA Security. RC2 is also a trademark of RSA Security, but this one can be used without the Alleged prefix, providing you list them as the trademark owner. Disclaimer: I am not a lawyer, and I suggest you contact RSA directly to confirm this information on your own. -Chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Please help: very urgent: Query on patented algorithms
RC4 is owned (and trademarked) by RSA Security Inc, but they are no longer enforcing the patent, RC4 was never protected by patent, but by trade secret. When the details of the algorithm were published, Ron Rivest himself suggested calling the alleged RC4 ARCFOUR. It is indeed a trademark of RSA Security. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: cipher algorithms
I can partially answer question #1. Yes, the client send the list of ciphers it supports to the server. The server will then pick the 'strongest' cipher from the list for negotiating the session. The priority is based on strength, best I can tell and differ between server implementations. For instance IIS and Apache will negotiate slightly different as far as what each considers 'stronger'. If your definition of random is each web server platform being a bit different in negotiation, then yes it is random ;) (sarcasm) Hope that helps, Brian Trzupek On Mar 4, 2008, at 5:28 AM, Baur, Mateus (Brazil RD-CL) wrote: Hi All, I have some doubts regarding OpenSSL cipher algorithms and I was wondering if someone could help me with that. 1) If my understanding is correct, the client sends the list of supported cipher algorithms and the server will choose one algorithm of such list in order to establish the secure channel. Is there some priority for the algorithms? For instances, will it favor AES in lieu DES whenever supported by the client? Or is the algorithm chosen randomly? 2) How is the symmetric key negotiated in OpenSSL? Does it use Diffie-Hellman or RSA? Or does it vary depending on client request? If the second, what is used if client supports both? Thanks in advance, Mateus
Re: cipher algorithms
Hello, I have some doubts regarding OpenSSL cipher algorithms and I was wondering if someone could help me with that. 1) If my understanding is correct, the client sends the list of supported cipher algorithms and the server will choose one algorithm of such list in order to establish the secure channel. Is there some priority for the algorithms? For instances, will it favor AES in lieu DES whenever supported by the client? Or is the algorithm chosen randomly? Client should sent most favorite cipher first. But, of course, server makes the final decision. Client order of cipher_suites in client_hello is only hint for server. 2) How is the symmetric key negotiated in OpenSSL? Does it use Diffie-Hellman or RSA? Or does it vary depending on client request? If the second, what is used if client supports both? Key exchange method is dependent of chosen ciphersuite. Look at: $ openssl ciphers -v Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: cipher algorithms
Thanks Marek! One last question, can an algorithm or cipher suite be enabled or disabled on OpenSSL by an user (I mean, without needing to recompile and redistribute OpenSSL binaries)? Regards, Mateus -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: quarta-feira, 5 de março de 2008 05:51 To: openssl-users@openssl.org Subject: Re: cipher algorithms Hello, I have some doubts regarding OpenSSL cipher algorithms and I was wondering if someone could help me with that. 1) If my understanding is correct, the client sends the list of supported cipher algorithms and the server will choose one algorithm of such list in order to establish the secure channel. Is there some priority for the algorithms? For instances, will it favor AES in lieu DES whenever supported by the client? Or is the algorithm chosen randomly? Client should sent most favorite cipher first. But, of course, server makes the final decision. Client order of cipher_suites in client_hello is only hint for server. 2) How is the symmetric key negotiated in OpenSSL? Does it use Diffie-Hellman or RSA? Or does it vary depending on client request? If the second, what is used if client supports both? Key exchange method is dependent of chosen ciphersuite. Look at: $ openssl ciphers -v Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: cipher algorithms
Thanks Marek! One last question, can an algorithm or cipher suite be enabled or disabled on OpenSSL by an user (I mean, without needing to recompile and redistribute OpenSSL binaries)? You can definitively disable an algorithm by not including it in the libraries. Most programs that use OpenSSL, including the build in 'openssl' executable permit you to change the algorithms used one way or another. I do not believe that OpenSSL provides a generic way to do this for other applications that use OpenSSL. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: cipher algorithms
Yes, I know you can enable/disable the algorithms at build time. However, my question is if a user could enable/disable an algorithm when the library is already built (even by the application using OpenSSL or some generic configuration of OpenSSL). I thought there was actually no way to do that. Your answer reinforces that. Thanks, Mateus -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl- [EMAIL PROTECTED] On Behalf Of David Schwartz Sent: quarta-feira, 5 de março de 2008 09:12 To: openssl-users@openssl.org Subject: RE: cipher algorithms Thanks Marek! One last question, can an algorithm or cipher suite be enabled or disabled on OpenSSL by an user (I mean, without needing to recompile and redistribute OpenSSL binaries)? You can definitively disable an algorithm by not including it in the libraries. Most programs that use OpenSSL, including the build in 'openssl' executable permit you to change the algorithms used one way or another. I do not believe that OpenSSL provides a generic way to do this for other applications that use OpenSSL. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: cipher algorithms
Surely http://www.openssl.org/docs/ssl/SSL_CTX_set_cipher_list.html. G. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baur, Mateus (Brazil RD-CL) Sent: 05 March 2008 12:25 To: openssl-users@openssl.org Subject: RE: cipher algorithms Yes, I know you can enable/disable the algorithms at build time. However, my question is if a user could enable/disable an algorithm when the library is already built (even by the application using OpenSSL or some generic configuration of OpenSSL). I thought there was actually no way to do that. Your answer reinforces that. Thanks, Mateus -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl- [EMAIL PROTECTED] On Behalf Of David Schwartz Sent: quarta-feira, 5 de março de 2008 09:12 To: openssl-users@openssl.org Subject: RE: cipher algorithms Thanks Marek! One last question, can an algorithm or cipher suite be enabled or disabled on OpenSSL by an user (I mean, without needing to recompile and redistribute OpenSSL binaries)? You can definitively disable an algorithm by not including it in the libraries. Most programs that use OpenSSL, including the build in 'openssl' executable permit you to change the algorithms used one way or another. I do not believe that OpenSSL provides a generic way to do this for other applications that use OpenSSL. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: cipher algorithms
Hello, One last question, can an algorithm or cipher suite be enabled or disabled on OpenSSL by an user (I mean, without needing to recompile and redistribute OpenSSL binaries)? Yes, from server or client point of view you can control this with SSL_CTX_set_cipher_list() function call. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
cipher algorithms
Hi All, I have some doubts regarding OpenSSL cipher algorithms and I was wondering if someone could help me with that. 1) If my understanding is correct, the client sends the list of supported cipher algorithms and the server will choose one algorithm of such list in order to establish the secure channel. Is there some priority for the algorithms? For instances, will it favor AES in lieu DES whenever supported by the client? Or is the algorithm chosen randomly? 2) How is the symmetric key negotiated in OpenSSL? Does it use Diffie-Hellman or RSA? Or does it vary depending on client request? If the second, what is used if client supports both? Thanks in advance, Mateus
AW: cipher algorithms
Hi, The browser can be configured for example: Firefox: security-prefs.js pref(security.ssl3.rsa_1024_des_cbc_sha, false); pref(security.ssl3.rsa_1024_des_cbc_sha, false); pref(security.ssl3.rsa_1024_des_cbc_sha, false); will disable these combinations. The server can be configured for example: Apache http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html How can I create a real SSLv2-only server? The following creates an SSL server which speaks only the SSLv2 protocol and its ciphers. httpd.conf SSLProtocol -all +SSLv2 SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP How can I create an SSL server which accepts strong encryption only? The following enables only the seven strongest ciphers: httpd.conf SSLProtocol all SSLCipherSuite HIGH:MEDIUM Regards Emre __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
CA certificate and signature algorithms
Hi All, I have a CA certificate with Signature Algorithm md21RSA. Can I create a server certificate with Signature Algorithm sha1RSA and sign the server certificate using the above CA certificate. Will there be any problems. Thanks in advance. Jaya __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
X509 v3 extensions and Digest Algorithms
dear friends of OpenSSL, i use OpenSSL-0.9.7 in an application that generates certificates with x509 v3 extensions. i have some questions: i) according to one post (http://www.mail-archive.com/openssl-dev@openssl.org/msg11608.html) OpenSSL-0.9.7 does not support otherName as a valid option for SubjectAltName extension (only: rfc822Name, dNSName, uniformResourceIdentifier, iPAddress, registeredID). is this true? Do i have to use OpenSSL-0.9.8 to use this option? ii) i would like to know how i could use the certificatePolicies extension in a certificate. how could i create the raw extension? iii) Does OpenSSL-0.9.7 support SHA256 and SHA512 digest algorithms? i read that OpenSSL-0.9.7k (for exmaple) has support to these algorithms but it is completely necessary to compiling and installing OpenSSL FIPS Module before. OpenSSL-0.9.8 does support these algorithms. i found a post that says OpenSSL FIPS Module is temporaly suspended. is there any way to support SHA256 and SHA512 digest algorithms in OpenSSL-0.9.7? Best regards Antonio Araujo Brett __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
What are the requirements for using Openssl crypto algorithms without openssl installation?
Dear all, What are the requirements for using Openssl crypto algorithms without openssl installation? For instance, i want to seperate and compile HMAC code without errors. Thanks in advance.
Re: What are the requirements for using Openssl crypto algorithms without openssl installation?
openssl-0.9.8a/crypto/hmac directory has the hmac interface code. openssl-0.9.8a/crypto/sha directory has the sha implementation and openssl-0.9.8a/crypto/md5 directory has the md5 implementation. Now you take the relevant files, remove the dependencies and compile... All the best! regards, Girish --- Aidaros Dev [EMAIL PROTECTED] wrote: Dear all, What are the requirements for using Openssl crypto algorithms without openssl installation? For instance, i want to seperate and compile HMAC code without errors. Thanks in advance. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: What are the requirements for using Openssl crypto algorithms without openssl installation?
Hello, openssl-0.9.8a/crypto/sha directory has the sha implementation and Yes, but you must pay attention on target platform. For example with ssh256-512 there are some defines which are enabled with configure step and are different on different platforms (for example SHA_LONG, SHA_LONG_LOG2). Especially, careful check word size (32/64 bit) and byte oreder (BIG/LITTLE endian) of target system. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: What are the requirements for using Openssl crypto algorithms without openssl installation?
Thanks Girish, Marek and all Girish, what you mean remove dependencies? I start the main function from hmactest.c I gathered relevant included files such as hmac md5 evp.h e_os but each calls other include files...until when I compile without error but i show you some of linking errors : cryptlib.obj : error LNK2001: unresolved external symbol _BUF_strdup eng_lib.obj : error LNK2001: unresolved external symbol _CRYPTO_get_ex_data err.obj : error LNK2001: unresolved external symbol _CRYPTO_pop_info Im using VC6 windows platform. Thanks in advance __OpenSSL Project http://www.openssl.orgUser Support Mailing Listopenssl-users@openssl.orgAutomated List Manager [EMAIL PROTECTED]
Which algorithms are need for PKCS12_parse?
I'm trying to use PKCS12_parse and it's failing with: error:06074079:digital envelope routines:EVP_PBE_CipherInit:unknown pbe algorithm error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error error:2306A075:PKCS12 routines:PKCS12_decrypt_d2i:pkcs12 pbe crypt error error:23076072:PKCS12 routines:PKCS12_parse:parse error This is a PKCS#12 container I created with OpenSSL 0.9.7 using whatever default algorithms it uses (the manual says RC2-40 and 3DES but I have added those without luck). Now, I am manually adding the algorithms and I absolutely do not want to use any sort of all_all_algorithms function because that makes my final application way too large (I'm statically linking to OpenSSL). It does actually work if I add all algorithms but as I said I do not want to do that. I have tried adding all this: EVP_add_cipher(EVP_des_ede()); EVP_add_cipher(EVP_des_ede3()); EVP_add_cipher(EVP_des_ede_ecb()); EVP_add_cipher(EVP_des_ede3_ecb()); EVP_add_cipher(EVP_des_cfb64()); EVP_add_cipher(EVP_des_cfb1()); EVP_add_cipher(EVP_des_cfb8()); EVP_add_cipher(EVP_des_ede_cfb64()); EVP_add_cipher(EVP_des_ede3_cfb64()); EVP_add_cipher(EVP_des_ede3_cfb1()); EVP_add_cipher(EVP_des_ede3_cfb8()); EVP_add_cipher(EVP_des_ofb()); EVP_add_cipher(EVP_des_ede_ofb()); EVP_add_cipher(EVP_des_ede3_ofb()); EVP_add_cipher(EVP_des_ede_cbc()); EVP_add_cipher(EVP_des_ede3_cbc()); EVP_add_cipher(EVP_desx_cbc()); EVP_add_cipher(EVP_rc2_ecb()); EVP_add_cipher(EVP_rc2_cbc()); EVP_add_cipher(EVP_rc2_40_cbc()); EVP_add_cipher(EVP_rc2_64_cbc()); EVP_add_cipher(EVP_rc2_cfb64()); EVP_add_cipher(EVP_rc2_ofb()); EVP_add_cipher(EVP_rc4()); EVP_add_cipher(EVP_rc4_40()); EVP_add_cipher(EVP_des_ecb()); EVP_add_cipher(EVP_des_cbc()); EVP_add_cipher(EVP_aes_256_ecb()); EVP_add_cipher(EVP_aes_256_cbc()); EVP_add_digest(EVP_md5()); EVP_add_digest(EVP_sha1()); No luck... I wish the error messages would tell me _which_ algorithm is missing. ? When searching for other people having this problem the answer is always add all algorithms. Thanks for any help. -- // Chris
Re: Which algorithms are need for PKCS12_parse?
On Thu, Feb 16, 2006, Chris wrote: error:06074079:digital envelope routines:EVP_PBE_CipherInit:unknown pbe algorithm error:23077073:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 algor cipherinit error error:2306A075:PKCS12 routines:PKCS12_decrypt_d2i:pkcs12 pbe crypt error error:23076072:PKCS12 routines:PKCS12_parse:parse error [snip] No luck... I wish the error messages would tell me _which_ algorithm is missing. ? When searching for other people having this problem the answer is always add all algorithms. Its a password based encryption (PBE) algorithm. Probably 40 bit RC2 and/or 3DES using the PKCS#12 key derivation algorihtm. Try calling PKCS12_PBE_add(). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Which algorithms are need for PKCS12_parse?
On 2/16/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: Its a password based encryption (PBE) algorithm. Probably 40 bit RC2 and/or3DES using the PKCS#12 key derivation algorihtm. Try calling PKCS12_PBE_add().Steve. Thanks! That did the trick. I wish all these _add() functions were listed somewhere or at least listed in the relevant sections of the documentation. I spent much time looking through evp.h and other headers trying to find something that made sense and the whole time all I needed was PKCS12_PBE_add(). Thanks again! -- // Chris
Re: Which algorithms are need for PKCS12_parse?
On Thu, Feb 16, 2006, Chris wrote: On 2/16/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: Its a password based encryption (PBE) algorithm. Probably 40 bit RC2 and/or 3DES using the PKCS#12 key derivation algorihtm. Try calling PKCS12_PBE_add(). Steve. Thanks! That did the trick. I wish all these _add() functions were listed somewhere or at least listed in the relevant sections of the documentation. I spent much time looking through evp.h and other headers trying to find something that made sense and the whole time all I needed was PKCS12_PBE_add(). It is documented in doc/openssl.txt and that file is referred to in the FAQ... http://www.openssl.org/support/faq.html#MISC2 At some point I'll tidy that up and place it in an appropriate manual page or better still tidy up the PBE API and document the tidied version... Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
