Subject: Re: Czech attack to PGP

From: [email-masked]
Date: Wed, 28 Mar 2001 11:18:12 -0800

Werner Koch writes:

> No need for a new format - doing such changes for OpenPGP right now
> will delay getting to draft even more.
>
> There is a far easier way to do this and we can do this first in our
> implementations and use the old format for transferring secret keys
> (which is a Bad Thing doing it at all or over an insecure channel):

Yes, I like the idea of doing extra checks internally, while retaining
at least for now the current format as a data interchange.  We could
add language to the draft warning implementors to check the arithmetic
validity of the keys if the files may have been meddled with.

> We introcude a new S2K mode and encrypt this:
>
>  1. fingerprint of the public key
>  2. the secret MPIs
>  3. A SHA-1 hash over 1 and 2.

A thread on sci.crypt recently pointed to an AsiaCrypt 2000 paper by Mihir
Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is
a theoretical analysis showing that based on very minimal assumptions
of the properties of MAC and encryption algorithms, the strongest mode
is to encrypt and then MAC.  That is, you compute a keyed MAC on the
ciphertext in order to detect modification.

In our case we might just compute an HMAC over the entire secret key
packet, and append it.

Now, Bellare's analysis is highly theoretical, and some of the attacks
he shows on other modes are quite artificial.  In practice something
like what Werner suggests should be fine.  But still we might want to
consider using the Bellare approach since it is strong even when we
consider artificial-seeming attacks.

> So either each implementation uses it's own scheme or we agree
> informally on one in the (not officially reserved) private range of
> S2K mode.

The commercial version of PGP also uses some special S2K values, but
we could certainly decide on a new value to identify the new form of
checksum.

Hal

---

From: "Michael Young" <[email-masked]>
Date: Wed, 28 Mar 2001 17:22:49 -0500

-----BEGIN PGP SIGNED MESSAGE-----

> > We introcude a new S2K mode and encrypt this:

Why is a new S2K mode preferable to a new key version?

The S2K is used in more than just the secret key packet.
Adding another context-specific flag to the S2K seems
wrong (unless you meant for this checksumming behavior
to apply to other uses, which also seems wrong).

Do you think that existing implementations would just
happen to ignore extra bits in the S2K specifier and
extra checksum bytes at the end?  If so, I admire
the trickery, but I don't think this is serious
enough to warrant it in the spec -- as many folks have
pointed out, local key storage can use any hackery
an implementation likes anyway.

> The commercial version of PGP also uses some special S2K values, but

Yes... the "raw" key used in key-splitting.

Which brings me to another point: can we at least
put placeholders in the spec for these existing PGP
product features?  I know that some of these hidden
features (ADKs, for instance) are unpopular, but an
OpenPGP implementation may well run across them.
I'd really like the spec to say how they appear (and
even what they do), even if it does not endorse them,
so that implementations can recognize them if they want.
The spec does have a "placeholder" for the ADK
subpacket.  Shouldn't it for the S2K extensions?
Are there others we just haven't run across yet?

---

From: Bill Frantz <[email-masked]>
Date: Wed, 28 Mar 2001 16:12:43 -0800

>In our case we might just compute an HMAC over the entire secret key

I must admit that when coding for the real world, I always liked checking
the MAC as late as possible.  That lets the MAC check as much of the
process as possible for errors.  (If you compute the MAC before encryption
and check it after decryption, the MAC checks the encryption-decryption
process.  In real life, I have found a timing dependant error using this
check.)

In the specific case of secret keys, the arithmetic consistency checks may
result in the same degree of assurance as a MAC, so applying the MAC after
encryption and checking it before decryption may be the right answer.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz       | Microsoft Outlook, the     | Periwinkle -- Consulting
(408)356-8506     | hacker's path to your      | 16345 Englewood Ave.
[email-masked] | hard disk.                 | Los Gatos, CA 95032, USA

---

From: Werner Koch <[email-masked]>
Date: Thu, 29 Mar 2001 09:43:19 +0200

> Bellare, http://www-cse.ucsd.edu/users/mihir/papers/oem.html.  This is

Thanks.

> In our case we might just compute an HMAC over the entire secret key

This still does not solve the problem, how to get the key for the
HMAC.  I didn't read the Bellare paper in detail but I can't see
that it goes into the problem of possible interaction between the
encryption and HMAC key.  I think it is good practise, not to use
the same key (or a derived onbe).  So we would need a second
passphrase - argh.

> we could certainly decide on a new value to identify the new form of

Can you please tell us which identifiers you use, so that we don't
run into problems if we encounter such identifiers.  

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus