Hi,
Thank you for the clarifications.
Regards,
Sanjaya
On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm wrote:
> (Top posting for consistency).
>
> Once the client receives the TLS1.2 servers choice of DH group,
> it can either accept it or abort the connection.
>
> However if both client and server
(Top posting for consistency).
Once the client receives the TLS1.2 servers choice of DH group,
it can either accept it or abort the connection.
However if both client and server support the "supported_groups"
extension (RFC4492) with the additional DH group identifiers in
RFC7919, they can
Hello,
Thank you Matt and Jordan. So, it seems that it's possible to modify my
client to accept/reject the DH group key length. But i have one more issue
to be clarified.
Is it possible that if a client does not accept the DH group key length
used by the server, then, a different possible cipher
On 07/06/18 16:02, Jordan Brown wrote:
> I do not understand, however, how the 80 relates to a 1024-bit limit.
It's a measure of the "security bits" of an algorithm according to table
2 in this doc:
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
Matt
--
On 6/6/2018 11:22 PM, Sanjaya Joshi wrote:
> >>Current OpenSSL isn't willing to connect to a server using a DH key size
> below 1024 bits.
> Yes, i have verified this. However, not sure, how my OpenSSL-based
> client can do this, as our requirement is that we must not use DH key
> size below 2048
On 07/06/18 04:10, Viktor Dukhovni wrote:
>
>
>> 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
Hello,
Thank you all for your responses. I forgot to mention that we are on
OpenSSL 1.1.0 and TLS 1.2.
I have some more queries though.
>>Current OpenSSL isn't willing to connect to a server using a DH key size
below 1024 bits.
Yes, i have verified this. However, not sure, how my OpenSSL-based
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:
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
11 matches
Mail list logo
