> From: owner-openssl-us...@openssl.org On Behalf Of Lutz Jaenicke > Sent: Tuesday, 10 May, 2011 13:47 > ----- Forwarded message from DUBUC Franck <franck.b.du...@socgen.com> ----- > To: "r...@openssl.org" <r...@openssl.org> > Date: Mon, 9 May 2011 17:12:45 +0200
> I create a encrypted file, with openssl, on unix server to > encrypted it on windows > As per below, you mean *de*crypt (or "un"crypt)on Windows > Version <snipped> > Command to encrypt the file on unix > > /usr/linux/bin/openssl enc -e -aes-256-cbc -salt -in > <<encrypted file>> -pass pass:<<PassPhrase>> > /usr/linux really? That's very unusual, though possible. /usr/local/* is much more common. -in here should be the *clear* file, and either redirect output to *encrypted* file or use -out to specify it. > Command to uncrypt the file on windows > > c:\openssl\openssl.exe enc -d -a -aes-256-cbc -salt -in > <<encrypted file>> -pass pass:<<PassPhrase>> > -a on decrypt is wrong unless -a was used on encrypt (or a separate base64 encoding step was done between) -salt is the default (on both encrypt and decrypt) so you don't need to specify it, but it does no harm if you do specify it. > Error to uncrypt it > unix to windows > error reading input file > This occurs if you encrypt without -a and decrypt with -a. > window sto unix > bad magic number > This occurs in the opposite case where you encrypt with -a and decrypt without -a. > > Is it a bug or is not possible to uncrypt a file crypted on unix ? > It is absolutely possible to encrypt on one system type and decrypt on another if you do it correctly. And with the same passphrase, of course. If you use anything other than ASCII alphanumeric and limited punctuation, be aware *entering* those characters on the command line of a Unix shell or Windows CMD can be problematic. If you allow openssl to prompt for the passphrase, all ASCII graphics should work, but controls and locale-dependent 'extension' (>=128) characters still may not. For "raw" encrypted data (no -a) the *transfer* of the encrypted file must be exact byte-for-byte, conventionally called "binary" or "image". In particular, FTP does NOT do this by default, especially not between Unix and Windows (but sometimes Unix-Unix also). Newer protocols like HTTP and SFTP, and NFS and SMB (Samba), do. It is usually sufficient to verify the filesize in bytes is the same. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
