Using openssl commandline tool from script
Gary
problems. What I am currently doing is:
,----
| echo -n <some data> | openssl enc -e -aes-256-cbc -k <some key>
`----
and then testing the result with
,----
| echo -n <encrypted data> | openssl enc -e -aes-256-cbc -k <some key>
`----
(obviously I should get back the data I started with).
More often than not it works fine, but sometimes the encryption will
produce output that contains values which echo (for the decrypt) balks
at.
I tried base64 en/decoding the data:
,----
| echo -n <some data> | openssl enc -e -aes-256-cbc -k <some key> -base64
`----
and
,----
| echo -n U2FsdGVkX1/EbpoczzWXJQC+RkTFvf7k2yL3LYWXCXrlDssu5p93tRAjtdODxBMa | openssl enc -d -base64 -aes-256-cbc -k <some key>
`----
and got "error reading input file" which I guess is because of the "/"
in the encoded and encrypted data. Any suggestions here?
Or is there a better solution to getting <some data> and <encrypted data>
into openssl than echoing it, without writing it to a file and
(preferably) without manipulating the data before passing it to openssl?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
> Sent: Tuesday, 14 September, 2010 11:20
> I am trying to call the openssl tool from a script, and I am
> having some
> problems. What I am currently doing is:
>
> ,----
> | echo -n <some data> | openssl enc -e -aes-256-cbc -k <some key>
> `----
>
> and then testing the result with
>
> ,----
> | echo -n <encrypted data> | openssl enc -e -aes-256-cbc -k <some key>
> `----
> (obviously I should get back the data I started with).
>
Use -d to decrypt (as you do below, so I hope this is just a typo).
And (raw) encrypted data is very likely to contain character codes
that aren't ASCII printable (or 8859/Unicode/etc. if applicable)
and you can't reliably type, or include in shell commands/arguments,
or are treated specially by echo (which could be a shell builtin
or external e.g. /bin/echo which are often significantly different).
> More often than not it works fine, but sometimes the encryption will
> produce output that contains values which echo (for the decrypt) balks
> at.
>
Sometimes? I'd expect most of the time.
> I tried base64 en/decoding the data:
>
> ,----
> | echo -n <some data> | openssl enc -e -aes-256-cbc -k <some
> key> -base64
> `----
> and
> ,----
> | echo -n
> U2FsdGVkX1/EbpoczzWXJQC+RkTFvf7k2yL3LYWXCXrlDssu5p93tRAjtdODxB
> Ma | openssl enc -d -base64 -aes-256-cbc -k <some key>
> `----
>
> and got "error reading input file" which I guess is because of the "/"
> in the encoded and encrypted data. Any suggestions here?
>
Drop -n. base64 data is standardly lines *with ending NL*.
If you (just) let it output you should see that, but if
you capture with x=`...|openssl enc -e` or x=$( ... )
and just use $x that "normalizes" whitespace. For data
over 48 bytes, base64 is *multiple* lines, which will be
harder to echo, unless you use -A to put it all on one line,
which may still be difficult to handle because it's long.
The / is no problem; the base64 charset is letters (both cases)
digits slash and plus, and equals for padding if necessary,
with linebreaks and other whitespace (if used) skipped.
These were chosen decades ago because they survive practically
all processing done on all systems everywhere.
> Or is there a better solution to getting <some data> and
> <encrypted data>
> into openssl than echoing it, without writing it to a file and
> (preferably) without manipulating the data before passing it
> to openssl?
>
Base64 is the usual way of doing this manually or semimanually,
precisely because it was designed to use only safe characters.
Writing and reading a file is usually the simplest and easiest
way to handle arbitrary bits, commonly 'binary'. Since you've
excluded that, awk and perl can (usually?) be persuaded to output
any bytes; or you can write your own decode/dearmor program(s?).
Or you could store it in a database and fetch it back out;
for base64 you can use standard commandline utilities like
mysql, sqlcmd, sqlplus; for 'binary' you'll have to write
your own programs. But many databases are actually files.
Although you could use a remote database (server), then
it isn't a file *on your system*; does that count? But you
could also remote a file with NFS, AFS, NetBios/Samba/etc.
Ciphertext is always 'binary' (for modern computer ciphers).
Whether your plaintext is so, or is limited to printable
characters that you can echo and print and type etc., is
up to you, or your users/customers/boss(es)/etc.
Gary
>> I am trying to call the openssl tool from a script, and I am
>> having some
>> problems
>> ,----
>> | echo -n <encrypted data> | openssl enc -e -aes-256-cbc -k <some key>
>> `----
> Use -d to decrypt (as you do below, so I hope this is just a typo).
Yes, a typo. Sorry.
>> I tried base64 en/decoding the data:
...
>> ,----
>> | echo -n
>> U2FsdGVkX1/EbpoczzWXJQC+RkTFvf7k2yL3LYWXCXrlDssu5p93tRAjtdODxB
>> Ma | openssl enc -d -base64 -aes-256-cbc -k <some key>
>> `----
>>
>> and got "error reading input file" which I guess is because of the "/"
>> in the encoded and encrypted data. Any suggestions here?
>>
> Drop -n. base64 data is standardly lines *with ending NL*.
Aha! Yes, that was exactly the problem. 2000 test runs have just
performed perfectly. Thanks very much!