On 9/9/2011 10:13 PM, krishnamurthy santhanam wrote:
I am implementing SSL on server side to authenticate the client certificate(X.509) and also client will authenticate the servers certificate(X.509). Once the mutual authentication has completed server has to generate AES key for encryption and decryption.In server side I am creating 256 bits AES key for encrypting the plaintext using C programming using OpenSSL. AES_KEY aeskey; RAND_bytes(key32,sizeof(key32)); AES_set_encrypt_key(key32, 32*8,&aeskey); AES_cbc_encrypt(inbuf, outbuf, 16,&aeskey, iv, AES_ENCRYPT); I have to decrypt the same message in Client side. Client side I am using JAVA Programming. 1. How i can send this AES key to JAVA client? or 2. How can derive common AES key on both side? 2. Can i use Password Based Encryption to derive the common keys for both side(JAVA and C)? Thanks, Krish
The normal way to do this is: 1. On the side running openssl, just let openssl handle the entire process, including any AES (or other negotiated algorithm) encryption in both directions with all the required precautions about key reuse etc. If you insist on at least 256 bit AES, set options in openssl parameters to only accept ciphersuites with strong enough ciphers. 2. On the side running Java, just let the standard SSL classes in Java (I forgot their names, see the JDK docs) handle the entire process in the same way. If you insist on at least 256 bit AES, set options in java SSL class parameters to only accept ciphersuites with strong enough ciphers, or if that is not possible, check the ciphersuite chosen after handshake and abort if not strong enough for your purpose. If on the other hand you are using an already encrypted and authenticated SSL channel to exchange encryption keys for some other use outside the SSL protocol, you need to know *A LOT* about security and cryptography to avoid making an insecure system. Once you know all that (which is very little about APIs and very much about the tricky ways such a system might be attacked), design the details (language and API independent) of how you will generate, use and protect your extra encryption keys. Then send your detailed protocol design (under NDA if applicable) to one or more highly experienced professional cryptographers for review. You will probably have to pay them (I did for my design and the response resulted in minor tweaks to my design before release). The whole learning and designing process took me 3 to 10 years depending on how much I include in the process. After all this (very necessary!) learning, design and review work, finding the right APIs to implement your protocol steps in various libraries should be trivial. (It ended up being mostly a matter of looking stuff up in the low level documentation and comparing function descriptions with my acquired knowledge of cryptographic security). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
