Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

howto secure older keys after the recent attacks

 

 

First page Previous page 1 2 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded


philcerf at googlemail

Sep 9, 2009, 3:43 PM

Post #1 of 43 (4159 views)
Permalink
howto secure older keys after the recent attacks

Hi.

Now something more realistic and pracitcal.

I'm using gpg for anonymous but secured communication together with some of
my friends for some years now....
Recently I've read on severa attacks on SHA1 and AES256 that could also
affect gpg and its keys.

So waht I'd like to see is some step by step howto on securing older keys
(written by some expert probably ;-) ).

I have two keys a the moment one is a 4096 bit RSA key, the oder (for daily
use) has 1024 bits.

Using the pgpdump tool I found out that it has these settings:
Old: Signature Packet(tag 2)(567 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key
packet(0x13).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(2 bytes)
Hash alg - SHA1(hash 2)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(2 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Fri Oct 28 20:48:23 CEST 2005
Hashed Sub: primary User ID(sub 25)(1 bytes)
Primary - Yes
Sub: issuer key ID(sub 16)(8 bytes)

and a more recent User ID has these:

Old: Signature Packet(tag 2)(566 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key
packet(0x13).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Fri Apr 25 01:23:36 CEST 2008
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
Hash alg - SHA1(hash 2)
Hash alg - SHA256(hash 8)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify


As far as I understand thise means:
- The signatures on them are created with SHA1
- The differ in preferred algorihtms for hashes and compression

Well...
- It seems that I can easily change these preferences via gpg --edit-key,..
so I could simply remove e.g. SHA1
-But I'd also like to have the signatures themselves using e.g. SHA256 or
SHA512,... but they're alread using SHA1
Can this be changed?
Or can I simply add new self signatures?
And if I do so the old ones would still be on the keyservers, right? And no
way to delete them.
So does this mean any harm to me? At some day SHA1 might be fully broken,
and then an attacker could use simply these older self signatures instead of
the newer ones, or not?
Or should I better start with a fresh key without any old signatures?

Another thing I've read about is, that gpg keys are using SHA1 hard coded in
some places with no way to use another algortihm... which places are these
so one could avoid them perhaps?

Thanks for your insight,
Philippe.


rjh at sixdemonbag

Sep 9, 2009, 6:05 PM

Post #2 of 43 (4081 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

> So waht I'd like to see is some step by step howto on securing older
> keys (written by some expert probably ;-) ).

Add these lines to your gpg.conf file:

personal-digest-preferences SHA256 SHA224 SHA384 SHA512 RIPEMD160
personal-cipher-preferences AES128 3DES

... This will tell GnuPG that you'd much rather use a newer SHA than you
would SHA-1; and if for some reason GnuPG has to use a 160-bit hash, to
use RIPEMD160 instead of SHA-1. It will also tell GnuPG to use AES128
for message encryption. If for whatever reason your recipient can't
read AES128, it should fall back to 3DES.

Some people will tell you that 3DES is an old, antique and outdated
cipher. This is true. Some will tell you it's slow. This is an
understatement. 3DES is ugly, crude, and inelegant. It has all the
aesthetics of the Soviet Socialist Realism school of art. It has also
been turning brilliant cryptanalysts into burned-out alcoholic wrecks
for three decades straight, and that reputation is solid gold.

Some people will undoubtedly advocate much more complex schemes. I
suggest avoiding them. Simple and effective solutions are usually much,
much better than complex and effective solutions.




_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dshaw at jabberwocky

Sep 9, 2009, 6:45 PM

Post #3 of 43 (4086 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Sep 9, 2009, at 6:43 PM, Philippe Cerfon wrote:

> Hi.
>
> Now something more realistic and pracitcal.
>
> I'm using gpg for anonymous but secured communication together with
> some of my friends for some years now....
> Recently I've read on severa attacks on SHA1 and AES256 that could
> also affect gpg and its keys.
>
> So waht I'd like to see is some step by step howto on securing older
> keys (written by some expert probably ;-) ).

[..]

> As far as I understand thise means:
> - The signatures on them are created with SHA1
> - The differ in preferred algorihtms for hashes and compression
>
> Well...
> - It seems that I can easily change these preferences via gpg --edit-
> key,.. so I could simply remove e.g. SHA1

Yes, but it won't actually go away completely. SHA1 is special in
OpenPGP. Unlike the other hashes, SHA1 is required to be supported.
Removing SHA1 from an OpenPGP preference list doesn't actually remove
it, but instead effectively puts it at the end of the list (so it is
the lowest ranked choice).

> -But I'd also like to have the signatures themselves using e.g.
> SHA256 or SHA512,... but they're alread using SHA1
> Can this be changed?
> Or can I simply add new self signatures?

Yes

> And if I do so the old ones would still be on the keyservers, right?
> And no way to delete them.

Yes

> So does this mean any harm to me? At some day SHA1 might be fully
> broken, and then an attacker could use simply these older self
> signatures instead of the newer ones, or not?

Well, yes and no. Old signatures are certainly available to both
friend and foe, but the real question is: use them for what? What
attack are you concerned about here?

> Or should I better start with a fresh key without any old signatures?

No need. If you had a DSA key, I might suggest changing keys, but you
have an RSA key, and are thus free to use whatever hash you please.

To change the hash you sign with, stick this in your gpg.conf file:

personal-digest-preferences sha256

Feel free to list whatever hashes you like here. GPG will rank them
in that order.

> Another thing I've read about is, that gpg keys are using SHA1 hard
> coded in some places with no way to use another algortihm... which
> places are these so one could avoid them perhaps?

You pretty much can't. The key ID itself is derived from SHA1.

There was a very long discussion of the SHA1 issue a few months back
on this list. See, for example, http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036338.html
and http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html

In short, I wouldn't worry all that much about it.

With regards to AES256, I doubly wouldn't worry about it. See http://lists.gnupg.org/pipermail/gnupg-users/2009-August/037107.html

This sort of question tends to cause long threads where everyone
throws in their own cipher preferences. Instead of giving my
preferences, allow me to point at the wonderful defaults in GPG.
They're the default algorithms for a reason.

David


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 4:42 AM

Post #4 of 43 (4081 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi Robert.


On Thu, Sep 10, 2009 at 3:05 AM, Robert J. Hansen <rjh [at] sixdemonbag> wrote:
> Add these lines to your gpg.conf file:
>
> personal-digest-preferences SHA256 SHA224 SHA384 SHA512 RIPEMD160
> personal-cipher-preferences AES128 3DES
>
[...]

And you think this is enough? Not removing and recreating and older
signatures that use SHA1?


Thanks,
Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 5:02 AM

Post #5 of 43 (4071 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Thu, Sep 10, 2009 at 3:45 AM, David Shaw <dshaw [at] jabberwocky> wrote:
> Yes, but it won't actually go away completely.  SHA1 is special in OpenPGP.
>  Unlike the other hashes, SHA1 is required to be supported.  Removing SHA1
> from an OpenPGP preference list doesn't actually remove it, but instead
> effectively puts it at the end of the list (so it is the lowest ranked
> choice).
Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would
we have to create a new OpenPGP and new keys?


>> -But I'd also like to have the signatures themselves using e.g. SHA256 or
>> SHA512,... but they're alread using SHA1
>> Can this be changed?
>> Or can I simply add new self signatures?
> Yes

Does this work via --cert-digest-algo option?
If so what must I do to get gpg to:
- resign my own key
- resign other keys
Is it simply with the sign command, or will it complain that there's
already a signture there?


>> So does this mean any harm to me? At some day SHA1 might be fully broken,
>> and then an attacker could use simply these older self signatures instead of
>> the newer ones, or not?
>
> Well, yes and no.  Old signatures are certainly available to both friend and
> foe, but the real question is: use them for what?  What attack are you
> concerned about here?

Well.. not sure... I've heard that one can add many settings to these
signatures like rovcations or policies. But I have not enough
knowledge on them (although I could imagine that someone could
probably use them to do evil things which might be impossible with a
newer hash-algo).
But perhaps it could be used to do some forgery with User IDs?


> To change the hash you sign with, stick this in your gpg.conf file:
>
> personal-digest-preferences sha256

Oh,.. so what is this --cert-digest-algo then good for?


>> Another thing I've read about is, that gpg keys are using SHA1 hard coded
>> in some places with no way to use another algortihm... which places are
>> these so one could avoid them perhaps?
>
> You pretty much can't.  The key ID itself is derived from SHA1.

I thought the key ID is only used for humans to short check the
keys,.. but not in the system itself?!
So this would basically mean, once SHA1 is broken, we're totally screwed?!


> There was a very long discussion of the SHA1 issue a few months back on this
> list.  See, for example,
> http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036338.html and
> http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html
>
> In short, I wouldn't worry all that much about it.

At least at the moment you mean? I mean we had the "same" thing with
MD4, MD5 and so on,... so probably it will hit us with SHA1, too?


> With regards to AES256, I doubly wouldn't worry about it.  See
> http://lists.gnupg.org/pipermail/gnupg-users/2009-August/037107.html
>
> This sort of question tends to cause long threads where everyone throws in
> their own cipher preferences.  Instead of giving my preferences, allow me to
> point at the wonderful defaults in GPG.  They're the default algorithms for
> a reason.
Ok,.. thanks for that information :)


I'd have some additional poor men's questions ;-)...
- When creating a new key,.. it uses the entropy, right? So is there
some way to improve this entropy? Perhaps not using Linux but instead
OpenBSD which might have a better PRNG (don't know if this is actually
the case ;) ) or use a specific Linux kernel version where a newer and
better PRNG was added?
-Currently the default (and I assume suggested) algorithm is RSA,
right? How does DSA2 compare with it? I once read, that RSA would
provide a hash algorithm armor which the DSA's wouldn't have. Is this
still true?
-My course's professor showed us some number from NIST (don't recall
the exact ones, though) where they suggested about something like
this:
15360 (or so) bits for the asymetric key <-> 512 bits for the hash
size <-> 256 symmetric key
should lead to about the same "strenght"...
So we have 512/256 bits for the later two,.. but per default much less
for the asymmetric... Does this mean, that the other two are overkill
for what we use in gpg?
- When creating new keys (I'd like to "convince" some more friends to
take part :) )... should they create their keys with gpg1 or gpg2? Or
is the key generation equally secure?


Best wishes,
Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Sep 10, 2009, 6:59 AM

Post #6 of 43 (4073 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

> - When creating a new key,.. it uses the entropy, right? So is there
> some way to improve this entropy? Perhaps not using Linux but instead
> OpenBSD which might have a better PRNG (don't know if this is actually
> the case ;) ) or use a specific Linux kernel version where a newer and
> better PRNG was added?

Not really. If there were good reasons to believe OpenBSD's entropy
collector was better than Linux's, the Linux crew would fix the code,
maybe even borrowing OpenBSD's entropy collector.

> -Currently the default (and I assume suggested) algorithm is RSA,
> right? How does DSA2 compare with it?

Arguing whether RSA or DSA2 is better is kind of like arguing whether
King Kong or Godzilla is better at stomping cities flat.

> I once read, that RSA would
> provide a hash algorithm armor which the DSA's wouldn't have. Is this
> still true?

Yes. No. Not really. Kind of.

RSA gives you a lot of freedom, yes. You could put SHA512 on an RSA-3
(as in "three bits of key") signature and it won't bat an eyelash. It's
_stupid_, but it won't bat an eyelash.

So, sure. RSA gives you more freedom with hashes than DSA2, but that's
not necessarily a good thing.

> should lead to about the same "strenght"...

Beware of those numbers. I don't know anyone who takes them seriously.
They are conjecture and speculation. Educated conjecture and
speculation, sure: some of the brightest minds out there worked on the
conjecture and speculation -- but they're still conjecture and
speculation.

That said, there's nothing wrong with using those numbers as long as you
remember that they're conjecture.

> So we have 512/256 bits for the later two,.. but per default much less
> for the asymmetric... Does this mean, that the other two are overkill
> for what we use in gpg?

Probably. But it isn't as if it matters much.

> - When creating new keys (I'd like to "convince" some more friends to
> take part :) )... should they create their keys with gpg1 or gpg2? Or
> is the key generation equally secure?

If memory serves, the key generation code is identical between the 1.4
and 2.0 branches.



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dkg at fifthhorseman

Sep 10, 2009, 7:31 AM

Post #7 of 43 (4065 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On 09/09/2009 09:45 PM, David Shaw wrote:
> Instead of giving my preferences,
> allow me to point at the wonderful defaults in GPG. They're the default
> algorithms for a reason.

I've asked this before, but without any satisfactory answer, i'm still
curious: Why do the digest defaults in 1.4.10 and 2.0.13 list SHA-1
above SHA-512, SHA-224, and SHA-384?

I don't believe that the mere existence of hardware acceleration of
SHA-1 is sufficient to warrant its default preference over stronger,
widely-implemented digests.

Users who have (and prefer to use) accelerator hardware for any
particular digest can change their published preferences to explicitly
prefer that hardware, right? Are SHA-1 accelerators so widespread that
people have them (and gpg uses them) without being aware of them?

Is there some other reason to rank SHA-1 like this?

--dkg
Attachments: signature.asc (0.87 KB)


philcerf at googlemail

Sep 10, 2009, 7:51 AM

Post #8 of 43 (4064 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi Robert.



On Thu, Sep 10, 2009 at 3:59 PM, Robert J. Hansen <rjh [at] sixdemonbag> wrote:
> Not really.  If there were good reasons to believe OpenBSD's entropy
> collector was better than Linux's, the Linux crew would fix the code,
> maybe even borrowing OpenBSD's entropy collector.

Ah,.. right... it was the other way round it didn't work (GPL2 to BSD ;) )


>> -Currently the default (and I assume suggested) algorithm is RSA,
>> right? How does DSA2 compare with it?
> Arguing whether RSA or DSA2 is better is kind of like arguing whether
> King Kong or Godzilla is better at stomping cities flat.

One should perhaps count in all the King Kong vs. Godzilla moviews,..
who has won more often? ;-)


>>  I once read, that RSA would
>> provide a hash algorithm armor which the DSA's wouldn't have. Is this
>> still true?
>
> Yes.  No.  Not really.  Kind of.

ooook... ^^


>> should lead to about the same "strenght"...
>
> Beware of those numbers.  I don't know anyone who takes them seriously.
> They are conjecture and speculation.  Educated conjecture and
> speculation, sure: some of the brightest minds out there worked on the
> conjecture and speculation -- but they're still conjecture and
> speculation.
>
> That said, there's nothing wrong with using those numbers as long as you
> remember that they're conjecture.

Ok,.. I see.

> If memory serves, the key generation code is identical between the 1.4
> and 2.0 branches.
Thanks :)


Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Sep 10, 2009, 7:54 AM

