Subject: security fixes (KDF, MDC->MAC)?

From: Trevor Perrin <[email-masked]>
Date: Thu, 26 Sep 2002 12:18:01 -0700

Hello OpenPGP,

Is there interest in fixing the security flaws discussed in the recent
"security analysis" thread? -

(1) the Integrity Protected Data and MDC Packets fail to stop Schneier et
al's attack, because the ciphertext blocks can be pasted into a
non-integrity protected packet (ie ciphertext from a tag 18 packet can be
placed in a tag 9 packet, evading the MDC).

(2) Once an attack like above recovered the prefix data, forgeries are
possible:
http://www.imc.org/ietf-openpgp/mail-archive/msg05804.html

One fix (due to John Kane) would be a version 2 of the integrity-protected
packet (tag 18).  This new version would use a key derivation function (KDF)
to derive separate encryption and authentication keys.  The authentication
key would be used by a new MAC packet (say tag 20), which would be just like
the MDC packet but use HMAC-SHA1 instead of SHA1.

Version = Integrity Protected Data Packet Version Number (2)
EncKey  = KDF(SessionKey, Version, 0)
AuthKey = KDF(SessionKey, Version, 1)

Since the encryption key is now the result of a version-dependent KDF,
downgrade attacks like (1) are prevented.

Since the MAC depends on the AuthKey which an attacker doesn't know,
forgeries (2) are prevented.

So what do people think?  Is a fix like this worth it?

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 27 Sep 2002 12:16:37 -0700

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>
>5.13.
>[...]    Unlike the Symmetrically Encrypted Data Packet, no
>   special CFB resynchronization is done after encrypting this prefix
>   data.
>
>doesn't this prevent converting packet 18 to 9 ?
>

It doesn't completely prevent the JKS attack.  The attacker can still copy
the first two blocks of ciphertext from a packet 18 to 9, and the check
bytes will decrypt appropriately, but the remainder of the second block will
be scrambled.

So this will probably leave a malformed packet header, but there's a chance
the header might still work, depending on how strict the parsing code is
(for example, what if the packet tag gets randomly set to 9, but the length
is wrong?).  The attacker can flip bits in the remainder of the second block
and keep submitting guesses to a decryption oracle, until he stumbles on a
packet header that makes the attack work.  

The attacker may also learn information from observing the oracle which lets
him reconstruct the keystream bytes that the ciphertext is being XOR'd with.
For example, if the oracle says "Error: packet tag 62 not supported", the
attacker can reconstruct the keystream bits that correspond to the packet
tag, and thus gain the ability to control its value.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 27 Sep 2002 12:23:04 -0700

Fixed a typo-

So this will probably leave a malformed packet header, but there's a chance
the header might still work, depending on how strict the parsing code is
(for example, what if the packet tag gets randomly set to 11 for Literal
Data, but the length is wrong?).  The attacker can flip bits in the
remainder of the second block and keep submitting guesses to a decryption
oracle, until he stumbles on a packet header that makes the attack work.  

Trevor