Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Ben Laurie <benl@google.com> Wed, 21 November 2012 15:47 UTC

Return-Path: <benl@google.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 7EE2E21F873E for <cfrg@ietfa.amsl.com>; Wed, 21 Nov 2012 07:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 83f5EQKfBp36 for <cfrg@ietfa.amsl.com>; Wed, 21 Nov 2012 07:47:19 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3A67D21F8738 for <cfrg@irtf.org>; Wed, 21 Nov 2012 07:47:19 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id 12so3408922wgr.19 for <cfrg@irtf.org>; Wed, 21 Nov 2012 07:47:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bd2xQB13ZNaf9l3xJ7B2tAHolfn8Ebuqb/13sVNDvMc=; b=aiNv+ImEuNJZMmWTYMlAt2C+Vwh+ogdsaCqx5FY8FIWItyzTYwF5/QLRSOScwp1ceC xGEHhpPxAjDoWKRGBLoU3aNE+vEdneiL0vy/lyjb7kQcKUPkNYsXX8PXMmqprHD7f9n8 2p6qHaHq6Ogi71aVPY47cK1AnezrAFU5UKCVFoLGbGUJXciHQt0aWbU9xpqzbN5dwAUo WAZray0eomAh+nShMrIRkDzxMKnyjbn6KcpyIgnTUQ7RR8atZy/RPZlf8kWftM9PoGg2 DWQQzMkkl1V9a2uo/krqNBwQC+0w1JuRzQ71iMpGDQmicAbQRjzWpGTdYDvo8tEulv8N u90w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Bd2xQB13ZNaf9l3xJ7B2tAHolfn8Ebuqb/13sVNDvMc=; b=j+1RzrTDTYvqIRgMlo/UyQbORavntIQBV3+UOYAXzm8uiInQtCP+tggzrKl2596H0C ePsFhkFy8J+W1cIOPmJm541OITIJajTHwe+l/MFtKdrz3Rb+7zb8DSFuwRtaPqZJz5LI NG6FWtVS2x746jL42qcNNqNC1H402xJ0cUB75uRKlMzjossmbrmfZHsRHo0v734U/RVK Tc5nOs0aaKkT1b3NuqroDYXtvfTNiitzsIdaNkZPAC+MU5rWlSxZyKjeXCDztOfG/8xI apkwn6vFBMBv5CC32LHLzywCl0ehQeGlmknUWVmiETR7LUM2Qd2ufl6vdHnkMR9zeF5/ c4Tg==
MIME-Version: 1.0
Received: by 10.180.101.3 with SMTP id fc3mr3659007wib.16.1353512838263; Wed, 21 Nov 2012 07:47:18 -0800 (PST)
Received: by 10.194.56.138 with HTTP; Wed, 21 Nov 2012 07:47:18 -0800 (PST)
In-Reply-To: <BAY171-W133C34B6212813A7B59F439B76D0@phx.gbl>
References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <BAY171-W133C34B6212813A7B59F439B76D0@phx.gbl>
Date: Wed, 21 Nov 2012 15:47:18 +0000
Message-ID: <CABrd9SSEcTVHN6w6i5AvUAbvewgPPuoV=YkDL1CWEd+fd6rqfQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkYQwF9AAbgJ8jj7hluaUvLs2ro8zM/qm/WRkwQHc1kuBlTgCL/lmHQ/b3rXBCIbI5KmOEMJatbEdJfb52BnhUoApmt2+zob6nNSJ31v14rsTHvZ0QHAy3fAbVAA+DTvEcO/SZmzEwoyYAf9/3uZ1UG9G5oydZAgh0gC9N3H7s3wjK4UK50PTGPihBvUxAHPux6wGJ7
Cc: mcgrew@cisco.com, cfrg@irtf.org, jose@ietf.org
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
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: Wed, 21 Nov 2012 15:47:20 -0000

On 12 November 2012 20:25, Michael Jones <michael_b_jones@hotmail.com> wrote:
>
> OK, I admit that the way I phrased my request may not be exactly in line
> with the way the “AEAD” terminology is used.  I can correct that. That’s
> syntax.  I was using “AEAD” as a shorthand for the working group’s decision
> to use only authenticated encryption algorithms – not to mean the particular
> combined representation of those parameters apparently specified in the AEAD
> draft.  I will correct the terminology usage in the next revision of the
> JOSE specifications.
>
>
> The semantic point remains that it’s cleaner and more flexible to have the
> Key, the Plaintext, IV, and “additional authenticated data” parameters all
> be separate inputs and the Ciphertext and “authentication tag” all be
> separate outputs.  In JOSE’s particular use case, that would be a
> significantly better match and easier for implementers to use.

Sorry for the drive-by comment, but this caught my eye...

The problem with this idea, though, is that authenticated encryption
does not require an "authentication tag" in general - it just requires
that decrypting a tampered or entirely invented ciphertext fails. So,
this seems like a short-sighted way to define it.

>
>
> JOSE already has a way of combining the inputs and outputs that’s inherent
> to its representation, and it doesn’t match the one you’ve specified.  GCM,
> CTR, and the current JOSE-specified algorithms are a great fit for this, as
> they can directly use that representation.  The AEAD pattern you cite
> requires disassembly of the components of the AEAD-specific representation
> to be able to use the combinations already present in the JOSE
> representations and then reassembly at decryption time.  That’s just more
> work for implementers, and it’s not semantically necessary work.
>
>
> Are you open to specifying versions of your algorithms that don’t require a
> particular combination method for the parameters, but instead leave the
> combination up to the use case?  I’m fine with you also specifying a
> specific combination method as an optional feature of the specification.
> But it shouldn’t be part of the algorithm definition, just like it isn’t for
> GCM.
>
>
>                                                             Best wishes,
>
>                                                             -- Mike
>
>
>
> From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com]
> Sent: Monday, November 12, 2012 11:43 AM
> To: Mike Jones; cfrg@irtf.org; jose@ietf.org
> Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
> version 01
>
>
> Hi Mike,
>
>
> From: Mike Jones <Michael.Jones@microsoft.com>
> Date: Monday, November 12, 2012 1:55 PM
> To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>,
> "jose@ietf.org" <jose@ietf.org>
> Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
> version 01
>
>
> As background, if there was a version of this spec that did not assume that
> the parameters would be concatenated together in a specific way, but left
> them as independent inputs and outputs, as AES GCM and AES CTR do, it would
> be a better match for JOSE’s use case.
>
>
>
> I believe that what you are referring to is the inclusion of the
> authentication tag in the authenticated ciphertext.   This is not just a
> property of draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19
> of the AEAD algorithms that have been defined so far.   For comparison,
> draft-mcgrew-aead-aes-cbc-hmac-sha2 says
>
>
>        The AEAD Ciphertext consists of the string S, with the string T
>
>        appended to it.  This Ciphertext is returned as the output of the
>
>        AEAD encryption operation.
>
>
>
> Where S is the ciphertext and T is the authentication tag.   RFC 5116 says
>
>
>                                      "The AEAD_AES_128_GCM ciphertext is
> formed by
>
>    appending the authentication tag provided as an output to the GCM
>
>    encryption operation to the ciphertext that is output by that
>
>    operation."
>
>
> David
>
>
>                                                             -- Mike
>
>
> ________________________________
> From: mcgrew@cisco.com
> To: cfrg@irtf.org; jose@ietf.org
> Date: Mon, 12 Nov 2012 18:20:57 +0000
> CC: Kenny.Paterson@rhul.ac.uk
> Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version
> 01
>
>
> Hi,
> There is a new version of "Authenticated Encryption with AES-CBC and
> HMAC-SHA", and I would appreciate your review.   It is online at
> <https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1>
> The diff between the current and the previous version is available at
> <http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01>
> This draft has been proposed for use in the JOSE WG
> <http://datatracker.ietf.org/wg/jose/> , where its adoption would allow the
> working group to omit "raw" unauthenticated encryption, e.g. AES-CBC, and
> only include authenticated encryption.   Thus I am asking for your help in
> making
> John Foley generated test cases that correspond to the current version of
> the draft, but I didn't include these in the draft because I did not yet get
> confirmation from a second independent implementation.   With hope, there
> will not be any need for any normative changes, and I will include these
> after I get confirmation.
> Thanks,
> David
>
> _______________________________________________ jose mailing list
> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>