Re: [Cfrg] Request For Comments: OCB Internet-Draft

David McGrew <> Thu, 21 July 2011 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC5E21F86D0 for <>; Thu, 21 Jul 2011 14:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.561
X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Db9mwshHCf1R for <>; Thu, 21 Jul 2011 14:40:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E1E021F86AA for <>; Thu, 21 Jul 2011 14:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3117; q=dns/txt; s=iport; t=1311284428; x=1312494028; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=/wbB00EgQBC4NqXFCMq6GcUeiFcUIs6dW+mVUZ9c1jI=; b=b7Ji+tCLD9aRPGnCftn1TjmaZz2R9B1yU0onKy5S6iKdK3MeclXsbFUg rcGSqT7CV0a6xBlJPxn5f5ed+ibTHR7YbTkhbmYRBDQRx2wWAgeIWZKRQ g8PWPsHnXDPn5bzIvvLMuCvf4U3JE2xAEPmexivuRkwn4ZG1ujCtU7F+5 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAF6cKE6rRDoH/2dsb2JhbABTG6cnd4h8nQWeIIVgXwSHVYsZkH4
X-IronPort-AV: E=Sophos;i="4.67,243,1309737600"; d="scan'208";a="5273105"
Received: from ([]) by with ESMTP; 21 Jul 2011 21:40:27 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p6LLeQbD024185; Thu, 21 Jul 2011 21:40:26 GMT
Message-Id: <>
From: David McGrew <>
To: Ted Krovetz <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 21 Jul 2011 14:40:25 -0700
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.936)
Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2011 21:40:29 -0000

Hi Ted,

thanks for this contribution.  I have not yet read it through, but  
after I do I'll send you my thoughts.  I have a comment on the  
security considerations being discussed.  This topic was already  
worked through for GCM and CCM, and it would be best to use similar  
language for OCB.

On Jul 15, 2011, at 9:45 AM, Ted Krovetz wrote:

>> If you know how "partial" that is, it would be useful for the draft.
>> Ted, I think you can be rather more specific.
> In my opinion the point of the nonce-reuse warning is to impress  
> upon security engineers that catastrophe strikes if a nonce is  
> reused during encryption, and so they should make nonce reuse  
> impossible. If nonce reuse is impossible, then it is irrelevant how  
> bad the damage is when nonces are reused.
> RFC writers need to walk a fine line: RFCs are primarily a  
> description of technology, but should include enough high-level  
> context to inform against poor usage. I think the current warnings  
> on nonce reuse do this, but if you can suggest a scenario where the  
> current advice is being heeded and yet it is still useful to know  
> how bad not heeding it would be, I'm open to adding some  
> quantifications.
> It may be worth adding a few paragraphs to the OCB paper describing  
> and quantifying the damage, but I'm a bit reluctant to do so in the  
> ID.

The draft should include text like that of Section 5.1.1 of RFC 5116,  
ideally using the same wording where possible, ideally in a subsection  
entitled "Nonce Reuse".  I think this text, adapted from that section,  
is appropriate:
The inadvertent reuse of the same nonce by two invocations of the OCB  
encryption operation, with the same key, but with distinct plaintext  
values, undermines the confidentiality of the plaintexts protected in  
those two invocations, and undermines all of the authenticity and  
integrity protection provided by that key.  For this reason, OCB  
should only be used whenever nonce uniqueness can be provided with  
assurance.   Note that it is acceptable to input the same nonce value  
multiple times to the decryption operation.   The security  
consequences are quite serious if an attacker observes    two  
ciphertexts that were created using the same nonce and key values,  
unless the plaintext and AD values in both invocations of the encrypt  
operation were identical.  First, a loss of confidentiality ensues  
because he will be able to infer relationships between the two  
plaintext values. Second, a loss of integrity ensues because the  
attacker will be able to recover secret information used to provide  
data integrity. Knowledge of this key makes subsequent forgeries  
Here I am assuming that the newer version of OCB is still vulnerable  
to Fergusen's collision attack ( 
); please correct me if I'm wrong.

> _______________________________________________
> Cfrg mailing list