Daniel A. Nagy | 9 Jan 01:03 2009

Re: A review of hash function brittleness in OpenPGP

Daniel Kahn Gillmor wrote:
> The X.509 community was able to respond by further deprecating MD5
> because there was a parameterized method in place to switch to another
> hash function.  OpenPGP currently has this in place almost everywhere a
> hash function is used.  That's good!

As far as I can judge, X.509 PKI is still in the state of catastrophic failure
with no obvious way out.

Right now, if my browser (or yours, or anybody else's) tells me that the site I
am browsing presented a certificate issued to it by a legitimate CA, I cannot be
sure that this assertion is true. Rejecting all certificates with MD5 in their
signatures is not a solution (there are too many out there and replacing them
requires non-trivial cooperation between different parties; no-one can do it
acting alone). Not issuing any more MD5-based certificates is not a solution
(who knows how many rogue CAs are already out there?). In fact, I do not see an
easy and cheap solution out of this mess.

It is a good thought-experiment to assess the consequences of an existential
collision attack on SHA1 such as the one we have for MD5 on OpenPGP security,
considering all the places where SHA1 is wired in. I haven't checked every
corner of RFC4880, but I can see no catastrophic failure akin to what happened
to X.509 PKI.

--

-- 
Daniel

Ben Laurie | 9 Jan 15:51 2009

OpenPGP:SDK v0.9 released


I thought people might be interested in this now somewhat-complete,
BSD-licensed OpenPGP library...

http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Jon Callas | 10 Jan 22:56 2009

Re: A review of hash function brittleness in OpenPGP


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote:

>
> Jon Callas wrote:
>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>> created a one-pass MAC construction that can replace HMAC. It also  
>> has
>> a proof of security.
>
> I wish people would stop saying that things have "a proof of  
> security".
> Rot13 has a proof of security, but I don't want to use it. You need to
> state what security properties you have proved.

If we're going to get picky, Rot-13 is not a cipher, it's a code. It  
has similar security properies to ASCII, which is a related code. But  
you're right -- on another list I'm on, there was someone who made the  
comment that there's no theoretically perfect cryptography. I almost  
replied that the Caesar cipher (which is ROT-N) has perfect security,  
just an inadequate key space.

Nonetheless, you're right. Many people including me sneer at security  
proofs. The list of things that have had proofs of security and then  
fallen over is large. There are plenty of proofs of security that have  
some people raise an eyebrow. For example, we say that HMAC is secure  
on today's slightly dodgy hash functions because of a proof of  
(Continue reading)

Florian Weimer | 11 Jan 18:04 2009
Picon

Re: A review of hash function brittleness in OpenPGP


* Daniel Kahn Gillmor:

> Also, it's quite likely that i've missed things in my reading of the
> spec.  If anyone sees any other problematic areas, it would be great to
> air them as soon as possible.

There's the issue of V3 keys.

If packet formats are changed once again, it could make sense to
incorporate random blobs near the start of the packets, so that an
attacker cannot predict the internal state of the hash function when a
signature is created.  OpenPGP does not need the convergent property
of hash functions.

Peter Gutmann | 13 Jan 07:50 2009
Picon
Picon
Picon

Re: A review of hash function brittleness in OpenPGP


Ben Laurie <ben <at> links.org> writes:
>Jon Callas wrote:
>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>> created a one-pass MAC construction that can replace HMAC. It also has
>> a proof of security.
>
>I wish people would stop saying that things have "a proof of security". Rot13
>has a proof of security, but I don't want to use it. You need to state what
>security properties you have proved.

On the subject of provable security, I've just been reading a paper that
provides a rigorous proof that a particular security mechanism is secure
(under appropriate assumptions regarding the cryptographic functions used).
Unfortunately this is a mechanism that's a slight variant of "click-OK-to-
continue", which means that it's close to worthless in practice (this result
both anecdotally and from a number of HCI papers that have evaluated it).  So
this would be a prime example of a rigorous provably-secure crypto mechanism
that thirty seconds of googling or a beer's worth of analysis would show
doesn't actually work.

(I haven't mentioned the paper name because I'm not trying to attack the 
author, just using it as a nice example of a provably secure but practically 
insecure mechanism, I can provide details in private email if anyone really 
wants to know).

Peter.

Ben Laurie | 13 Jan 12:30 2009

Re: A review of hash function brittleness in OpenPGP


Jon Callas wrote:
> 
> On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote:
> 
>> Jon Callas wrote:
>>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>>> created a one-pass MAC construction that can replace HMAC. It also  
>>> has
>>> a proof of security.
>> I wish people would stop saying that things have "a proof of  
>> security".
>> Rot13 has a proof of security, but I don't want to use it. You need to
>> state what security properties you have proved.
> 
> If we're going to get picky, Rot-13 is not a cipher, it's a code.

So what?

> It  
> has similar security properies to ASCII, which is a related code. But  
> you're right -- on another list I'm on, there was someone who made the  
> comment that there's no theoretically perfect cryptography. I almost  
> replied that the Caesar cipher (which is ROT-N) has perfect security,  
> just an inadequate key space.
> 
> Nonetheless, you're right. Many people including me sneer at security  
> proofs.

Then why mention them?
(Continue reading)

Peter Thomas | 27 Jan 22:54 2009

Series of minor questions about OpenPGP 4


Hello list.

As you can see from the subject this is already the 4th email in a
series of questions about OpenPGP (and in some cases gnupg).
After the first three David Shaw, who perfectly answered my questions
so far (lots of thanks again), asked me to move here, as it became
more and more OpenPGP specific.
For those who are interested (the previous ones also contained
questions about OpenPGP itself, and some very great answers) you can
find the other ones here:
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035445.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035458.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035467.html

This time it's all about signature subpackets:
Sorry that this got longer, but I think these points are all somehow
connected. So feel free to split up as you like :-)
I know that these questions are more about OpenPGP itself than gnupg,
but perhaps you, David, can have a look at them here, before I post it
on their mailing list (don't want to look stupid there ^^ and I'm
still quite new in OpenPGP's standard).

1) gnupg (and as far as I can see other implementations, too) don't
set the critical bit on much signature subpackets by default. The RFC
(AFAIK) doesn't demand any subpacket to be understood by applications.
Unknown subpackets should be ignored, except the critical bit is set.
Correct so far?
Now when I go through the currently defined signature subpackets, I
see several which are or at least could be critical for security and
(Continue reading)

Hal Finney | 28 Jan 19:48 2009

Re: Series of minor questions about OpenPGP 4


Hello Peter -

I will answer your questions on the assumption that you are writing
OpenPGP compliant software. You are therefore asking about how you should
implement your software.

> 1) gnupg (and as far as I can see other implementations, too) don't
> set the critical bit on much signature subpackets by default. The RFC
> (AFAIK) doesn't demand any subpacket to be understood by applications.
> Unknown subpackets should be ignored, except the critical bit is set.
> Correct so far?
> Now when I go through the currently defined signature subpackets, I
> see several which are or at least could be critical for security and
> for the correct evaluation of signatures:
> 2, 3: a signature might not be valid yet, or might be expired already
> 7: an attacker might manage to revoke an irrevocable signature
> 9: they key is expired and the owner does not want it to be used any
> longer (maybe also due to security reasons)
> 12: if an implementation doesn't understand this, it might not notice,
> that a key/UID is already revoked
> 26: the policy may contain critical information for security (e.g.
> "this key signs any applicant without validating his personal data)
> 27: it might be a security issue, if a key that was marked for
> certification-only (0x01) has signed some casual data
> 31: required for revocation signatures and thus possibly security critical
> 32: required for the signing subkey backsigs (0x19)
>
> I'd even consider the following as critical:
> 28: the signer might want to express that a specific role/UID made the
(Continue reading)

Peter Thomas | 29 Jan 18:42 2009

Re: Series of minor questions about OpenPGP 4


Hi Hal.

On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" <hal <at> finney.org> wrote:
> I will answer your questions on the assumption that you are writing
> OpenPGP compliant software. You are therefore asking about how you should
> implement your software.
Yes and no.
I'm actually thinking about writing an OpenPGP key editor (perhaps
using parts of gnupg as backend) which can do nearly everything that
the RFC allows to give geeks and freaks the opportunity to try out
everything which shouldn't be possible for the average user (that said
I fully like the way gnupg - and probably other implementations -
"guide" the user).

But my discussion here is more about how could the RFC be improved.
Please don't get me wrong, I don't wanna say the RFC is crap or anyone
here did make wrong things or so and I'm fully aware that I'm really a
newbie here.
But what I see is that X.509 based PKIs which are based on a strict
hierarchical trust model are spread more and more. And personally I
dislike it and consider hierarchical trust models inferior to what
OpenPGP allows.
Most governments fully set on X.509 based PKIs and don't consider or
even support OpenPGP and even most technical standards or applications
are only X.509 aware (see SSL/TLS, although we have RFC 5081).

What it all comes down to is: I think there are places where the RFC
and thus OpenPGP could be improved maybe I'm wrong but nevertheless
I'll tell this list my ideas.
(Continue reading)

Peter Thomas | 29 Jan 19:23 2009

Ideas on new user attribute types and image formats


Hi list.

This is not an official proposal or request. I haven't read RFC2434 yet ;-)

Just wanted to ask about opinions and ideas for new user attribute
types and image formats.

First perhaps the image formats as these are easier to discuss:
Of course JPEG is in principle enough and it's probably a very bad
idea to include any image type GIMP can open ;-) but I think the
following might be worth thinking about:
1) PNG (ISO 15948, RFC 2083)
Advantages:
- just as JPEG, nearly everybody can open these image format in the
meantime (even MS IE as far as I know)
- well standardized (ISO/IETF RFC)
- "We" call our "product" OpenPGP but JPEPG is - as far as I know -
patent encumbered, but PGP is fully free.
- Is providing an alpha-channel an argument?! ;-)
- lossless compression

Disadvantages:
- lossless compression leading to much bigger packets than with JPEG

2) JPEG 2000 (ISO/IEC 15444)
Advantages:
- well standardized (ISO) ... ok one could question that ^^
- provides even better/smaller quality/image sizes than JPEG
(And I think to keep image-packets small was the main reason for choosing JPEG)
(Continue reading)


Gmane