Re: AES256 & AES192. (Was: Can I revitalise an old key-pair?)

2013-09-03 Thread Pete Stephenson 
On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole  wrote:
> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
>  wrote:
>
> [snip]
>
>>
>>  Paradoxically, AES256 & AES192 had
>> weaknesses that made them less safe than AES (AES-128) several
>> years back.  May I humbly suggest TWOFISH or one of the
>> CAMELLLIA ciphers as a first choice UNTIL you determine whether
>> or not the fixes for AES-256 and AES-192 are retroactive?  DID
>> THEY GET THEM FIXED?  I am just assuming they did but that means
>> I HOPE the older implementation and the newer one can easily be
>> discerned when you do the decipher.
>
>
> [snip]
>
> I was curious about this. The wikipedia page mentions the "Related Key
> Attack" on these cyphers, but is vague about whether they were ever
> fixed.
>
> Does anyone know?
>
> And did fixes make it into the version used by Gnupg?

Even more importantly, were they ever an issue with GnuPG in the first place?

That is, does GnuPG generate related keys?

I was always under the impression that GnuPG randomly generated
session keys rather than creating related session keys; if true,
wouldn't this mean that the related-key attack doesn't apply?

In regards to fixing the cipher, I'm not really sure that one can just
issue a patch that would update the cipher itself (as opposed to a
specific implementation of it): the cipher is standardized and is
implemented in both hardware and software in zillions of devices and
programs around the world. Adding more rounds or changing its
functionality in some way to counter this attack would cause that
changed version to diverge from the standard and it presumably not
interoperate with standard AES.

Cheers!
-Pete

-- 
Pete Stephenson

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AES256 & AES192. (Was: Can I revitalise an old key-pair?)

2013-09-03 Thread Nicholas Cole 
On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson  wrote:
> On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole  wrote:
>> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
>>  wrote:
>>
>> [snip]
>>
>>>
>>>  Paradoxically, AES256 & AES192 had
>>> weaknesses that made them less safe than AES (AES-128) several
>>> years back.  May I humbly suggest TWOFISH or one of the
>>> CAMELLLIA ciphers as a first choice UNTIL you determine whether
>>> or not the fixes for AES-256 and AES-192 are retroactive?  DID
>>> THEY GET THEM FIXED?  I am just assuming they did but that means
>>> I HOPE the older implementation and the newer one can easily be
>>> discerned when you do the decipher.
>>
>>
>> [snip]
>>
>> I was curious about this. The wikipedia page mentions the "Related Key
>> Attack" on these cyphers, but is vague about whether they were ever
>> fixed.
>>
>> Does anyone know?
>>
>> And did fixes make it into the version used by Gnupg?
>
> Even more importantly, were they ever an issue with GnuPG in the first place?
>
> That is, does GnuPG generate related keys?
>
> I was always under the impression that GnuPG randomly generated
> session keys rather than creating related session keys; if true,
> wouldn't this mean that the related-key attack doesn't apply?

And if that were true, I presume that would mean that the "AES is
stronger than AES256" argument would also fall. Or have I
misunderstood?

N.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Security of 3DES

2013-09-03 Thread Peter Lebbing 
My main point is furtheron because I reply inline

On 02/09/13 06:04, Henry Hertz Hobbit wrote:
> CAST5 is a good last choice because some of the time that is all others can
> handle. Make sure CAST5 is always a last or next to last choice because that
> may be all that they can do with a limited horsepower box.

I have to assume "can handle" here means: get good encryption speed. Because:

> You may even want 3DES as a last option for those that got stuck there for
> some reason.

We /are/ talking OpenPGP here, so any implementation is required to be able to
handle 3DES. There is no OpenPGP-conformant implementation that will do CAST5
but not 3DES. Also, 3DES is always in your preference list; if not explicitly,
it's implicitly added as the least-preferred algorithm (i.e., at the end of the
list).

> Compression?  The symmetric ciphers seem to always have better compression
> than either zlib (gzip) or zip.

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.

> Time marches on and what was good 10+ years ago (3DES) is no match for modern
> CPU power.

*Here is my main point* which made me decide to reply.