Post #9 of 43 (4065 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote:
> Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would
> we have to create a new OpenPGP and new keys?

Probably. However, if SHA-1 gets totally broken we'll have a lot bigger
things to worry about than OpenPGP.

> > Well, yes and no. Old signatures are certainly available to both friend and
> > foe, but the real question is: use them for what? What attack are you
> > concerned about here?
>
> Well.. not sure...
> But perhaps it could be used to do some forgery with User IDs?

As soon as you find an attack, then we can discuss it. Unfortunately,
we can't really talk intelligently about vague fears.

> I thought the key ID is only used for humans to short check the
> keys,.. but not in the system itself?!

Nope, it's pretty pervasive in the system.

> So this would basically mean, once SHA1 is broken, we're totally screwed?!

If SHA-1 gets totally broken, pretty much everyone with a computer more
powerful than a pocket calculator is screwed. We won't be the only
ones.

> At least at the moment you mean? I mean we had the "same" thing with
> MD4, MD5 and so on,... so probably it will hit us with SHA1, too?

Hans Dobbertin proved MD5 was weak in 1996. In 1997, Network Associates
(who then were pretty much the only game in town, as far as PGP goes)
decided the Dobbertin attack was worrisome and that MD5 needed to go.
By the time the MD5 attacks became practical, PGP had _long_ since
migrated to SHA-1 and RIPEMD160.

The same thing is happening today with OpenPGP. Everyone knows about
the SHA-1 attacks. For right now, the SHA-1 attacks are impractical.
The people behind OpenPGP are working on a new OpenPGP proposal that
will use a stronger, better hash algorithm.

They're on it. Relax. :)

If you want to follow the discussion yourself on the official mailing
list for the RFC4880 standard, feel free. It's a public list and
everyone's welcome.



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Sep 10, 2009, 8:04 AM

Post #10 of 43 (4068 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Thu, 2009-09-10 at 16:51 +0200, Philippe Cerfon wrote:
> Ah,.. right... it was the other way round it didn't work (GPL2 to BSD ;) )

Copyright protects the way an idea is expressed, not the idea itself.
If Linux had a better entropy collector than OpenBSD, the OpenBSD folks
would study the Linux version. They'd learn how it works, they'd learn
how it was designed. The Linux developers would probably help them out
in this. Once the OpenBSD folks knew exactly how the Linux collector
worked and why, they'd go off and hammer out their own version of the
Linux collector.

It wouldn't take them long. The hardest part of programming is
understanding the problem and how the solution you're writing interacts
with it. Once you've got that down, the code almost writes itself. It
comes together really, really quick.

IANAL, if you're doing serious software development talk to your own IP
lawyer before you take this seriously, etc., etc.




_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dshaw at jabberwocky

Sep 10, 2009, 8:08 AM

Post #11 of 43 (4076 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Sep 10, 2009, at 8:02 AM, Philippe Cerfon wrote:

> On Thu, Sep 10, 2009 at 3:45 AM, David Shaw <dshaw [at] jabberwocky>
> wrote:
>> Yes, but it won't actually go away completely. SHA1 is special in
>> OpenPGP.
>> Unlike the other hashes, SHA1 is required to be supported.
>> Removing SHA1
>> from an OpenPGP preference list doesn't actually remove it, but
>> instead
>> effectively puts it at the end of the list (so it is the lowest
>> ranked
>> choice).
> Uhm,.. what a pity. What would happen if SHA1 gets fully broken? Would
> we have to create a new OpenPGP and new keys?

Not a new OpenPGP, exactly, but certainly a revised one. New keys,
yes. Of course, SHA1 is nowhere near being fully broken. Heck, even
MD5 is nowhere near being "fully" broken (which doesn't mean I
recommend people use it, of course).

>>> -But I'd also like to have the signatures themselves using e.g.
>>> SHA256 or
>>> SHA512,... but they're alread using SHA1
>>> Can this be changed?
>>> Or can I simply add new self signatures?
>> Yes
>
> Does this work via --cert-digest-algo option?
> If so what must I do to get gpg to:
> - resign my own key
> - resign other keys
> Is it simply with the sign command, or will it complain that there's
> already a signture there?

Yes. To re-sign a key with a new hash, do this:

gpg --cert-digest-algo sha256 --expert --edit-key (thekey)
(pick the user IDs you want to sign)
sign

The "cert-digest-algo" tells GPG which hash to make key signatures
with, and the "expert" tells GPG that it is okay to re-sign a user ID
that is already signed.

>> To change the hash you sign with, stick this in your gpg.conf file:
>>
>> personal-digest-preferences sha256
>
> Oh,.. so what is this --cert-digest-algo then good for?

personal-digest-preferences sets the hash for signatures you make on
data.
cert-digest-algo sets the hash for signatures ("certifications") you
make on keys.

>>> Another thing I've read about is, that gpg keys are using SHA1
>>> hard coded
>>> in some places with no way to use another algortihm... which
>>> places are
>>> these so one could avoid them perhaps?
>>
>> You pretty much can't. The key ID itself is derived from SHA1.
>
> I thought the key ID is only used for humans to short check the
> keys,.. but not in the system itself?!
> So this would basically mean, once SHA1 is broken, we're totally
> screwed?!

