No idea on OpenVPN, I guess you could ask them directly : ) > On 26 Jul 2017, at 18:38, SaAtomic <saato...@keemail.me> wrote: > > > Thank you for the elaboration and the link. > One more follow-up question :) > > With OpenVPN, when I configure a TLS cipher suite like > `TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256`, I never manually created an ECC > private key. > You mentioned that this is required for such cipher suites. Does in this case > OpenVPN take over that task, or is that yet another special case? > > Kinds regards, > SaAtomic > > 26. Jul 2017 10:39 by paulyang....@gmail.com <mailto:paulyang....@gmail.com>: > > > On 26 Jul 2017, at 16:21, SaAtomic <saato...@keemail.me > <mailto:saato...@keemail.me>> wrote: > > The subject is much clearer to me now, thank you. > > The EC key you mentioned is not created manually, correct? > This key is a result of ECC, which is done by OpenSSL. > > So if I set up a server offering TLS connections and only offer ECDH/ECDHE, > no additional data has to be generated manually, correct? > > Ahh, that depends on how you use ECC in TLS. If you use something like > ‘ECDHE-RSA-XXX-YYY’, you don’t need to manipulate the ECC stuff ‘manually’, > since the authentication part of that cipher suite is RSA, just preparing an > RSA key/certificate is enough. But if you want to use stuffs like > ‘ECDHE-ECDSA-XXX-YYY’, you need to prepare ECC private key (and also the > corresponding certificate that encodes the ECC public key). For ECDH ciphers > (without the ‘E’ part), that’s more confused, IIRC, in such case the > authentication part of that kind ciphers indicates what signature algorithm > is used to sign the certificate, but not the ‘public-key-type’ in the > certificate, so anyway you probably need to get a ECC key/certificate pair. > But the without-‘E’ version of such usage seems rare, I have never meet one > in production environment... > > And also, don’t mix up the ECC keys used in a `key exchange’ phase during TLS > handshake with the keys used in ‘auth’ phase. I suggest you to read the > following RFC documentation to get clear understandings on this: > https://www.ietf.org/rfc/rfc4492.txt <https://www.ietf.org/rfc/rfc4492.txt> > > Hope it helps : ) > > > Kind regards, > SaAtomic > > > 26. Jul 2017 10:14 by paulyang....@gmail.com <mailto:paulyang....@gmail.com>: > > On 26 Jul 2017, at 15:56, SaAtomic <saato...@keemail.me > <mailto:saato...@keemail.me>> wrote: > > Thanks for the reply. > I'm still not sure I understand this correctly. > > So the length of modulus is the essential part, determining the security of > the DH, right? > > Mostly. > With ECC, this is defined by the used curves. > Without ECC, this is determined by the DH parameters (from the .pem file I > mentioned). > > If a server only supported ECDH or ECDHE, the DH parameters (.pem) file > wouldn't even be needed. > > Yes, in that case, you only need an EC key (and also EC parameters to > generate this key, of course) > > Is this correct? > > Thank you for your help, > kind regards, > SaAtomic > > --------- > > Paul Yang paulyang.inf at gmail.com <http://gmail.com/> > > Wed Jul 26 07:19:31 UTC 2017 > > The ‘key size’ concept is usually referred to the length of modulus. (In > > public key crypto area) > > For DH and ECDH, it (the size) ’s generated and defined in the > > ‘parameters’, as you pasted. Parameters are not exactly the final ‘keys’, > > they are the ‘materials’ to produce keys (both private ones and public > > ones), either for DH or ECDH. For DH, you generate parameters based on a > > given length of prime, and this length is what you called ‘key size’ (e.g. > > 2048), for ECC the parameters are generated based on named curves, such as > > prime192v1/prime239v1..., in this case, the ‘key > size’ is 192/239bit. In > > both case, the prime numbers are used as modulus being used while doing DH > > or EC crypto calculations... > > > > If you get either a DH or EC key, you could use the following command of > > OpenSSL to check the ‘key size’: > > > > openssl pkey -in xyz.key -noout -text > > > > check the Private-Key: (xxxx bit) in the output. >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
