emulating "good old" des commands behaviour using "openssl des"
Jochen...@acm.org
A customer of mine receives encrypted files from a market data supplier.
(Yes, it belongs to the mayor ...)
So far we have been decoding files like this using Eric Young's "libdes" and "des" utility v 4.01,
and I thought it would be a good idea to start using uptodate software,
i.e. to use "openssl enc -d ..." instead.
So this is how we UU-decode and decrypt our files in one go:
des -u -D -k 'our_key' input-file output-file
This is wrapped up in shell script downloading and decrypting files and sleeping for a while all day all week ...
and it has been working fine for quite a while,
until a non IT-person broke my shell script with a "cuckoo's egg",
and that was quite a terrible experience,
as it delayed production for several hours.
That cuckoo's egg was a file, that wasn't UU-encoded (-> "-u") at all.
All right, I thought, let's split the job into to halves and look whose fault it is:
uudecode -d /dev/stdout < input-file |
des -D -k 'our_key' > output-file
... and I found, that uudecode does a proper job,
but "des" has a problem with empty files.
So this is a simple but rather time consuming and never ending job on our machine:
des -D -k 'our_key' < /dev/null
Instead of debugging the code of this "des" utility
I thought it would be far better to start using "openssl enc -d ..."
(hoping the problem had long be removed),
and this is how I tried it:
openssl enc -d -des -d -k 'our_key' -in input-file -out output-file
But it told me:
bad magic number
I also tried "-des-cbc", "-des-cfb", "-des-ecb", "-des-ofb", but with no success.
Maybe "openssl enc -d ..." can not do what "des -D ..." did??
Or maybe I have just not tried the right approach?
"Polite criticisms and good answers would be appreciated."
Thank you!
J.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dr. Stephen Henson
> Salutation
>
> A customer of mine receives encrypted files from a market data supplier.
> (Yes, it belongs to the mayor ...)
>
[snip details]
> But it told me:
>
> bad magic number
>
> I also tried "-des-cbc", "-des-cfb", "-des-ecb", "-des-ofb", but with no success.
>
> Maybe "openssl enc -d ..." can not do what "des -D ..." did??
> Or maybe I have just not tried the right approach?
>
> "Polite criticisms and good answers would be appreciated."
>
Short answer: try the -nosalt option.
Long answer...
Including the key on the command line can be problematical on some systems if
someone can run ps.
DES doesn't provide any real security any more and can be cracked with fairly
moderate computing power with modern systems.
If its an option redoing the whole thing would be advisable.
The old way that enc/dec worked was vulnerable to dictionary attacks so the
default format was made more secure using a salted algorithm. This removes the
security problem but makes it incompatible with the old format. Mixing the two
results in that error message.
Having just looked at the manual page I see that it hasn't been updated, ugh.
Anyway if you want compatibility with the old format use the -nosalt option.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
Jochen Hayek
> On Wed, Jul 07, 2004, Jochen Hayek wrote:
[snip details]
SH> Including the key on the command line can be problematical on
SH> some systems if someone can run ps.
You are definitely right, but we don't really understand,
why Bloomberg encrypts the data in the first place,
so on *our* *local* machine we don't regard the key as a secret.
But because you are right anyway, I take it as a finger exercise,
to let openssl take the key from a file.
SH> DES doesn't provide any real security any more and can be
SH> cracked with fairly moderate computing power with modern
SH> systems.
SH> If its an option redoing the whole thing would be advisable.
You are right, but we are not in a position to ask Bloomberg to do it right,
and then apparently they had "some trouble" being able to "export that crypto technology" a couple of years ago
and for some reason they fear the effort.
[snip details]
Thanks for your help!
J.
Jochen Hayek
Alright, using "-des-cfb" or "-des-ofb" I don't get the "bad decrypt" error message,
but still:
$ des -D -k 'our_key' < in_file > out_file.generated_using_des_utility
$ openssl enc -des-cfb -pass 'pass:our_key' -d -nosalt < in_file > out_file.generated_using_openssl_des_cfb
$ openssl enc -des-ofb -pass 'pass:our_key' -d -nosalt < in_file > out_file.generated_using_openssl_des_ofb
$ cmp out_file.generated_using_des_utility out_file.generated_using_openssl_des_cfb
... differ: char 1, line 1
$ cmp out_file.generated_using_des_utility out_file.generated_using_openssl_des_ofb
... differ: char 1, line 1
$ cmp out_file.generated_using_openssl_des_cfb out_file.generated_using_openssl_des_ofb
... differ: char 1, line 1
Maybe the emulation of "des -D" is quite a little different to "des -d" and not as easily solvable.
FYI: This is from des's manual page:
-e Encrypt data using an 8 byte key in a manner compatible with sunOS des(1).
-E Encrypt data using a key of nearly unlimited length (1024 bytes). This will product a more secure encryption.
-d Decrypt data that was encrypted with the -e option.
-D Decrypt data that was encrypted with the -E option.
BTW:
size file name
79653 out_file.generated_using_des_utility
79656 out_file.generated_using_openssl_des_cfb
79656 out_file.generated_using_openssl_des_ofb
79656 in_file
Cheers
