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

Jack Lloyd <lloyd@randombit.net> Fri, 15 July 2011 17:38 UTC

Return-Path: <lloyd@randombit.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC43221F8567 for <cfrg@ietfa.amsl.com>; Fri, 15 Jul 2011 10:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG4KFpV472Ri for <cfrg@ietfa.amsl.com>; Fri, 15 Jul 2011 10:38:40 -0700 (PDT)
Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8921F8563 for <cfrg@irtf.org>; Fri, 15 Jul 2011 10:38:36 -0700 (PDT)
Received: by chihiro.randombit.net (Postfix, from userid 1000) id B9B9A2F0015E; Fri, 15 Jul 2011 13:38:35 -0400 (EDT)
Date: Fri, 15 Jul 2011 13:38:35 -0400
From: Jack Lloyd <lloyd@randombit.net>
To: cfrg@irtf.org
Message-ID: <20110715173835.GI13721@randombit.net>
References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <FD9110CA-6C21-492D-9DE3-027C77A0A31F@krovetz.net> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> <B89E1A56-0533-4420-B6C6-8B8F81BEC2CE@krovetz.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B89E1A56-0533-4420-B6C6-8B8F81BEC2CE@krovetz.net>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2011 17:38:41 -0000

On Fri, Jul 15, 2011 at 09:45:06AM -0700, Ted Krovetz wrote:

> 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.

I think part of the issue is that making something truly 'impossible'
is quite a bit harder than it might sound, especially in the face of
an active attacker who might well decide that the easiest way of
breaking the system is to force it to reuse a nonce somehow (this
seems especially likely in embedded systems, but a general system
might well be susceptible). Some plausible failure modes, like VM
state rollback [1], could even be attacked passively and
opportunistically.

Someone building or deploying a system (ie the sort of person who
would read an i-d or RFC) might well want to understand exactly how
fragile the system is when misused, which lets them make a realistic
and informed judgement of the tradeoffs in choosing between different
options.

Regards,
  Jack

[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg01349.html