Re: [Cfrg] Changes in draft-irtf-cfrg-ocb-03

David McGrew <mcgrew@cisco.com> Thu, 13 June 2013 17:46 UTC

Return-Path: <mcgrew@cisco.com>
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 9143B21F8D16 for <cfrg@ietfa.amsl.com>; Thu, 13 Jun 2013 10:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.8
X-Spam-Level:
X-Spam-Status: No, score=-109.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cR5RIx7bPsY for <cfrg@ietfa.amsl.com>; Thu, 13 Jun 2013 10:46:09 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0621F99C2 for <cfrg@ietf.org>; Thu, 13 Jun 2013 10:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2639; q=dns/txt; s=iport; t=1371145569; x=1372355169; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=x0XKlhkCBz8el+1NFD9OUrjJnu7f6axpXMfO9BIt4so=; b=gZlRdaP3YxRtf1yfCQZckcD4m/dSos+z96O0KpvBj3/KQNY7XJlyAhfx gb8KILE+E9nXCK6ewJ5d/SIYYuWNkN1E0XTbn7jPbTTdX1LrHimN3i/Hi KEdG2H32LKh9o3XQZ6xaX9OBp960r8RUTYF02ksZ9ubgCsg1eQCIwEbMA M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAEAEulGtJV2c/2dsb2JhbABbgwkwAUKCertJgQIWdIIjAQEBAwEBAQEgSwsQCxgCAiYCAicwBhMJh38GBwWpb5FUgSaLL4JuB4JMgRQDnWCLI4MrIA
X-IronPort-AV: E=Sophos;i="4.87,860,1363132800"; d="scan'208";a="222458305"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Jun 2013 17:46:09 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5DHk8rv020507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 17:46:08 GMT
Message-ID: <1371145567.3892.731.camel@darkstar>
From: David McGrew <mcgrew@cisco.com>
To: Ted Krovetz <ted@krovetz.net>
Date: Thu, 13 Jun 2013 13:46:07 -0400
In-Reply-To: <21F1AE1B-3783-4767-BDB4-1E40F8468372@krovetz.net>
References: <21F1AE1B-3783-4767-BDB4-1E40F8468372@krovetz.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] Changes in draft-irtf-cfrg-ocb-03
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, 13 Jun 2013 17:46:14 -0000

On Wed, 2013-06-12 at 15:56 -0700, Ted Krovetz wrote:
> I have just posted a revised Internet-Draft for OCB.
> 
>   <https://datatracker.ietf.org/doc/draft-irtf-cfrg-ocb/>
> 
> A nice diff can be seen at
> 
>   <http://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-ocb-03>
>  
> The most significant changes are:
> 
> 1. OCB uses an internal 128-bit nonce which is constructed from user-supplied nonce N as
> 
>  `Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N`  
> 
>  This changes all generated tags except those that are 128 bits. The macro `num2str` is also new and is now defined in the notation section.
> 
> 
> 2. The end of Appendix A adds test vectors for each named parameter set. All other test vectors are unchanged because they had 128-bit tags.
> 
> 
> 3. The Security Considerations has a new paragraph on TAGLEN.
> 
>  > Normally, a given key should be used to create ciphertexts with a
>  > single tag length, TAGLEN, and an application should reject any
>  > ciphertext that claims authenticity under the same key but a
>  > different tag length.  While the ciphertext core and all of the bits
>  > of the tag do depend on the tag length, this is done for added
>  > robustness to misuse and should not suggest that receivers accept
>  > ciphertexts employing variable tag lengths under a single key.

it is a sound approach to forbid the use of a single key with different
tag lengths, but the requirements language should be firmed up.  This
section should say something like "For each particular key, the value of
TAGLEN MUST be fixed."  

David

> 
> 
> 4. A new paragraph is added to the introduction making it clear that byte-oriented implementations are okay. This is in response to an implementor who was worried about his byte-oriented implementation being out of compliance with the spec.
> 
>  > For reasons of generality, OCB is defined to operate on arbitrary
>  > bit-strings.  But for reasons of simplicity and efficiency, most
>  > implementations will assume that strings operated on are byte-strings
>  > (ie, strings that are a multiple of 8 bits).  To promote
>  > interoperability, implementations of OCB that communicate with
>  > implementations of unknown capabilities should restrict all provided
>  > values (nonces, tags, plaintexts, ciphertexts, and associated data)
>  > to byte-strings.
> 
> Thank you everybody for your help in refining OCB. Phil and I really appreciate it.
> 
> -Ted
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg