Re: [Cfrg] draft-housley-ccm-mode-00.txt

pgut001@cs.auckland.ac.nz (Peter Gutmann) Fri, 16 August 2002 04:15 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25943 for <cfrg-archive@odin.ietf.org>; Fri, 16 Aug 2002 00:15:08 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA28786 for cfrg-archive@odin.ietf.org; Fri, 16 Aug 2002 00:16:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28767; Fri, 16 Aug 2002 00:16:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28742 for <cfrg@optimus.ietf.org>; Fri, 16 Aug 2002 00:16:12 -0400 (EDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25936 for <cfrg@ietf.org>; Fri, 16 Aug 2002 00:14:50 -0400 (EDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7G4Fe8W001972; Fri, 16 Aug 2002 16:15:40 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA18722; Fri, 16 Aug 2002 16:15:40 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Date: Fri, 16 Aug 2002 16:15:40 +1200 (NZST)
Message-ID: <200208160415.QAA18722@ruru.cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ggr@qualcomm.com, rhousley@rsasecurity.com
Subject: Re: [Cfrg] draft-housley-ccm-mode-00.txt
Cc: cfrg@ietf.org
Sender: cfrg-admin@ietf.org
Errors-To: cfrg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
X-BeenThere: cfrg@ietf.org

Greg Rose <ggr@qualcomm.com> writes:

>Doing the authentication and the encryption with the same key is bad
>practice. You should take the input key, and derive from it two subordinate
>keys, which are independent of each other as far as an outside attacker can
>tell, then use one of them for the counter mode encryption, the other for
>the CBC-MAC.

This doesn't work if your crypto hardware or software doesn't give you
access to the key, which is quite common.  The way I was doing it for the
encrypt+MAC is to use the encryption algorithm to generate a MAC key by
encrypting an all-zero block(s), this both avoids the problem of key
inaccessibility and means that a rollback attack is made more difficult
since the first block of ciphertext is scrambled (it isn't 100%
bulletproof, but will catch most attempts to roll back from encrypt+MAC
to encrypt-only).

Peter.


_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg