Subject: [Cfrg] Possible RFC: Data integrity combined with encryption

From: [email-masked] (Terry Hayes)
Date: Thu, 19 Sep 2002 14:59:20 -0700

The current discussion on this list about the security of OpenPGP is covering
an interesting set of topics relating to protocols that try to provide both
encryption and integrity.  I think this group could provide valuable information
to IETF by creating an RFC that describes the best current practices in this
area.

Right now it is difficult for designers to get good information on how to
build protocols that provide both encryption and integrity.  In fact, some
of the best known sources of information about cryptographic algorithms seem
to provide methods that are now believed to be incorrect.  For example, Handbook
of Applied Cryptography (Menezes, van Oorschot and Vanstone) contains a section
in Chapter 9 called "Data integrity using encryption and an MDC".  This section
essentially describes the method proposed in OpenPGP.  While it does include
remarks about the dangers of using this method with stream ciphers in situations
where there is known plaintext, the overall impression is that it is always
good method when used with block ciphers in CBC mode. The RFC might describe
what steps should to be taken to use this method in a protocol (if it is possible
at all).

The following section in HAC describes including a MAC to provide integrity.
However it describes the method of including the MAC inside the encrypted
data, computed on the plaintext.  Hugo Krawczyk's work on the order of encryption
and authentication shows that reversing these might be better.  The RFC might
describe the preferred method (encrypt then authenticate) and indicate when
it would be safe or more appropriate to do something else (if ever).

I have quite often heard the mantra "sign and then encrypt".  Applying this
rule leads to designs like authenticate-then-encrypt.  The RFC might describe
situations where signing first is important, and distinguish them from the
cases where encrypt-then-authenticate is the preferred thing to do.

Finally, there are new modes under consideration (such as OCB and CCM) that
provide both encryption and integrity.  The RFC might mention these new modes,
and possibly recommend one that should be used.

I would find an RFC that covers these issues very useful.  What do others
think?

Terry Hayes

[email-masked]

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Mihir Bellare <[email-masked]>
Date: Thu, 19 Sep 2002 16:12:59 -0700

> encryption and integrity.  I think this group could provide valuable
> information to IETF by creating an RFC that describes the best current
> practices in this area.

An RFC might indeed be valuable. Meanwhile I just thought I'd point out that
there are papers about these topics out there, for example:

1. On the generic composition methods methods mac-then-encrypt, 
   encrypt-then-mac and mac-and-encrypt:

*  M. Bellare and C. Namprempre.Authenticated Encryption: Relations among
   notions and analysis of the generic composition paradigm. Asiacrypt 2000.
   http://charlotte.ucsd.edu/users/mihir/papers/oem.html

*  H. Krawczyk. The Order of Encryption and Authentication for Protecting 
   Communications (or: How Secure Is SSL?). CRYPTO 2001. 

2. On the possibility of encryption-with-redundancy (meaning, constructs like
   appending an MDC and then encrypting) providing authenticity:

*  J. An and M. Bellare. Does encryption with redundancy provide authenticity? 
   Eurocrypt 2001. http://charlotte.ucsd.edu/users/mihir/papers/enc-red.html

3. On the use of generic composition in SSH:

*  M. Bellare, T. Kohno and C. Namprempre. Provably Fixing the SSH Binary 
   Packet Protocol. http://charlotte.ucsd.edu/users/tkohno/papers/SSH/ssh.html

Regards,

-Mihir

---

From: Aram Perez <[email-masked]>
Date: Thu, 19 Sep 2002 17:15:48 -0700

Hi Terry,

I think it¹s a great idea! Many times I¹ve had to argue points based on
³good security practice² and have been lucky that no one has asked ³Show me
where it states that². Having an RFC with best current practices would
provide me a document to refer to. It seems that most books on cryptography
explain the basic algorithms but not how to use them correctly in the
context of using them in a protocol.

My dos centavos,
Aram

Terry Hayes wrote:

> build protocols that provide both encryption and integrity.  In fact, some of
> the best known sources of information about cryptographic algorithms seem to
> provide methods that are now believed to be incorrect.  For example, Handbook
> of Applied Cryptography (Menezes, van Oorschot and Vanstone) contains a
> section in Chapter 9 called "Data integrity using encryption and an MDC".
>  This section essentially describes the method proposed in OpenPGP.  While it
> does include remarks about the dangers of using this method with stream
> ciphers in situations where there is known plaintext, the overall impression
> is that it is always good method when used with block ciphers in CBC mode. The
> RFC might describe what steps should to be taken to use this method in a
> protocol (if it is possible at all).
> 
> data, computed on the plaintext.  Hugo Krawczyk's work on the order of
> encryption and authentication shows that reversing these might be better.  The
> RFC might describe the preferred method (encrypt then authenticate) and
> indicate when it would be safe or more appropriate to do something else (if
> ever).
> 
> _______________________________________________ Cfrg mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/cfrg