RE: About the encrypted premaster length.
> -Original Message- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Dave Thompson > Sent: Thursday, August 23, 2012 2:31 AM > To: openssl-users@openssl.org > Subject: RE: About the encrypted premaster length. > > > From: owner-openssl-us...@openssl.org On Behalf Of Tayade, Nilesh > > Sent: Wednesday, 22 August, 2012 16:13 > [...] > Only for RSA key-exchange (which is the most commonly used). > For DH* and ECDH* suites ClientKeyExchange is quite different. > (Not to mention Kerberos or PreShared.) [...] > > If I am correct, the length depends upon the RSA key size > > (128bytes for 1024bit key). Is there some way to know before > > hand if the RSA key being used is 1024bits or different (some > > information in certificates etc.)? So that based on that I > > could look for the encrypted premaster length. > > > Yes, an RSA EncryptedPremaster value is the same size as the > server's RSA public key, in and taken from the server's cert. > (Or to be exact, the same size as the modulus in the key; > the public key as distributed contains some additional data, > usually only a little, and thus is slightly larger.) > > But you don't need to "look for" the length of this value. > It is encoded as a vector in SSL/TLS, which means it has a > length prefix right in the protocol message. See 4.7 and 4.3 > in RFC5246 (likely the same earlier, but I didn't re-check). > And it's the only field in the (CKE) message which has a length > header, and typically that message is the only message in the > (handshake) record which as a length header. Thanks, yes the initial bytes denote the length. I have another basic question. Does the size of decrypted premaster always remain 48bytes (irrespective of encrypted premaster is 128bytes or 256bytes)? I tried decrypting the encrypted_premaster as RSA_private_decrypt(length, encrypte_premaster, decrypted_premaster, rsa, RSA_PKCS1_PADDING) and it resulted into 48bytes decrypted premaster even for the length = 128bytes. -- Thanks, Nilesh __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Tables for handling various non-blocking I/O errors
For my own benefit and that of others, I made a page at http://jmarshall.com/stuff/handling-nbio-errors-in-openssl.html listing various error conditions after SSL_accept(), SSL_connect(), SSL_read(), SSL_write(), and SSL_shutdown(), all on *non-blocking* sockets. The tables show what to do after the given function returns the given result, also considering the response from SSL_get_error(). The info is consolidated from the docs for those six functions. I'm new to OpenSSL, so I'd love it if someone who knows this stuff could review it. Corrections, additions, and suggestions all very welcome. Thanks! James
RE: About the encrypted premaster length.
> From: owner-openssl-us...@openssl.org On Behalf Of Tayade, Nilesh > Sent: Wednesday, 22 August, 2012 16:13 > The 'Client Key Exchange' packet carries the encrypted > premaster. I am working on utility for decrypting the data > and supported cipher suites are RC4_128_MD5 and RC4_128_SHA. > Only for RSA key-exchange (which is the most commonly used). For DH* and ECDH* suites ClientKeyExchange is quite different. (Not to mention Kerberos or PreShared.) > I observed that the encrypted premaster length varies in the > 'Client key exchange' packet. Sometimes it is 128bytes and > sometimes 256bytes. > If I am correct, the length depends upon the RSA key size > (128bytes for 1024bit key). Is there some way to know before > hand if the RSA key being used is 1024bits or different (some > information in certificates etc.)? So that based on that I > could look for the encrypted premaster length. > Yes, an RSA EncryptedPremaster value is the same size as the server's RSA public key, in and taken from the server's cert. (Or to be exact, the same size as the modulus in the key; the public key as distributed contains some additional data, usually only a little, and thus is slightly larger.) But you don't need to "look for" the length of this value. It is encoded as a vector in SSL/TLS, which means it has a length prefix right in the protocol message. See 4.7 and 4.3 in RFC5246 (likely the same earlier, but I didn't re-check). And it's the only field in the (CKE) message which has a length header, and typically that message is the only message in the (handshake) record which as a length header. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
About the encrypted premaster length.
Hi, The 'Client Key Exchange' packet carries the encrypted premaster. I am working on utility for decrypting the data and supported cipher suites are RC4_128_MD5 and RC4_128_SHA. I observed that the encrypted premaster length varies in the 'Client key exchange' packet. Sometimes it is 128bytes and sometimes 256bytes. If I am correct, the length depends upon the RSA key size (128bytes for 1024bit key). Is there some way to know before hand if the RSA key being used is 1024bits or different (some information in certificates etc.)? So that based on that I could look for the encrypted premaster length. -- Thanks, Nilesh __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AES-CMAC-128 equivalent to EVP_aes_128_cbc sent to CMAC?
Hi folks, Thanks for your help with previous questions. I have a new one, which should hopefully be quick: In implementing AES-CMAC-128 over a message, I assumed it would be equivalent in OpenSSL to hand the EVP_aes_128_cbc() EVP_CIPHER to CMAC, as I did not see a regular AES-128 EVP_CIPHER availble. Perhaps this is incorrect, but it seems as if there are only a variety of modes of AES available to send to CMAC, rather than the most "basic" version of the cipher. Is there just a generic AES-128 EVP_CIPHER available to pass as an arg to CMAC? Thanks for insight. Cassie __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Generation ECDHE parameters
Hi We are in the process of adding support for ECDSA-ECDHE cipher suites and hence ECDSA certificates to our server. Right now, the server does the following: 1) Assign the ECDSA certificate to the SSL_CTX. 2) Set the callback for ECDH parameter generation using SSL_CTX_set_tmp_ecdh_callback. In ssl3_send_server_key_exchange, when this callback is called, the value of 'keylength' parameter is always either 512 or 1024. Shouldnt 'keylength' have the curve name or id in the case of ECDH? Are we doing something wrong here? Thanks Varma
Re: What exactly does the -binary switch do when creating s/mime output?
On 21 Aug 2012, at 2:39 PM, Bart W Jenkins wrote: > Given: > > openssl smime -binary -sign -passin "pass:SomePassword" -signer cert.pem > -inkey key.pem -in Document.txt -out Document.txt.sig -outform DER > > What *exactly* is done to the s/mime text to create a "binary" file? Are you asking about the "-binary" flag to "openssl smime" or about the encoding of the encrypted/signed file? I think the only difference "-binary" makes is whether the plaintext's line-endings are converted to/from the local convention vs. the network-standard CRLF. Glancing at the source code, the only things that flag affects are the mode argument of fopen() and an internal function that canonicalizes line endings (rather, if "-binary" is given, it does not canonicalize line endings). > I'm trying to do the equivalent in Java using BouncyCastle and just can't get > from a text based PEM file to a binary/DER file. That's controlled by the "-outform DER" flag to openssl, not "-binary". PEM is simply base64-encoded DER with header and footer lines added; it has nothing to do with whether the data inside the crypto blob is "binary" or not. I'm not familiar with the BouncyCastle APIs, but I'm guessing they generate DER internally and then convert that to PEM. If you want DER, just remove or disable that last conversion. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock in multi-threaded OpenSSL FIPS 2.0
On Wed, Aug 22, 2012, Seiichi Tatsukawa wrote: > We are seeing the deadlock in FIPS 2.0. (1.0.1c + fips-2.0 and using > AES256-SHA256 if that matters.) DRBG's auto reseeding (after 2^24 operations) > causes it. Here is the simplified backtrace. > > fips_drbg_bytes() > CRYPTO_w_lock(CRYPTO_LOCK_RAND) > FIPS_drbg_generate() > drbg_reseed() >fips_get_entropy() > drbg_get_entropy() > ssleay_rand_bytes() > CRYPTO_w_lock(CRYPTO_LOCK_RAND) > > Obviously, a simple workaround is to register the locking callback that uses > the recursive lock (e.g., PTHREAD_MUTEX_RECURSIVE_NP). However, I can't find > such locking requirement in OpenSSL FIPS 2.0 User Guide. (And w/o FIPS 2.0, > OpenSSL clearly avoids the recursive lock.) > > Are we not initializing FIPS properly? If so, what's missing? (We are not > registering our own entropy callbacks.) Or, is this a simple oversight in > FIPS locking??? > Thats a bug in the FIPS capable OpenSSL. It should be using a version of ssleay_rand_bytes() which doesn't use a CRYPTO_LOCK_RAND lock. I'll look into fixing it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Entropy for OpenSSL
I'm looking at https://groups.google.com/forum/?fromgroups#!topic/mailing.openssl.users/j8O bkLf6xgs Do I interpret it correctly as saying that assuming I do not have some clever source of entropy of my own, that I should just "do nothing" and let OpenSSL do what it decides is best? In other words, that I should NOT call app_RAND_load_file() (as the current source for s_client does) nor RAND_screen() (as O'Reilly sort-of advises)? Thanks, Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Deadlock in RAND_poll's Heap32First/Heap32Next call
Hi all, We (and a couple of others) had faced this issue on Windows 7 and Windows 2008 systems. We raised the issue with MS and very recently they released a hotfix to address the problem in Ntdll.dll. If you ever face the issue, please install the hotfix from http://support.microsoft.com/kb/2719306 Thanks Sandeep
Re: Using variable length Blowfish key with command line
On Tue, Aug 21, 2012, Nathan McCrina wrote: > On 08/21/12 23:04, Dave Thompson wrote: > >>From: owner-openssl-us...@openssl.org On Behalf Of Nathan McCrina > >>Sent: Tuesday, 21 August, 2012 21:31 > > > >Not in commandline; in library it's fine. > >See http://marc.info/?l=openssl-users&m=134463726501144&w=2 > >for the similar but undocumented RC4 case, and adjust. > > > > > > Oh dear. O.o > > I'll see if I can figure it out, haha. Onward and upward! And thank you. See the parameter setting examples in: http://www.openssl.org/docs/crypto/EVP_EncryptInit.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL DES generates '\n' in encrypted code
We are beating this to death but one problem is that the encoded string is not an exact number even of *bits* (except for favorable values of 'n'). I don't know what is so fascinating about this problem but I was thinking about it again this morning. There may be 94 *possible* characters but any given string has at most 24 unique characters. I don't know if it is possible to exploit that fact in some way. It also occurred to me that perhaps the OP does not *really* need encryption. If so, there are "obfuscation" techniques that would be much simpler to implement than encryption and might satisfy management, auditors, or whoever is driving this requirement -- and would inherently produce "printable" output of 24 characters. They would make the string not obviously a password, social security number, or whatever it is now. If the OP is interested, please respond and I will elaborate. Keep in mind than an awful lot of homegrown encryption implementations are a lot weaker than they seem. You can use AES256, but if the key is stored in some file that would be relatively easy for a rogue employee to get into, then your security is a lot "less than AES256." Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ben Laurie Sent: Tuesday, August 21, 2012 1:47 PM To: openssl-users@openssl.org Subject: Re: OpenSSL DES generates '\n' in encrypted code On Tue, Aug 21, 2012 at 2:14 PM, Charles Mills wrote: > Actually, there IS *almost* a general solution to this problem. > > The input consists of characters from some set of 'n' characters. (Perhaps 'n' is 94 -- 0x21 through 0x7e inclusive -- but it does not matter.) You need to pack those characters with maximum density. It's conceptually the easiest if 'n' is 64, but basically you convert each character to an integer from 0 to 'n', and multiply the first character's value times the second's times the third's, etc., until you have done all 24. You have a problem dealing with the leftover bits when you overflow whatever size integer your system supports, but it is a solvable problem. (Perhaps OpenSSL BN will help with this; I don't know.) Now you end up with a string of somewhat less than 24 bytes: 18 if 'n' is 6, 20 if n is 94. (Actually 19.2 bytes, which is going to be the problem.) > > Encrypt the 20 bytes (into 20 bytes). Now reverse the process: divide the result by 'n' and represent the remainder as one of your 'n' legal characters; repeat until you have converted the whole string. Unfortunately, because of that leftover .8 byte you are going to end up with 25 characters. *Almost* a solution. > > If you can figure out a way to encrypt 19.2 bytes into 19.2 bytes rather than 20 you have it solved. Doesn't CFB mode work at the bit level? Also, CTR mode can be used for partial bytes. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Deadlock in multi-threaded OpenSSL FIPS 2.0
We are seeing the deadlock in FIPS 2.0. (1.0.1c + fips-2.0 and using AES256-SHA256 if that matters.) DRBG's auto reseeding (after 2^24 operations) causes it. Here is the simplified backtrace. fips_drbg_bytes() CRYPTO_w_lock(CRYPTO_LOCK_RAND) FIPS_drbg_generate() drbg_reseed() fips_get_entropy() drbg_get_entropy() ssleay_rand_bytes() CRYPTO_w_lock(CRYPTO_LOCK_RAND) Obviously, a simple workaround is to register the locking callback that uses the recursive lock (e.g., PTHREAD_MUTEX_RECURSIVE_NP). However, I can't find such locking requirement in OpenSSL FIPS 2.0 User Guide. (And w/o FIPS 2.0, OpenSSL clearly avoids the recursive lock.) Are we not initializing FIPS properly? If so, what's missing? (We are not registering our own entropy callbacks.) Or, is this a simple oversight in FIPS locking??? --- Seiichi __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
What exactly does the -binary switch do when creating s/mime output?
Given:
openssl smime -binary -sign -passin "pass:SomePassword" -signer cert.pem -inkey
key.pem -in Document.txt -out Document.txt.sig -outform DER
What *exactly* is done to the s/mime text to create a "binary" file?
I'm trying to do the equivalent in Java using BouncyCastle and just can't get
from a text based PEM file to a binary/DER file.
(and no, issuing a call to
SMIMESignedGenerator.setContentTransferEncoding("binary")) does NOT do the
equivalent.
Any help would be appreciated.
Bart