No, just that we need to revise OpenPGP. It's not a disaster - we've
done it in the past, and can do it again in the future. It's just a
specification that describes a cryptographic system using the best
knowledge of the time. If the knowledge changes, we change the
specification.

The real headache here is (as always) the practical - what to do with
existing keys and such. I suspect that removing SHA1 would
effectively mean a new key type for OpenPGP (again, not a disaster -
we're on our 4th key type today).

> I'd have some additional poor men's questions ;-)...
> - When creating a new key,.. it uses the entropy, right? So is there
> some way to improve this entropy? Perhaps not using Linux but instead
> OpenBSD which might have a better PRNG (don't know if this is actually
> the case ;) ) or use a specific Linux kernel version where a newer and
> better PRNG was added?

There are occasional debates on who has the better PRNG. The debates
usually end with no changes on either side :)

That isn't to say there aren't differences between systems - the
FreeBSD PRNG (which seems to have been inherited by OSX) is of a
fairly different construction than the Linux one, which has led to
some mild controversy in the past. Notably, the Linux one blocks if
you run out of gathered entropy, and the FreeBSD one does not.
FreeBSD /dev/random is similar to Linux's /dev/urandom.

See also http://www.entropykey.co.uk/

> -Currently the default (and I assume suggested) algorithm is RSA,
> right? How does DSA2 compare with it?

Given the same key length and same hash, they are (massive armwave!)
roughly equal for real-world use. If you like, you can define
"roughly equal" as "usually so much stronger than the rest of the
system that fiddly differences are irrelevant". The actual difference
you find between the two is more in implementation and use issues,
like DSA signatures being physically smaller than RSA signatures (nice
for email), RSA being more widely supported in hardware doodads
(smartcards, crypto math chips, etc), and RSA allowing more hash
flexibility than DSA.

Read NIST SP 800-57 for lots of detail on strength, but they basically
conclude the same thing: roughly equal for real-world use.

> I once read, that RSA would
> provide a hash algorithm armor which the DSA's wouldn't have. Is this
> still true?

I'm not exactly sure what you mean by "hash algorithm armor". RSA in
OpenPGP does have a additional protection (usually called a "hash
firewall") that DSA lacks. This gives some protection against hash
substitution attacks, but it's not a major deal either way.

> -My course's professor showed us some number from NIST (don't recall
> the exact ones, though) where they suggested about something like
> this:
> 15360 (or so) bits for the asymetric key <-> 512 bits for the hash
> size <-> 256 symmetric key
> should lead to about the same "strenght"...
> So we have 512/256 bits for the later two,.. but per default much less
> for the asymmetric... Does this mean, that the other two are overkill
> for what we use in gpg?

It's true that NIST's guidelines say that to truly get the maximum
juice out of a 512-bit hash, you should use a 15360-bit key, but that
doesn't mean you must. That overall strength of the system is the
weakest point, so as long as that weakest point is strong enough,
you're fine.

A 15360-bit key is wildly impractical. I doubt we'll ever see keys of
that size in use. When technology progresses to the point of that
being necessary (no time soon) we'll move on to other algorithms that
are stronger per-bit, like ECDSA.

> - When creating new keys (I'd like to "convince" some more friends to
> take part :) )... should they create their keys with gpg1 or gpg2? Or
> is the key generation equally secure?

Equally secure. In fact, it's almost the same code.

David


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


dshaw at jabberwocky

Sep 10, 2009, 8:27 AM

Post #12 of 43 (4059 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Sep 10, 2009, at 10:51 AM, Philippe Cerfon wrote:

>> Not really. If there were good reasons to believe OpenBSD's entropy
>> collector was better than Linux's, the Linux crew would fix the code,
>> maybe even borrowing OpenBSD's entropy collector.
>
> Ah,.. right... it was the other way round it didn't work (GPL2 to
> BSD ;) )

Those are just implementations of methods to gather and manipulate
entropy. If one method was better, the other would more likely re-
implement the idea rather than lifting code wholesale. This usually
works out that way in the open source world, and especially in the
open source crypto world. Most likely, the people with the better
entropy gatherer would actively help the other people to improve their
code.

This doesn't necessarily work out the same way in the non-open source
world, but even so, some companies are very good to deal with with
getting information and discussing common problems (the PGP company is
a good example of this).

>>> -Currently the default (and I assume suggested) algorithm is RSA,
>>> right? How does DSA2 compare with it?
>> Arguing whether RSA or DSA2 is better is kind of like arguing whether
>> King Kong or Godzilla is better at stomping cities flat.
>
> One should perhaps count in all the King Kong vs. Godzilla moviews,..
> who has won more often? ;-)

Kong 1, Godzilla 0. Not exactly an Oscar winner, but "King Kong vs.
Godzilla" does have its charms.

I'm not sure which is RSA or DSA in this example though, and then
there is Mechani-Kong, and Lady Kong, and... ;)

David


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg.users at ml

Sep 10, 2009, 9:00 AM

Post #13 of 43 (4060 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

* Philippe Cerfon <philcerf [at] googlemail> [2009-09-10 14:03]:
> I'd have some additional poor men's questions ;-)...
> - When creating a new key,.. it uses the entropy, right? So is there
> some way to improve this entropy? Perhaps not using Linux but instead
> OpenBSD which might have a better PRNG (don't know if this is actually
> the case ;) ) or use a specific Linux kernel version where a newer and
> better PRNG was added?

Hi,

regarding this, the Simtec Entropy Key http://www.entropykey.co.uk/ is
available for sale online since a few days ago. This is an USB
hardware entropy generator. Perhaps this would be something to
consider in your tests regarding quality and speed of entropy
generation.

Kind Regards,

Sebastian

--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Attachments: signature.asc (0.58 KB)


gnupg.users at ml

Sep 10, 2009, 9:19 AM

Post #14 of 43 (4065 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

* Sebastian Wiesinger <gnupg.users [at] ml> [2009-09-10 18:01]:
> Hi,
>
> regarding this, the Simtec Entropy Key http://www.entropykey.co.uk/ is
> available for sale online since a few days ago. This is an USB
> hardware entropy generator. Perhaps this would be something to
> consider in your tests regarding quality and speed of entropy
> generation.

I'm sorry,

somehow I mixed up this thread with one on gnupg-devel. Nevertheless
the key is a nice piece of hardware.

Regards,

Sebastian

--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Attachments: signature.asc (0.58 KB)


dkg at fifthhorseman

Sep 10, 2009, 9:22 AM

Post #15 of 43 (4059 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On 09/10/2009 10:54 AM, Robert J. Hansen wrote:
> On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote:
>> I thought the key ID is only used for humans to short check the
>> keys,.. but not in the system itself?!
>
> Nope, it's pretty pervasive in the system.

Unless i misunderstand the context, I think I disagree with your
characterization here, Robert.

The Key ID is a substring (either the last 8 or 16 hex chars) of the Key
Fingerprint (which is 40 hex chars). The Key ID is used nowhere in the
internals of the OpenPGP specification, from what i can tell.

The fingerprint itself is used only in the designated revocation key
[0], which is an acknowledged weakness of the cryptosystem [1]. It's
not used anywhere else that i can tell.

So I think Philippe Cerfon's characterization is pretty accurate,
actually. The fingerprint (and to a weaker extent, the keyID) is useful
where the mechanical implementation meets the human mind. But I don't
think either are used internally to the OpenPGP cryptosystem in many
places at all.

--dkg

[0] http://tools.ietf.org/html/rfc4880#section-5.2.3.15
[1] http://www.imc.org/ietf-openpgp/mail-archive/msg33257.html
Attachments: signature.asc (0.87 KB)


rjh at sixdemonbag

Sep 10, 2009, 1:21 PM

Post #16 of 43 (4074 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Daniel Kahn Gillmor wrote:
> On 09/10/2009 10:54 AM, Robert J. Hansen wrote:
>> On Thu, 2009-09-10 at 14:02 +0200, Philippe Cerfon wrote:
>>> I thought the key ID is only used for humans to short check the
>>> keys,.. but not in the system itself?!
>> Nope, it's pretty pervasive in the system.
>
> Unless i misunderstand the context, I think I disagree with your
> characterization here, Robert.

I understood him to mean the "key ID" as the fingerprint of the
certificate's primary signing key, rather than checking each bit of the
certificate's primary signing key individually.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 2:33 PM

Post #17 of 43 (4049 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi Robert.



On Thu, Sep 10, 2009 at 4:54 PM, Robert J. Hansen <rjh [at] sixdemonbag> wrote:
> Probably.  However, if SHA-1 gets totally broken we'll have a lot bigger
> things to worry about than OpenPGP.

What specifically do you mean? Crypto-stuff in banking etc.?


> As soon as you find an attack, then we can discuss it.  Unfortunately,
> we can't really talk intelligently about vague fears.

Of course,... just wondered if there might be any known issues due to that.


> Hans Dobbertin proved MD5 was weak in 1996.  In 1997, Network Associates
> (who then were pretty much the only game in town, as far as PGP goes)
> decided the Dobbertin attack was worrisome and that MD5 needed to go.
> By the time the MD5 attacks became practical, PGP had _long_ since
> migrated to SHA-1 and RIPEMD160.

Ok,.. I see.
But attackers could still attack older data, that they intercepted, right?


Best wishes,
Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 2:38 PM

Post #18 of 43 (4050 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Thu, Sep 10, 2009 at 5:08 PM, David Shaw <dshaw [at] jabberwocky> wrote:
> The real headache here is (as always) the practical - what to do with
> existing keys and such.  I suspect that removing SHA1 would effectively mean
> a new key type for OpenPGP (again, not a disaster - we're on our 4th key
> type today).

Ok,.. but then people would "loose" all their collected signatures on
their keys and to other keys :-(


> That isn't to say there aren't differences between systems - the FreeBSD
> PRNG (which seems to have been inherited by OSX) is of a fairly different
> construction than the Linux one, which has led to some mild controversy in
> the past.  Notably, the Linux one blocks if you run out of gathered entropy,
> and the FreeBSD one does not.  FreeBSD /dev/random is similar to Linux's
> /dev/urandom.

So I better use Linux and not FreeBSD ;)


> I'm not exactly sure what you mean by "hash algorithm armor".  RSA in
> OpenPGP does have a additional protection (usually called a "hash firewall")
> that DSA lacks.  This gives some protection against hash substitution
> attacks, but it's not a major deal either way.

Yeah,.. that's the issue I've meant...


> It's true that NIST's guidelines say that to truly get the maximum juice out
> of a 512-bit hash, you should use a 15360-bit key, but that doesn't mean you
> must.  That overall strength of the system is the weakest point, so as long
> as that weakest point is strong enough, you're fine.

*still cannot believe, that I've remembered the exact number :-O *


Thanks,
Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 2:43 PM

Post #19 of 43 (4051 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hello Daniel.



On Thu, Sep 10, 2009 at 6:22 PM, Daniel Kahn Gillmor
<dkg [at] fifthhorseman> wrote:
> The Key ID is a substring (either the last 8 or 16 hex chars) of the Key
> Fingerprint (which is 40 hex chars).  The Key ID is used nowhere in the
> internals of the OpenPGP specification, from what i can tell.

I think I've messed up the terms fingerprint and key ID, sorry :-(


> The fingerprint itself is used only in the designated revocation key
> [0], which is an acknowledged weakness of the cryptosystem [1].  It's
> not used anywhere else that i can tell.

Ok,.. I'm confused now.
David said,.. the community would probably have to create a new key
type or version at some point.
But this sounds more, that if I simply don't use designated revocation
keys,... I don't use SHA1 at all,.. and would be fine to simply swtich
to another algorithm.


Regards,
Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


philcerf at googlemail

Sep 10, 2009, 2:44 PM

Post #20 of 43 (4055 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

On Thu, Sep 10, 2009 at 10:21 PM, Robert J. Hansen <rjh [at] sixdemonbag> wrote:
> I understood him to mean the "key ID" as the fingerprint of the
> certificate's primary signing key, rather than checking each bit of the
> certificate's primary signing key individually.

I meant the fingerprint, yes.
But now that you say it. Would it be "better" to not just check other
keys via their fingerprint, but to really copy them (e.g. per
USB-stick) from their owners and sign only such direct copies?


Philippe.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


christoph.anton.mitterer at physik

Sep 10, 2009, 3:11 PM

Post #21 of 43 (4053 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi folks.



On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote:
> The real headache here is (as always) the practical - what to do with
> existing keys and such. I suspect that removing SHA1 would
> effectively mean a new key type for OpenPGP (again, not a disaster -
> we're on our 4th key type today).
Wahhhh .... will loose all my signatures *G*
Ok seriously: ...


This is _really_ nice (especially as there are Debian packages for
it :-D)
> See also http://www.entropykey.co.uk/
Anyway,.. I'm really not an randomness-expert so perhaps some questions:

1) Is this already supported by gpg?


2) If so,.. where would gpg use it? Only for symmetric keys? Or also for
asymmetric?


3) One problem with such devices is,.. that one can never know (well at
least normal folks like me) how good they actually are.
If this company would be evil (subsidiary of NSA or so) they could just
sell bad devices that produce poor entropy thus rendering our (symmetric
and asymmetric) keys, signatures etc. "useless". Right?

So my question is basically,..
If gpg would use this,... does it only improve the already existing
entropy and randomness of the kernel PRNG? I mean that gpg somehow
"merges" the different sources?
Or is it more or less a,.. either use the kernel PRNG or the hardware
RNG.

If there is such a "merging",.. how well does it work? I mean imagine
the device would be very evil (or just stupid) and produce only 0's or
1's or series of 0101's or something like this.
Would the "merging" produce entropy that's still as least as good as if
one would just have the kernel PRNG? Or would it yield in weaker
randomness.

(sorry for my non-expert terminology here ;) )


> > - When creating new keys (I'd like to "convince" some more friends to
> > take part :) )... should they create their keys with gpg1 or gpg2? Or
> > is the key generation equally secure?
>
> Equally secure. In fact, it's almost the same code.
I really wonder if you'll maintain both versions forever :-) ;)


Happy crypting,
Chris.
--
Grid Monkey
Attachments: smime.p7s (3.31 KB)


christoph.anton.mitterer at physik

Sep 10, 2009, 3:32 PM

Post #22 of 43 (4048 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi folks.



On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote:
> The real headache here is (as always) the practical - what to do with
> existing keys and such. I suspect that removing SHA1 would
> effectively mean a new key type for OpenPGP (again, not a disaster -
> we're on our 4th key type today).
Wahhhh .... will loose all my signatures *G*
Ok seriously: ...


This is _really_ nice (especially as there are Debian packages for
it :-D)
> See also http://www.entropykey.co.uk/
Anyway,.. I'm really not an randomness-expert so perhaps some questions:

1) Is this already supported by gpg?


2) If so,.. where would gpg use it? Only for symmetric keys? Or also for
asymmetric?


3) One problem with such devices is,.. that one can never know (well at
least normal folks like me) how good they actually are.
If this company would be evil (subsidiary of NSA or so) they could just
sell bad devices that produce poor entropy thus rendering our (symmetric
and asymmetric) keys, signatures etc. "useless". Right?

So my question is basically,..
If gpg would use this,... does it only improve the already existing
entropy and randomness of the kernel PRNG? I mean that gpg somehow
"merges" the different sources?
Or is it more or less a,.. either use the kernel PRNG or the hardware
RNG.

If there is such a "merging",.. how well does it work? I mean imagine
the device would be very evil (or just stupid) and produce only 0's or
1's or series of 0101's or something like this.
Would the "merging" produce entropy that's still as least as good as if
one would just have the kernel PRNG? Or would it yield in weaker
randomness.

(sorry for my non-expert terminology here ;) )


> > - When creating new keys (I'd like to "convince" some more friends to
> > take part :) )... should they create their keys with gpg1 or gpg2? Or
> > is the key generation equally secure?
>
> Equally secure. In fact, it's almost the same code.
I really wonder if you'll maintain both versions forever :-) ;)


Happy crypting,
Chris.
--
Grid Monkey
Attachments: smime.p7s (3.31 KB)


christoph.anton.mitterer at physik

Sep 10, 2009, 3:32 PM

Post #23 of 43 (4050 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Hi Robert.



On Thu, 2009-09-10 at 10:54 -0400, Robert J. Hansen wrote:
> Nope, it's pretty pervasive in the system.
I thought it (and SHA1 fingerprints) would only be used in designated
revoker signatures, and MDC?


> The people behind OpenPGP are working on a new OpenPGP proposal that
> will use a stronger, better hash algorithm.
Have workings on an 4880 successor already started?
Perhaps some of you (David?) remember the discussion that took place
here and on the WG list some time ago about things like:
- how criticality and critical bit could be handled much stricter
- potential problems that arise because conforming implementation are
only recommended to ignore signatures of an older time (especially
self-sigs).
- some other places where OpenPGP could (and for security reasons
perhaps should) be more strict and demanding to (conforming)
implementations
- Ideas for much broader use of attributes (different types of names,
birth-dates, -places, sex, etc. etc.)

So I wonder who's doing the (main) work for the writing this time? And
is there perhaps a wiki or so, where one could collect such suggestions?



Sincerely,
Chris.
Attachments: smime.p7s (3.31 KB)


rjh at sixdemonbag

Sep 10, 2009, 3:39 PM

Post #24 of 43 (4050 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Philippe Cerfon wrote:
> What specifically do you mean? Crypto-stuff in banking etc.?

"Specifically"? I don't have the time to list everywhere that will
break. SHA-1 is used in a ton of places, and often not places you'd
immediately expect. For instance, computer fuel injection timings are
controlled by software. Auto enthusiasts would like to be able to
customize them, but can't. If SHA-1 breaks, auto enthusiasts will be
able to forge their own signatures and deliver their own "updates" to
their engines.

Skype will potentially break. Many P2P networks (including the ones
Skype is based upon) use a mathematical construct called a "distributed
hash table" to figure out how to route data. If the hash algorithm is
bad, well, you're out of luck.

Filesystems will suffer. There exist some filesystems that avoid
storing redundant data by tracking a hash of each file. If the file
you're writing matches a hash that's already on the disk, the filesystem
just puts in a soft link.

That's three examples of things that will unexpectedly break if SHA-1
falls. A complete laundry list would go for pages and pages and pages.
I'd suggest reading comp.risks; they might have something on point.

> But attackers could still attack older data, that they intercepted, right?

No.

Imagine that in 2010, the OpenPGP Working Group publishes a new key
specification. v5 keys use SHA256, not SHA1. I revoke my current key
and migrate to a new v5 key.

In 2015, the SHA-1 attack becomes practical. Someone goes back to my
old messages and lifts a signature off something I've written. They
construct a new message that hashes out the same as my old message, and
put my old signature on a new message. "Look, look! He signed a
message in 2009 claiming that he'd pay me $1 million in 2015! Pay up,
Mr. Hansen!"

No one would take such a forgery seriously.



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Sep 10, 2009, 4:18 PM

Post #25 of 43 (4052 views)
Permalink
Re: howto secure older keys after the recent attacks [In reply to]

Philippe Cerfon wrote:
> But now that you say it. Would it be "better" to not just check other
> keys via their fingerprint, but to really copy them (e.g. per
> USB-stick) from their owners and sign only such direct copies?

No.

Sharing media is a great way to spread malware. Don't do that to your
friends. Use the keyserver network.

SHA-1 is in trouble, but it's not dead yet, and regular users should not
be worried about it.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

First page Previous page 1 2 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.