DH group cipher suites getting rejected

[Chitrang Srivastava]

Hi,

Why google rejected DH ciphers suites, I am trying
*openssl s_client -cipher 'DHE-RSA-AES128-GCM-SHA256' -connect
www.google.com:443 *
However if I try ECDHE, it works fine. Is DHE only cipher suites less
common now ?
I believe its responsibility of server to generate DHparam of large enough
size.

Thanks

Re: PrivateKey Decrypt Failure

[Chitrang Srivastava]

Thanks very much, that worked.


On Wed, Sep 11, 2019 at 10:56 PM Wim Lewis  wrote:

>
>
> On Sep 11, 2019, at 3:31 AM, Chitrang Srivastava <
> chitrang.srivast...@gmail.com> wrote:
> > I am using openssl 1.1.1b and I am storing private key encrypted.
> >
> > I am storing private key as
> > PEM_write_bio_PrivateKey(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12,
> 0, 0, NULL);
>
> I don't think that PEM_write_bio_PrivateKey() will compute the key length
> for you if you pass 0. If you pass klen=0 it will encrypt with a 0-byte
> key. Try passing strlen(PKeyPassPKCS12) for klen and see if that helps.
>
>
>

PrivateKey Decrypt Failure

[Chitrang Srivastava]

Hi,

I am using openssl 1.1.1b and I am storing private key encrypted.

I am storing private key as
*PEM_write_bio_PrivateKey*(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, 0,
0, NULL);
and on system startup reading using the following way
 if(!*PEM_read_bio_PrivateKey*(keyBIO, _s_key, NULL,
decryptSharedSecret))

Upon debugging I found it is failing in PKCS12_pbe_crypt >
*EVP_CipherFinal_ex*
Please suggest where I am doing wrong?
Could this be appear to related to padding ?
Without encryption of key , it works fine , which clear other code is all
fine.

Thanks,

*evp_enc.c:EVP_DecryptFinal_ex:569*
/*
 * The following assumes that the ciphertext has been authenticated.
 * Otherwise it provides a padding oracle.
 */
n = ctx->final[b - 1];
if (n == 0 || n > (int)b) {

*EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_BAD_DECRYPT);*
return 0;
}

Re: Acquire Entropy for embedded platform

[Chitrang Srivastava]

from the git repo of cpu jitter i see few files only so may be easy to
compile  at least.
Yeah it can be added to openssl source with macro to enable it.

On Fri, Aug 16, 2019 at 4:05 PM Dr Paul Dale  wrote:

> Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
> entropy sources.
> I dread the effort that this would entail.
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava <
> chitrang.srivast...@gmail.com> wrote:
>
> Thanks Pauli,
>
> I did checked CPU Jitter and it looks promising. It has openssl engine
> support too.
> So i guess I have to add this add provide OS specific calls and it should
> work.
> Will keep you posted.
>
> Thanks,
>
>
> On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale  wrote:
>
>> I investigated HAVEGE fairly deeply a couple of years ago.  I am
>> completely in agreement with the basis of this source, however the sticking
>> point was the “expansion” phase.  Essentially, every bit of entropy
>> gathered is turned into (just under) thirty two bits of “entropy”.  This is
>> logically and physically impossible.  As a source, it appears reasonable to
>> the usual tests (i.e. dieharder), although TestU01
>> <https://en.wikipedia.org/wiki/TestU01> does pick up on it being less
>> than ideal.
>>
>> I would, however, recommend Stephan Müller's CPU Jitter
>> <https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>.  The gathering
>> is well researched and performed, no hidden tricks are present and the bits
>> produces are equiprobable.
>>
>>
>> Pauli
>> --
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
>> Phone +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>>
>> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz  wrote:
>>
>>
>>
>> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>>
>> Hi,
>>
>> I am working on an embedded platform and now ported openssl 1.1.1b
>> TLS 1.2/1.3 is working fine.
>> While analysing random number , Rand pool initialization calls where I am
>> returning like this ,
>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
>> {
>> return rand_pool_entropy_available(pool);
>> }
>> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits
>> of RTC, would that give enough entropy or any other recommendation to have
>> enough entropy for embedded platforms?
>>
>>
>>
>> Check out:https://issihosts.com/haveged
>>
>> I talk about it here:
>> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS
>>
>>
>>
>>
>

