> From: owner-openssl-us...@openssl.org On Behalf Of Gary > Sent: Thursday, 16 September, 2010 08:57
> I asked this on the php users ml yesterday, but I think nobody there > knows the answer. I hope there might be one or two php coders here who > can help me out (yeah, I know, "I'd love to. Which way did you come > in?"). > > Basically I have a spec which says "If you encrypt a file with this > command line > ,---- > | openssl enc -e -aes-256-cbc -k <some key> ... > `---- > decryption will magically work on the receiver's end." > > Sadly the server I am using doesn't have openssl installed, > but the php > installation is configured with -with-mcrypt=shared so I am trying to > use that instead. > Sorry I know almost nothing about php, or mcrypt. But just reasoning from general principles: > Can anyone tell me what the equivalent to above command is, using the > mcrypt_* functions, please? > > I tried > ,---- > | $iv = mcrypt_create_iv(mcrypt_get_block_size(MCRYPT_RIJNDAEL_256, > | MCRYPT_MODE_CBC), > | MCRYPT_DEV_RANDOM); > | $encryptedData = mcrypt_cbc(MCRYPT_RIJNDAEL_256 > | ,$passphrase > | ,$data > | ,MCRYPT_ENCRYPT > | ,$iv); > `---- > amongst other things, but it doesn't work, I get "bad magic number" > when I tried to decrypt the contents of $encryptedData using > ,---- > | openssl enc -d -aes-256-cbc -k <passphrase> ... > `---- > (which I am doing at this stage in order to test that the receiver > will be able to decrypt it). > First I ass-u-me you are transporting encryptedData by means that preserves binary data, since your previous question involved that. > Yeah, bad magic number, naughty magic number, go and stand in the > corner. Seriously. WTH is that supposed to mean?! > > I also tried not using an iv but mcrypt slapped my wrist for being > presumptious enough to try it. > if it's using an explicitly random IV like that, it *can't* be compatible with openssl enc's default. Such an IV must be transmitted with the data, but 'enc' uses an IV derived from the passphrase. 'enc' also by default uses salt in the key/IV derivation, and while that could be implicit, it would be very odd to make the IV explicit but the salt implicit. "bad magic number" from enc -d means that it didn't find the prefix in the file with the stored salt, so if mcrypt here is using salt at all it isn't doing it the same way. Are you certain that mcrypt_cbc call takes a passphrase and not an actual key? Generally password-based schemes either use a separate call like OpenSSL's EVP_BytesToKey or a different algname something like PBEwithSHA1andAES and in general may need parameters with such algnames. You might try mcrypt-encrypt with a fixed/known *key* and IV, and have openssl try raw (not PBE) decryption: openssl enc -alg -d -K keyinhex -iv IVinhex -nosalt # note that's uppercase -K (I would actually do AES128 or even 1DES if supported/ allowed, to make the values more convenient.) If that works, and you want/need OpenSSL's PBE scheme, you must get mcrypt to use the same key/IV derivation, and either include salt using the openssl format, or tell the receiving openssl -nosalt. OpenSSL's scheme is PKCS#5v1 without iteration, which is really just one or two MD5's. mcrypt might have PKCS#5v1 as such available, or MD5, or you can just take the reference code from RFC1321 and modify as needed. Aside: I wonder why get_block_size takes mode as well as algorithm. There are stream modes that effectively *ignore* the primitive's blocksize, but I don't know of any that actually use a *different* blocksize. Maybe they're just trying to futureproof. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
