Re: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM)
On Fri, Nov 04, 2016 at 10:03:21AM +0530, Akshar Kanak wrote: > Dear team > as per the documnet http://csrc.nist.gov/groups/ > STM/cmvp/documents/fips140-2/FIPS1402IG.pdf > page 150 , Its mentioned > The implementation of the nonce_explicit management logic inside the > module shall ensure that > when the nonce_explicit part of the IV exhausts the maximum number of > possible values for a given > session key (e.g., a 64-bit counter starting from 0 and increasing, > when it reaches the maximum value > of 2 64 -1), > *either party (the client or the server) that encounters this condition > triggers a handshake toestablish a new encryption key – see Sections > 7.4.1.1 and 7.4.1.2 in RFC 5246*. > > is this being handled by openssl ? in the source code of openssl i am > not able find out the > exact location where this renegotiation is initiated when the counter > over flows ? (my understanding might be limited) I think we currently do an error if the calling frontend does not initiate renegotiation. Code is here: crypto/modes/gcm128.c CRYPTO_gcm128_encrypt_ctr32 These kind of checks avoid the 32bit counter overflow: if (mlen > ((U64(1) << 36) - 32) || (sizeof(len) == 8 && mlen < len)) return -1; The calling instance needs to re-iv with CRYPTO_gcm128_setiv. For TLS, if I understand correctly, the stack does intiailize the GCM cipher with a new IV on every TLS record and these cannot be that large. Ciao, Marcus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Does the OpenSSL site has translation for error codes: Error code is: 12
Hi, I have been looking for a description of what certain error codes mean on the OpenSSL site, but could not found any. Earlier there used to be page for the error codes. I would like to know what exactly this error means: @20160901 11:09:17.372 #9768[.\emspopclient.cpp@960] EMSPOPClient::tlsconnect Server Response Network Layer Error- Error message is: X.509 certificate has invalid signature @20160901 11:09:17.372 #9768[.\emspopclient.cpp@960] EMSPOPClient::tlsconnect Server Response Network Layer Error code is: 12 The above is a trace from an OpenSSL client. Does it means that the certificate presented by the OpenSSL server is invalid OR The CA chain at the client is invalid OR The CRL is invalid If you do have page that list the error descriptions then it would be good. Thanks, Sahil -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Does the OpenSSL site has translation for error codes: Error code is: 12
On 04/11/2016 07:53, Rangari, Sahil (Sahil) wrote: Hi, I have been looking for a description of what certain error codes mean on the OpenSSL site, but could not found any. Earlier there used to be page for the error codes. I would like to know what exactly this error means: @20160901 11:09:17.372 #9768[.\emspopclient.cpp@960] *EMSPOPClient::tlsconnect Server Response Network Layer Error- Error message is: X.509 certificate has invalid signature* @20160901 11:09:17.372 #9768[.\emspopclient.cpp@960] EMSPOPClient::tlsconnect Server Response Network Layer Error code is: 12 The above is a trace from an OpenSSL client. Does it means that the certificate presented by the OpenSSL server is invalid OR The CA chain at the client is invalid OR The CRL is invalid If you do have page that list the error descriptions then it would be good. See https://www.openssl.org/docs/faq.html#PROG7 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM)
On 04/11/2016 09:26, Marcus Meissner wrote: On Fri, Nov 04, 2016 at 10:03:21AM +0530, Akshar Kanak wrote: Dear team as per the documnet http://csrc.nist.gov/groups/ STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 150 , Its mentioned The implementation of the nonce_explicit management logic inside the module shall ensure that when the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key (e.g., a 64-bit counter starting from 0 and increasing, when it reaches the maximum value of 2 64 -1), *either party (the client or the server) that encounters this condition triggers a handshake toestablish a new encryption key – see Sections 7.4.1.1 and 7.4.1.2 in RFC 5246*. is this being handled by openssl ? in the source code of openssl i am not able find out the exact location where this renegotiation is initiated when the counter over flows ? (my understanding might be limited) I think we currently do an error if the calling frontend does not initiate renegotiation. Code is here: crypto/modes/gcm128.c CRYPTO_gcm128_encrypt_ctr32 These kind of checks avoid the 32bit counter overflow: if (mlen > ((U64(1) << 36) - 32) || (sizeof(len) == 8 && mlen < len)) return -1; The calling instance needs to re-iv with CRYPTO_gcm128_setiv. For TLS, if I understand correctly, the stack does intiailize the GCM cipher with a new IV on every TLS record and these cannot be that large. Ciao, Marcus As I understand the GCM mode, the limitation is that the same IV must not be used twice, and only a limited number of all the possible IVs may be used before changing the *key*. Setting a "new" IV for each TLS record is always needed, regardless if it comes from a simple record counter or is transmitted for each record (the TLS RFCs presumable have a fixed choice for this). But to get a new *key* before too much data has been encrypted with it (such limits exist for *all* algorithms and modes), I believe that an actual TLS renegotiation is needed, involving at least a partial handshake without closing the connection. 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ?
On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote: > Hi, > > I'm curious. Why exactly do you want to change the shared library > version? I had to change the soname in Debian (because I dropped all SSLv2 and SSLv3 symbols) and changed it to 1.0.2. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] X25519 not listed in ecparam -list_curves
Hi, OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH -curves X25519 -connect google.com:443" works as expected, and I get "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the output of "openssl ecparam -list_curves" in version 1.1.0b (I use 1.1.0b-2 from Debian). Should it be listed there anyway? Regards, Viktor -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
