t's a server installed many many years ago and there are
applications which are no used.
Server is too late and I have new server
(latest Centos 6) for migrating where I installed latest version.
I'd
like to take to new server all certificate database (certificated
included) which I created.
On 6/6/2018 12:11 PM, Sanjaya Joshi wrote:
> I understood that when DHE ciphers are tried to be used between two
> entities, it's only the server that plays a role about selection of
> the DH parameters. This is not negotiable with the client. For e.g.,
> the server can freely use a very low
> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users
> wrote:
>
> Without commenting on whether or not your understanding is correct (the
> client gets the params and can see how big the key is, no?), I will point out
> that the way DHE works is defined by the IETF RFC’s, and they
Without commenting on whether or not your understanding is correct (the client
gets the params and can see how big the key is, no?), I will point out that the
way DHE works is defined by the IETF RFC’s, and they have not changed.
--
openssl-users mailing list
To unsubscribe:
On 06/06/2018 09:12 PM, openssl-users-requ...@openssl.org digestributed:
> Date: Wed, 6 Jun 2018 16:12:59 +
> From: Michael Wojcik
>
>> Hence my solution of using a hardware TRNG shared over the
>> network with devices that lack the ability to have one added
>> locally.
>
> Yes, I think
Hello,
I understood that when DHE ciphers are tried to be used between two
entities, it's only the server that plays a role about selection of the DH
parameters. This is not negotiable with the client. For e.g., the server
can freely use a very low not-recommended DH group with 512 bit key length
> From: openssl-users on behalf of Jakob
> Bohm
> Sent: Tuesday, June 5, 2018 02:46
> Hence my solution of using a hardware TRNG shared over the
> network with devices that lack the ability to have one added
> locally.
Yes, I think that's a good approach. It reduces the attack surface, since