3DES is safe. It's incredibly safe! How is it no match for modern CPU power?
There are no practical attacks on 3DES. What are you trying to say?

> 4. If possible, the backup of the keys themselves in an an enciphered file

A passphrase on a key is already encryption and it is useless to encrypt it more
beyond that.

> Alternatively, 7-zip could be used with its built-in AES128 bit cipher

... which just creates a useless dependency on a piece of software you might not
be able to get for your computer in 10 or 20 years, IMHO. Put a passphrase on
the key and presto, nothing more needed.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[no subject]

2013-09-03 Thread Mustrum 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone.

The last gpg-agent supports ECDSA and putty's pageant.

But, does it support ECDSA for putty/pageant ?

Regards.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iQI7BAEBCAAlBQJSJbADHhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK
CRBMuv2GX9WDnh40D/9Zf8Mho4GYBedjrKBhPq6CXLr+fBmla/VFbKa08NNDJ+Jg
kA0cD/CWo/3N5QgY7bSzkzHPHFz3X3zleL/+glGci7ILgybtow8d8M6TEaxg5uUk
kAsxd6As9sdTGVJqhSHwX4f6o214izkjNFl710YWqwzXqIyyf5N40jnhrNBwodvN
RGIYaqIgFULRUqC8G6FOnMqGv4Oz+JOwJuwbNu/qoYDMMZ8FckOdaM0CUnpOswyY
SwZTYoArFKYnzwTiEr8OEtmqEczybdgkQzeeay25cbCqZncEC0lFXizfRZl1/mBS
wW4m9WrTaMuBlbJ/maHy6twAxL6PxZiQaDg8065tK060PUM1MtunTJcjZbgtRpMj
culIrtlKi68rwhvVGaEp1MOSgdBKdv1gIlSizyyGwtxTZd3ZzF1QLX42JFdftNvu
H5YzfG1EVTamIn7Vz0JC+cJmjnrZ54dTIDqnBe5zXc+5EFXbmIkWIOjScZzbmkcc
BtyUonwFM876SGp8i0FQNgdL2ugLi4Az5yBSzNsSQqkFEbn5i0ZrEXA6ANcLBepJ
mgfT3N7SuB2MygdUSVSqLCINO+LoPvAhOotsDoBuI5+H5KaaLRbSfk0nvjbhrECV
8kWpZn54BO7LgHx3YDDK5ZZBGWRLMHqNEGuYtVsoDr/G8eFDt7DeXH+2JsiNcA==
=ZwEs
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AES256 & AES192. (Was: Can I revitalise an old key-pair?)

2013-09-03 Thread Nicholas Cole 
On Tuesday, 3 September 2013, Nicholas Cole wrote:

> On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson 
> >
> wrote:
> > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole 
> > >
> wrote:
> >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
> >> > wrote:
> >>
> >> [snip]
> >>
> >>>
> >>>  Paradoxically, AES256 & AES192 had
> >>> weaknesses that made them less safe than AES (AES-128) several
> >>> years back.  May I humbly suggest TWOFISH or one of the
> >>> CAMELLLIA ciphers as a first choice UNTIL you determine whether
> >>> or not the fixes for AES-256 and AES-192 are retroactive?  DID
> >>> THEY GET THEM FIXED?  I am just assuming they did but that means
> >>> I HOPE the older implementation and the newer one can easily be
> >>> discerned when you do the decipher.
> >>
> >>
> >> [snip]
> >>
> >> I was curious about this. The wikipedia page mentions the "Related Key
> >> Attack" on these cyphers, but is vague about whether they were ever
> >> fixed.
> >>
> >> Does anyone know?
> >>
> >> And did fixes make it into the version used by Gnupg?
> >
> > Even more importantly, were they ever an issue with GnuPG in the first
> place?
> >
> > That is, does GnuPG generate related keys?
> >
> > I was always under the impression that GnuPG randomly generated
> > session keys rather than creating related session keys; if true,
> > wouldn't this mean that the related-key attack doesn't apply?
>
> And if that were true, I presume that would mean that the "AES is
> stronger than AES256" argument would also fall. Or have I
> misunderstood?
>

While reading up on all of this I found this piece (concerning a very
widely used piece of software for Mac OS and iOS) on the switch to AES256.
I thought others would find it useful.

http://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Security of 3DES

2013-09-03 Thread Robert J. Hansen 
On 9/3/2013 12:49 PM, Peter Lebbing wrote:
> 3DES is safe. It's incredibly safe! How is it no match for modern CPU
> power? There are no practical attacks on 3DES. What are you trying to
> say?

I have said this many times in the past; apparently I need to say it again.

"3DES has been turning brilliant cryptanalysts into burned-out alcoholic
wrecks for over thirty years."

Nothing in the OpenPGP suite comes anywhere near to the safety provided
by 3DES.  Nothing even comes *close*.  Assuming your adversary has
access to more computing power than exists in the entire world, 3DES
offers "only" 112 bits of security; for realistic assumptions about
computing power, 3DES offers the full 168 bits.

3DES is ugly, awkward, ungainly, slow, and it has all the aesthetic
appeal of the Socialist Realism school of art.  It is *awful*.  And yet,
it keeps on going, completely impervious to the last three decades of
cryptanalysis.

It reminds me quite a lot of the coelacanth -- a fish that was found in
the fossil record 400 million years ago, and still can be found swimming
in the oceans today.  If you look at a coelacanth it just looks
primitive, unevolved, and strangely frightening.  It has survived the
last 400 million years of Nature's attempts at killing it.  It commands
respect and admiration, even while at the same time giving vague
feelings of revulsion.

3DES is our coelacanth.

http://outlookcolumbus.com/wp-content/uploads/2013/02/coelacanth1.jpg




smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Gpg-agent ECDSA and pageant

2013-09-03 Thread Mustrum 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone.

The last gpg-agent supports ECDSA and putty's pageant.

But, does it support ECDSA for putty/pageant ?

Regards.

Ps: oups,  sorry for my last message without any subject,  bad clicking...
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iQI7BAEBCAAlBQJSJb9AHhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK
CRBMuv2GX9WDniPlD/kBMS7njhxHUrogbL30GonJZcUqiuhAHdgkg+mOSXbtOGqR
8g7JTb30oFka99KRB1xKRhiJwhIUKWpb1NAdrhjPirCGpxmpUctw7Ds6o1KfrdpZ
8gcIffQvs/3gSmfcOSI9gO4ycAW+uGxxpAJDKst4i0+RqJJxQproLivjzwPSs2hv
jTcT3mKQJ0JA8tTfzwL2iU4Ac74xAgeFeCnjlwSHMveuQtl/xhjlrBMDyFVx/CzY
VUHRb7/0jBmRkx4DnxhL80XaECUzo5hS5LV40mzBw9sj2+GIVxmw850/F084JORe
p84ypaAzkMKMPvVZszGVx7eaFR8TwVqZB0lvZrnDpTZr+sRdqGu00mRAHbv4PAou
ispe8o1fQpYO5/zTx+5gqyTQaspbPyTthvCXUxygyRpLhqGeZIGySRoWL/cfodfU
EJ7J9ZxbXBCAGuRXu+F/B7Z9inVR1FHFqPupXoTdJDgd4KDMwey4YH3O71djLwhC
LhG535G8dALkmYMy9K8FDGjFxP7SsOIe+2DkULyEZebmgPvIiBYdCarJj6IdNfCS
MvdOl0KTWXuxiLhhpD2UolCaNltJr6QFxNgUVTbL0yg62BwJgKH8yQ3ZAaQOzNWR
5Rw2/y5ROtD9J8Gq+Y6DqVsBfx8RviIxkBTUN6uGjEs/BjdfWl3Muu+92JnAaw==
=cZaO
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: my statements were twisted (was Security of 3DES)

2013-09-03 Thread Henry Hertz Hobbit 
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 base64.zip
11978 Sep  4 01:25 DOC_Sue_Wagner.bin
16870 Sep  4 01:21 DOC_Sue_Wagner.eml
 8859 Sep  4 01:18 DOC_Sue_Wagner.zip

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 base64.zip was the conve