[jose] CAESAR crypto competition’s model of an AEAD algorithm

"Manger, James H" <James.H.Manger@team.telstra.com> Tue, 16 July 2013 04:29 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52C111E810A for <jose@ietfa.amsl.com>; Mon, 15 Jul 2013 21:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.646
X-Spam-Level:
X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_203=0.994, SARE_SUB_ENC_UTF8=0.152, SUBJECT_FUZZY_TION=0.156]
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 tF2oz+n+Rz9P for <jose@ietfa.amsl.com>; Mon, 15 Jul 2013 21:29:47 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0C39611E81F0 for <jose@ietf.org>; Mon, 15 Jul 2013 21:29:46 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,674,1367935200"; d="scan'208,217"; a="147762331"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 16 Jul 2013 14:29:43 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7137"; a="145163427"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbni.tcif.telstra.com.au with ESMTP; 16 Jul 2013 14:29:43 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 16 Jul 2013 14:29:42 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "jose@ietf.org" <jose@ietf.org>
Date: Tue, 16 Jul 2013 14:29:41 +1000
Thread-Topic: CAESAR crypto competition’s model of an AEAD algorithm
Thread-Index: Ac6B3RdKMS/YOHHlTwu9Uar0KmzU/w==
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C7C368F@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151C7C368FWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [jose] CAESAR crypto competition’s model of an AEAD algorithm
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 04:29:53 -0000

“CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) will identify a portfolio of authenticated ciphers that offer advantages over AES-GCM and that are suitable for widespread adoption.”
http://competitions.cr.yp.to/caesar-call-3.html

CAESAR should be of interest to JOSE for its *model* of AEAD algorithms. Slotting any CAESAR algorithm into JOSE (eg mapping JOSE fields to crypto_aead_decrypt() arguments) should be trivial once a “alg” string is picked. CAESAR says an AEAD algorithm has 5 inputs (plaintext, associated data, secret message number, public message number, and a key) and 1 output (ciphertext).

“Message number” is unusual terminology for a nonce, but reflect the fact that only part of the nonce might be in a message (ie only the public message number). This mainly corresponds to ‘iv’ in JOSE, which is sometime a dot-separated B64 segment, and sometimes a header parameter.

A more important clash between CAESAR and JOSE is JOSE’s ‘tag’ field that does not exist as a distinct item in the CAESAR model. [One more reason to fix issue #11 properly.]

P.S. While I’m talking about AEAD tags, the latest change to A128GCMKW moves the key wrap tag from outside the AAD to inside the AAD of the subsequent content encryption. Are they any implications for this change to the security properties?

--
James Manger