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)