Talk:Enc
Rarely Used -K option
"This is rarely used, normally you specify a password from which a key is derived."
Is this true? Does it not depend fairly heavily on your use case? Just not sure what the basis for this statement is.
--Matt 21:39, 27 June 2013 (UTC)
Probably you are right. Its a biased statement. I'll change it.
--Frukto 07:27, 28 June 2013 (UTC)
Zlib compression
"Use this flag to enable zlib-compression. After a file is encrypted (and maybe base64 encoded) it will be compressed via zlib. Vice versa while decrypting, zlib will be applied first."
I think this happens the other way around. Doesn't compression occur before encryption, or after decryption? It doesn't make sense to do it the other way around - after encryption the data will appear indistinguishable from random data, and therefore should not have any appreciable ability to be compressed.
--Matt 12:17, 5 July 2013 (UTC)
Yes, i had the same question. But i tried it and it works actually like this: encryption -> base64 -> zlib
encrypt + unzip:
$ openssl enc -des -in message.plain -a -out message.enc -nosalt -z
$ printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" |cat - message.enc | gzip -dc
gives the same as:
$ openssl enc -des -in message.plain -a -out message.enc -nosalt
--Frukto 14:05, 5 July 2013 (UTC)
Interesting. I checked the source code and you appear to be right. The manual page however says this about -z: "Compress or decompress clear text using zlib before encryption or after decryption. This option exists only if OpenSSL with compiled with zlib or zlib-dynamic option. "
--Matt 11:41, 6 July 2013 (UTC)
Maybe, I should file a bug? I mean as you pointed out, the point of encryption is, in some sense, to maximize entropy. It does not make sense to compress afterwards. I don't know what was intended, but as you cite (actually i didn't check) the man page, it is a bug? But obviously nobody is using it, it would have been noticed immediately.
--Frukto 12:07, 6 July 2013 (UTC)
Might be worth raising it on the mailing list to see what the reaction is. I suspect it won't be fixed as it might break scripts etc for people that do use it. A possible feature enhancement could be to add a new option to do it properly. If it won't get fixed then we can edit the wiki version of the manual here, so at least the documentation is right.
--Matt 13:09, 6 July 2013 (UTC)
Block size vs Key size
I changed references to block size to key size as I think that is what you meant. AES-256 has a 256-bit key. The block size is always 128 bits for AES.
--Matt 11:41, 6 July 2013 (UTC)
Yes sure, thx.
--Frukto 11:57, 6 July 2013 (UTC)