Re: Acquire Entropy for embedded platform

[Chitrang Srivastava]

Thanks Pauli,

I did checked CPU Jitter and it looks promising. It has openssl engine
support too.
So i guess I have to add this add provide OS specific calls and it should
work.
Will keep you posted.

Thanks,


On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale  wrote:

> I investigated HAVEGE fairly deeply a couple of years ago.  I am
> completely in agreement with the basis of this source, however the sticking
> point was the “expansion” phase.  Essentially, every bit of entropy
> gathered is turned into (just under) thirty two bits of “entropy”.  This is
> logically and physically impossible.  As a source, it appears reasonable to
> the usual tests (i.e. dieharder), although TestU01
> <https://en.wikipedia.org/wiki/TestU01> does pick up on it being less
> than ideal.
>
> I would, however, recommend Stephan Müller's CPU Jitter
> <https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>.  The gathering
> is well researched and performed, no hidden tricks are present and the bits
> produces are equiprobable.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz  wrote:
>
>
>
> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>
> Hi,
>
> I am working on an embedded platform and now ported openssl 1.1.1b
> TLS 1.2/1.3 is working fine.
> While analysing random number , Rand pool initialization calls where I am
> returning like this ,
> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
> {
> return rand_pool_entropy_available(pool);
> }
> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits
> of RTC, would that give enough entropy or any other recommendation to have
> enough entropy for embedded platforms?
>
>
>
> Check out:https://issihosts.com/haveged
>
> I talk about it here:
> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS
>
>
>
>

Acquire Entropy for embedded platform

[Chitrang Srivastava]

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I am
returning like this ,
size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 bits of
RTC, would that give enough entropy or any other recommendation to have
enough entropy for embedded platforms?

Thanks,

Re: SSL Server setup DH/ECDH

[Chitrang Srivastava]

Hi Matt,

I tried following code but it is crashing @ *SSL_CTX_set_ciphersuites*
s_ctx = SSL_CTX_new(TLS_method());
SSL_CTX_set_options(s_ctx,  SSL_OP_NO_RENEGOTIATION |
SSL_OP_CIPHER_SERVER_PREFERENCE);
SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION);
SSL_CTX_set_ciphersuites(s_ctx,
"TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384");

In the debugger I noticed

s_ctx :: cipher_list & cipher_list_by_id are both NULL
However tls13_ciphersuites is populated.
Further in update_cipher_list which is called by SSL_CTX_set_ciphersuites
tries to delete this cipher_list and hence crash ?

Any pointer what I am missing?

-Thanks



On Tue, Aug 6, 2019 at 7:48 PM Matt Caswell  wrote:

>
>
> On 06/08/2019 14:58, Chitrang Srivastava wrote:
> > Yeah I mean TLS 1.3 cipher , sorry I haven't pasted exact names.
> > So after SSL_OP_CIPHER_SERVER_PREFERENCE, server uses
> > TLS_1_3_AES_256_SHA_384.
> > While without that it uses TLS_1_3_AES_128_SHA_256, which is better in
> terms of
> > performance.
>
> Ah! Right - now I understand.
>
> So the option SSL_OP_CIPHER_SERVER_PREFERENCE means that the server
> prefers the
> server's ordering of ciphersuites compared to the clients. With that
> option set
> it will use the first ciphersuite that is in the server's list that is
> also in
> the client's list. Without the set it will use the first ciphersuite that
> is in
> the client's list that is also in the server's list. Server operators often
> prefer this because it gives more control over which ciphersuite
> ultimately gets
> used. But that's only really useful if you also look at this list of
> configured
> ciphersuites and make sure they are in your preferred order! Otherwise the
> option is fairly pointless!
>
> For TLSv1.3 the default list is:
>
> #   define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \
> "TLS_CHACHA20_POLY1305_SHA256:" \
> "TLS_AES_128_GCM_SHA256"
>
> If you want a different order you can use the functions
> SSL_CTX_set_ciphersuites() (or SSL_set_ciphersuites()) to amend it:
>
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ciphersuites.html
>
> Matt
>
> >
> > Thanks very much,
> > Chitrang
> >
> > Tuesday, August 6, 2019, Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 06/08/2019 12:20, Chitrang Srivastava wrote:
> > > Noticed that if I set  SSL_OP_CIPHER_SERVER_PREFERENCE,
> > TLS_1_3_AES_256_SHA_384
> > > is being used while without that
> > > AES_128_SHA256 is being used and I see client(Chrome) send this as
> first
> > preference.
> > > Is there anyway where I can always prefer AES-128-SHA256 cipher
> suite of
> > TLS 1.3?
> >
> > Hmmm...are you sure?
> >
> > Those names don't look like OpenSSL names for those ciphersuites. I
> guess you
> > mean TLS_AES_256_GCM_SHA384 and AES128-SHA256. The former is a
> TLSv1.3
> > ciphersuite and the latter is for TLSv1.2 and below. They are
> mutually
> > exclusive. If you negotiate TLSv1.3 then you can't use TLSv1.2
> ciphersuites and
> > vice versa.
> >
> > SSL_OP_CIPHER_SERVER_PREFERENCE should not affect the protocol
> version
> > negotiated. OpenSSL negotiates the version *first* before deciding
> what
> > ciphersuite to use. So it should not be the case that
> > SSL_OP_CIPHER_SERVER_PREFERENCE suddenly causes a TLSv1.3
> ciphersuite to be used
> > when a TLSv1.2 ciphersuite was used without it.
> >
> > Matt
> >
> >
> > >
> > > On Tue, Aug 6, 2019 at 3:53 PM Matt Caswell  > <mailto:m...@openssl.org>
> > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> > >
> > >
> > >
> > > On 06/08/2019 11:21, Chitrang Srivastava wrote:
> > > > Yes , since in my case mostly browser will be used to access
> > webserver running
> > > > on embedded platform.
> > > > Another question, since my webserver is running on embedded
> platform and
> > > it has
> > > > limited memory , I have disabled
> > > > ARIA/CAMELLIA  and few others, is that OK ? because I don't
> see any
> >     ciphers
> > > > suites which is used in practice.
> > >
> > > Yes, that should be fine

Re: SSL Server setup DH/ECDH

[Chitrang Srivastava]

Yes , since in my case mostly browser will be used to access webserver
running on embedded platform.
Another question, since my webserver is running on embedded platform and it
has limited memory , I have disabled
ARIA/CAMELLIA  and few others, is that OK ? because I don't see any ciphers
suites which is used in practice.



On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell  wrote:

>
>
> On 06/08/2019 11:07, Chitrang Srivastava wrote:
> > Thanks Matt,
> >
> > So now I have, which i believe is enough ?
> >
> > SSL_CTX_set_options(s_ctx,  SSL_OP_NO_RENEGOTIATION |
> > SSL_OP_CIPHER_SERVER_PREFERENCE);
> > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION);
>
> This is fine although it obviously prevents connections from very old
> clients
> that don't support TLSv1.2. This might not be a problem for you depending
> on
> your situation.
>
> Matt
>
> >
> > On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 06/08/2019 09:42, Chitrang Srivastava wrote:
> > > Hi,
> > >
> > > I am implementing HTTPs server using openssl 1.1.1b.
> > > Is it mandatory to setup these API's while creating ssl context ?
> > >
> > > SSL_CTX_set_tmp_ecdh
> > >
> > > SSL_CTX_set_tmp_dh
> >
> > By default OpenSSL will automatically use ECDH if appropriate and
> choose a
> > suitable group so there is no need to call SSL_CTX_set_tmp_ecdh()
> unless you
> > want more control over which specific group is used.
> >
> > OpenSSL will not use DH unless you specifically configure it. If you
> want to
> > make use of DH based ciphersuites then you must either call
> SSL_CTX_set_tmp_dh()
> > or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the
> former enables
> > you to configure any arbitrary DH group that you choose. Calling the
> latter will
> > enable the built-in DH groups.
> >
> > It is not mandatory to call any of the above.
> >
> > >
> > > Also any suggestion what all options one should set while setting
> up
> > server like
> > > SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3
> >
> > Don't use the protocol version specific options at all. Use
> > SSL_CTX_set_min_proto_version() if you want to specify a minimum
> protocol
> > version. SSLv2 is no longer supported at all. SSLv3 is compiled out
> by default.
> >
> > Other options that are worth considering are SSL_OP_NO_RENEGOTIATION
> and
> > (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need
> the others
> > unless there is a specific problem you are trying to solve.
> >
> > Matt
> >
>

Re: SSL Server setup DH/ECDH

[Chitrang Srivastava]

Thanks Matt,

So now I have, which i believe is enough ?

SSL_CTX_set_options(s_ctx,  SSL_OP_NO_RENEGOTIATION |
SSL_OP_CIPHER_SERVER_PREFERENCE);
SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION);

On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell  wrote:

>
>
> On 06/08/2019 09:42, Chitrang Srivastava wrote:
> > Hi,
> >
> > I am implementing HTTPs server using openssl 1.1.1b.
> > Is it mandatory to setup these API's while creating ssl context ?
> >
> > SSL_CTX_set_tmp_ecdh
> >
> > SSL_CTX_set_tmp_dh
>
> By default OpenSSL will automatically use ECDH if appropriate and choose a
> suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() unless
> you
> want more control over which specific group is used.
>
> OpenSSL will not use DH unless you specifically configure it. If you want
> to
> make use of DH based ciphersuites then you must either call
> SSL_CTX_set_tmp_dh()
> or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the former
> enables
> you to configure any arbitrary DH group that you choose. Calling the
> latter will
> enable the built-in DH groups.
>
> It is not mandatory to call any of the above.
>
> >
> > Also any suggestion what all options one should set while setting up
> server like
> > SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3
>
> Don't use the protocol version specific options at all. Use
> SSL_CTX_set_min_proto_version() if you want to specify a minimum protocol
> version. SSLv2 is no longer supported at all. SSLv3 is compiled out by
> default.
>
> Other options that are worth considering are SSL_OP_NO_RENEGOTIATION and
> (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need the
> others
> unless there is a specific problem you are trying to solve.
>
> Matt
>

SSL Server setup DH/ECDH

[Chitrang Srivastava]

Hi,

I am implementing HTTPs server using openssl 1.1.1b.
Is it mandatory to setup these API's while creating ssl context ?

SSL_CTX_set_tmp_ecdh

SSL_CTX_set_tmp_dh

Also any suggestion what all options one should set while setting up server
like
SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3

Thanks,

Re: Compile EC(Elliptic Curve) crypto

[Chitrang Srivastava]

Thanks,
I will check out.



On Mon, Jun 3, 2019 at 6:18 PM Jakob Bohm via openssl-users <
openssl-users@openssl.org> wrote:

> On 03/06/2019 14:35, Chitrang Srivastava wrote:
> > Hi,
> >
> > I am porting Openssl 1.1.1b for an embedded platform.
> > I see that EC folder generate some of function in assembly for e.g
> > These functions are generated based on environment like
> > x86-64/ppc/armv8 etc.
> > Is there any C version of these function to use directly ?
> > Thanks,
> >
> All algorithms etc. are available as C code, the assembler optimizations
> are used if they exist for a compilation target and have not been
> explicitly disabled with the configure option "no-asm".
>
> Because embedded platforms often have slow CPUs, keeping the assembler
> optimizations enabled is especially advantageous on such systems.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, 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
>
>

Compile EC(Elliptic Curve) crypto

[Chitrang Srivastava]

Hi,

I am porting Openssl 1.1.1b for an embedded platform.
I see that EC folder generate some of function in assembly  for e.g
These functions are generated based on environment like x86-64/ppc/armv8
etc.
Is there any C version of these function to use directly ?

Thanks,

Re: rand interface while upgrading openssl

[Chitrang Srivastava]

Thanks Michael,

I am using *ssleay_rand_add* function which was present in earlier version
of openssl
https://code.woboq.org/crypto/openssl/crypto/rand/md_rand.c.html#ssleay_rand_add

I don't find this file or function in latest version of openssl.
As I understood recommended way is to use engine method but on embedded
system we compile everything in a single elf binary.
No concept of dynamic shared object or engine , so i defined
OPENSSL_NO_ENGINE to compile engine thing out.

Is there any default random number like md_rand.c in this version of
openssl.
For entropy we will be providing SHA1/SHA2 of a mix of CPU clock and
various other thing(serial #, mac, ) to seed.

-Thanks,

On Wed, Apr 17, 2019 at 1:23 AM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Chitrang Srivastava
> > Sent: Tuesday, April 16, 2019 08:24
>
> > I need suggestion regarding random number interface , earlier we were
> using  RAND_METHOD.
>
> That's a mechanism for telling OpenSSL what mechanism to use for its
> cryptographically-strong pseudorandom number generator (CPRNG).
>
> > Can I still use the same mechanism? Because I see new code rand folder
> contains OS specific
> > implementation of
> >
> > rand_pool_acquire_entropy
> > rand_pool_add_nonce_data
> > rand_pool_add_additional_data
>
> That's part of OpenSSL's mechanism for getting entropy for the CPRNG. The
> CPRNG needs this, but they are not the same thing.
>
> > As I understand , above function also needs to be ported?
>
> I believe you'll need some implementation of them, but I haven't poked
> around this corner of the OpenSSL 1.1 sources.
>
> > Any document to start with porting random number to any platform.
>
> The CPRNG seeding mechanism is cryptographically sensitive, and should not
> be implemented by a non-expert. What does your existing implementation do
> to provide entropy for the OpenSSL CPRNG? If the answer is "nothing" (or
> something that's not adequately opaque to an attacker), then your product
> has seriously flawed security. An attacker who can guess the entropy for
> the CPRNG pool can break your encryption.
>
> It will also be platform-specific (though some mechanisms will exist on
> multiple platforms), so there can't be much guidance on doing it for "any
> platform".
>
> The literature on seeding CPRNGs is fairly extensive. It's often a
> challenge for embedded applications, particularly SOC-based ones which may
> not have much in the way of internal noise sources such as clock skew. Some
> CPUs have entropy sources, such as Intel's RDRAND; if you trust them (and
> in an embedded application you may not have much choice) you can use that.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>

rand interface while upgrading openssl

[Chitrang Srivastava]

Hi,

I am trying to upgrade openssl for my embedded OS platform. The one we
currently use is pretty old i.e. *OpenSSL  0.9.6a * , but porting to
Openssl 1.1.1b works fine.

I need suggestion regarding random number interface , earlier we were
using  RAND_METHOD.
Can I still use the same mechanism? Because I see new code *rand* folder
contains OS  specific implementation of

rand_pool_acquire_entropy
rand_pool_add_nonce_data
rand_pool_add_additional_data

As I understand , above function also needs to be ported?
Any document to start with porting random number to any platform.

Thanks