Re: [Cfrg] Attacker changing tag length in OCB

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Fri, 31 May 2013 00:58 UTC

Return-Path: <prvs=98631c50d8=uri@ll.mit.edu>
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 328C121F9371 for <cfrg@ietfa.amsl.com>; Thu, 30 May 2013 17:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.873
X-Spam-Level:
X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 BqYPDCON83mr for <cfrg@ietfa.amsl.com>; Thu, 30 May 2013 17:58:20 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id F30A721F96EB for <cfrg@ietf.org>; Thu, 30 May 2013 17:58:19 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r4V0wH9S013756; Thu, 30 May 2013 20:58:19 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'ted@krovetz.net'" <ted@krovetz.net>, "'cfrg@ietf.org'" <cfrg@ietf.org>
Date: Thu, 30 May 2013 20:43:26 -0400
Thread-Topic: [Cfrg] Attacker changing tag length in OCB
Thread-Index: Ac5dlYJG/vgkvXZYS1OaUQyix/CQXgAAlW6b
In-Reply-To: <F1616246-4F1E-4AA1-B2A5-39B5AB7B5DAF@krovetz.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-30_08:2013-05-30, 2013-05-30, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305300254
Message-Id: <20130531005819.F30A721F96EB@ietfa.amsl.com>
Subject: Re: [Cfrg] Attacker changing tag length in OCB
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, 31 May 2013 00:58:24 -0000

Test-vectors - that's nothing.

Algorithm stability - yes, that's a good argument. Under this condition I probably wouldn't change mine, so can't insist that you change yours. 

TNX!
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <uri@ll.mit.edu>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

 

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Ted Krovetz [mailto:ted@krovetz.net]
Sent: Thursday, May 30, 2013 08:15 PM
To: cfrg@ietf.org <cfrg@ietf.org>
Subject: Re: [Cfrg] Attacker changing tag length in OCB


> There's no reason not to introduce an extra bit of (maybe unnecessary?) protection

There are some costs.

- Redo test vectors. All the test vectors would have to be regenerated. This is not hard, but some confidence has been built up about the current vectors by several implementors, and the confidence building would need to start over.

- Change of algorithm. The OCB algorithm has been stable for some time, and OCB is already being used in some products. Any changes to the algorithm would be problematic for these early adopters.

Without these costs I would not hesitate to agree to the change, but with them I'm inclined to keep things as they are.
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg