Salutation
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 [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
