> From: [email protected] On Behalf Of Gary > 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
