Difference between revisions of "Talk:Enc"

From OpenSSLWiki
Jump to navigationJump to search
(Option -K)
 
(Further discussion on zlib compression)
 
(8 intermediate revisions by 2 users not shown)
Line 4: Line 4:
  
 
Is this true? Does it not depend fairly heavily on your use case? Just not sure what the basis for this statement is.
 
Is this true? Does it not depend fairly heavily on your use case? Just not sure what the basis for this statement is.
 +
 +
--[[User:Matt|Matt]] 21:39, 27 June 2013 (UTC)
 +
 +
Probably you are right. Its a biased statement. I'll change it.
 +
 +
--[[User:Frukto|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.
 +
 +
--[[User:Matt|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
 +
 +
--[[User:Frukto|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. "
 +
 +
--[[User:Matt|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.
 +
 +
--[[User:Frukto|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 [[Manual:Enc(1)|here]], so at least the documentation is right.
 +
 +
--[[User:Matt|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.
 +
 +
--[[User:Matt|Matt]] 11:41, 6 July 2013 (UTC)
 +
 +
Yes sure, thx.
 +
 +
--[[User:Frukto|Frukto]] 11:57, 6 July 2013 (UTC)

Latest revision as of 13:09, 6 July 2013

Rarely Used -K option[edit]

"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[edit]

"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[edit]

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)