my statements were twisted (was Security of 3DES)

Henry Hertz Hobbit hhhobbit at
Wed Sep 4 05:37:28 CEST 2013

On 09/03/2013 04:49 PM, Peter Lebbing wrote:

> To expand on what Johan Wevers said: symmetric ciphers do not change the length
> of the encrypted text (by more than the block size). They certainly do not
> compress. Usually, data is compressed before encrypting it (compressing it after
> is pretty useless). If you set your key preferences to not allow compression,
> files encrypted to your key will not be smaller than the original files.

NO TWO PEOPLE ARE THE SAME!  The main thing I am saying is to
make choices work for you but at the same time consider the
others you interact with.  Taking my choices is NOT any better
than the ones on the Debian page.  You have to find your own.
If you have a problem with that I will don my Psychologist cap
and do analysis instead.

I won't answer the other questions because you have grossly
misinterpreted me.  My major point was that what was picked in
that list had the idea that bigger is better and biggest is best.
Zipping was required.

I dropped my 4096R keys and went from them to 2048R more not from
the point of view of which is safer but more from the point of
view of being reasonable for others.  Ditto for going from the
SHA512 hash down to SHA256.  Now I realize that there is a lot
more going on in GnuPG than just using sha256sum and sha512sum.
Nevertheless, doing tests on creating the hashes on 1000 files
made it quite evident that SHA256 wasn't that much of a burden
over SHA1.  But sha512sum consumed gobs more time than using
sha256sum.  So I switched not only the key sizes but the DIGEST
to SHA256 as my first choice.  How bad was SHA512 in other ways?
There were some times the  detached ".sig" files were as large
as or even larger than the base files!  But it was NOT what ever
I thought was the best for me security-wise driving the decision.
It was the needs and desires of others.  You don't live in a vacuum.
Having that much extra for the task at hand was gross over-kill.

There is nothing wrong with 3DES from my point of view.  There
may be from other people's point of view and that includes people
making government specifications that ignore the fact that CAST5
has not had as much crypton-analysis done on it than has been
done with 3DES.  Have you ever heard the statement "there is
the right way, the wrong way, and the Navy way"?  In that case
it is NOT your choice driving the decision.  If you were not
supposed to use 3DES then by golly you better not use it.
Didn't I make the statement that you are far more likely to lose
your secret documents via a hacker infecting your machine and
stealing them that way than attacking any of these ciphers?
Didn't I say you are more likely to have somebody go into your
house and attach a key-logger to the end of your keyboard than
by them attacking any of these ciphers directly?  Why did you
ignore these statements?

I only mentioned that 3DES should be considered for low powered
machines.  That statement stands.  If you want 3DES as your first
choice on an umpteen core machine go ahead. Other people with
lower powered machines will be delighted with your choice.  I will
get it implicitly only when that is all they can do but choose not
to add it to my list of ciphers.  Don't feel people have to pick
what you picked.  I hope they pick what works best for them and
the others they interact with.

My whole point is that they lined up things with a bigger is
better and biggest is best mentality.  There are times when
other factors are just as important as the security is.  There
are also the times as in AES vs. AES-256 where bigger doesn't
always mean better - at least according to Bruce Schneier's
thinking.  If you want to argue that point argue it with Bruce,
not me.  Me?  I took his advice and moved the AES to the head
of the AES line-up.  I was about to drop the AES-192 for one
of the Camellia ciphers (see my PS at the end).  It is called
free choice but I will make it considering the needs of others,
not just slap down the biggest one or the smallest one.

As for the zip algorithms I was thinking more along the lines of
what is going on in email and the fact that I much prefer 7-zip
over all the zip algorithms you can specify. You will NEVER
get 7-zip in GnuPG.  Now please don't misunderstand me on that
as well! All I am saying is that 7-zip will never be added to
GnuPG and I prefer 7-zip.  So I will do my compressing outside
of GnuPG.  But there is more going on.  First for what is
going on in email using one of the malware I got yesterday
pretending to come from the Royal Bank of Scotland:

 8859 Sep  4 01:26
11978 Sep  4 01:25 DOC_Sue_Wagner.bin
16870 Sep  4 01:21 DOC_Sue_Wagner.eml
 8859 Sep  4 01:18

The DOC_Sue_Wagner.eml was the email saved as is from
Thunderbird.  In adddition to the ASCII-fied zip it has a fair
sized headers, MIME markings and other things.  The file named
DOC_Sue_Wagner.bin was the eml file stripped down to just the
ASCII zip.  The was the conversion from the bin
file to a zip file using base64 -i -d.  The
file was saved as is from Thunderbird. and are the same:

$ sha1sum

$ hexcmp
# nothing spit out and zero returned which means all of the
# nth bytes are always the same.

But in this case it is a wash.  Whether zipped or not there
just isn't that much more of saving when things go to ASCII
so why bother?  All that does is slow both you and them down.

If it is a super huge file then I just zip it on the outside
with 7-zip.  Both 7-zip and bzip2 beat gzip and zip although
there are times when the orders are different.  On average
bzip2 usually is about 10% to 15% larger than 7-zip, gzip is
larger than bzip2 and zip is the largest of all.  But one
more thing 7-zip does for me is throw out the UID:GID.

Thus due to the email considerations and what I said pick your
own zip poison for GnuPG.  For me it will continue to be

Like I said, there is no one BEST choice for everybody. If
you disagree with somebody else's choice do it without being

PS  I think I am going to revoke my keys and just say to
    hell with OpenPG encryption.  It isn't worth it.

More information about the Gnupg-users mailing list