> From: owner-openssl-us...@openssl.org On Behalf Of redpath
> Sent: Thursday, 01 November, 2012 13:07
> I have written AES encryption which uses salt
>
*password-based* with salt, as you correctly say for Java below.
> int nrounds=5;
> unsigned char salt[]= {1,2,3,4, 5,6,7,8};
> unsigned char key[32], iv[32];
>
> unsigned char *key_data="password";
> int key_data_len= 8;
>
> i = EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha1(), salt, key_data,
> key_data_len, nrounds, key, iv);
>
> Sample code supplied for this.
>
EVP_BytesToKey uses original PKCS#5, retronymed PBKDF1,
up to the hash size (16 or 20 bytes) and a nonstandard
extension beyond that. AES-256-CBC requires 48 bytes.
> I am required to use Java to decrypt the openssl encrypted
> salted password AES
> so I wrote Java code to encrypt and decrypt using salt. I
> cannot figure out what are the
> parms for the salt to get the same results of encryption as I get with
> openssl.
>
Salt is not the problem, it's one of the few things you have right.
<snip example and code>
Your Java codes uses PBKDF2WithHMACSHA1. This is a different
algorithm, although designed on somewhat similar principles.
As far as I can find, Suncle Java with the standard providers
does not provide PBKDF1 as a primitive, although it provides
a few (older) PBE encryptions I'm pretty *include* KDF1.
I'm certain it doesn't provide OpenSSL's extended-KDF1.
OTOH, OpenSSL (evp.h) also provides PKCS5_PBKDF2_HMAC_SHA1
(or optionally other hash), and that is compatible with Java.
Also, your Java code uses AES-128, and a default (random)
IV rather than the PB-generated IV. While random IV may
actually be preferable, it must be implemented (compatibly)
at both ends and transmitted or stored with the ciphertext.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
