[Cfrg] Repeated one-time pad

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 14 July 2011 19:42 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9522F21F8C35 for <cfrg@ietfa.amsl.com>; Thu, 14 Jul 2011 12:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id m2drL0WJ16ci for <cfrg@ietfa.amsl.com>; Thu, 14 Jul 2011 12:42:02 -0700 (PDT)
Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 77BDB21F8C02 for <cfrg@irtf.org>; Thu, 14 Jul 2011 12:42:02 -0700 (PDT)
Received: by wwe6 with SMTP id 6so615316wwe.19 for <cfrg@irtf.org>; Thu, 14 Jul 2011 12:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oq3QPFBZzwOddnCeZoKCr8jx5J44CT/DDZ2gcInmIIo=; b=s7P5X2b0hGv9II72kqwRI3QYksfeqQ47ZCJlc87l4eTePQpVHFnxAemzmeiKrmL6kq FZvqPF4ZDJBp6C5jxY/cw3fXrCxraJt+FYyx7yx8xfQ1wRwybIei53Vp6kmDXaSoKsi7 y3ctZ04Za0WWhTgKbJxCmXegPli15dx/cYOb0=
Received: by with SMTP id a11mr2379302wbx.74.1310672521289; Thu, 14 Jul 2011 12:42:01 -0700 (PDT)
Received: from [] (bzq-79-178-192-3.red.bezeqint.net []) by mx.google.com with ESMTPS id fc2sm474208wbb.52.2011. (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 12:42:00 -0700 (PDT)
Message-ID: <4E1F467C.8090702@gmail.com>
Date: Thu, 14 Jul 2011 22:41:48 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <mailman.117.1310670016.1187.cfrg@irtf.org>
In-Reply-To: <mailman.117.1310670016.1187.cfrg@irtf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Cfrg] Repeated one-time pad
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: Thu, 14 Jul 2011 19:42:06 -0000

Regarding "immediate key disclosure": is is well known that reuse of a 
stream cipher or a one-time pad with different plaintexts leads to 
immediate exposure of the plaintext (see e.g. 
http://en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course 
I am teaching, I would appreciate pointers to the algorithms that are 
used for this cryptanalysis and/or source code that implements this attack.


Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson 
<simon@josefsson.org> To: Ted Krovetz <ted@krovetz.net> Cc: 
cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB 
Internet-Draft Message-ID: <87ipr5gukz.fsf@latte.josefsson.org> 
Content-Type: text/plain Ted Krovetz <ted@krovetz.net> writes:
>> I have just submitted an internet-draft for OCB to the IETF.
>>    http://datatracker.ietf.org/doc/draft-krovetz-ocb
>> I'd appreciate any comments you may have on how to make the draft better.
> It would help if you explained (in the security considerations) what
> happens if a nonce is repeated.  The question of failure modes of
> authenticated encryption modes has come up in several different
> contexts.  It turns out that different AEAD modes have different failure
> properties.
> In particular, you want to address whether repeat of a nonce leads to
> immediate key disclosure, or whether the key can be found after some
> computation faster than obvious attacks, or whether it can only lead to
> recovery of the plaintext, and/or whether it depends on the plaintext as
> well (e.g., something interesting happens if the plaintexts are related).