From mcgrew@cisco.com Thu Nov 8 07:35:53 2012 Return-Path: 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 CA71A21F845A for ; Thu, 8 Nov 2012 07:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 OnMXiIsOZ0RI for ; Thu, 8 Nov 2012 07:35:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D48D621F8458 for ; Thu, 8 Nov 2012 07:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1004; q=dns/txt; s=iport; t=1352388953; x=1353598553; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FAcLRG0JxSdDjOMii80ctfYqMc/C7SrQPwDzQFTVE5s=; b=TttbWaPl9+XQdjs/Be7q5TPvaQ62aBS4L0i39U99VMq3T/M+VGkD/FIw 5JWua0KYrwXDO6EdHkM1P50Ms2ax5lPTa8SuKKmiIMowvYxJbZU4TSt4n TnEWHB/77Qs2g9MgNRS5dm9g6UG/tE5hBlK/2izKtSFI031NYlz4dX7s/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMIABvQm1CtJXG//2dsb2JhbABEw2uBAQeCHgEBAQQBAQEPASc0HQEIIhQ3CxsBBgMCBBMIGodoC5pNgSugM5F4YQOXF408gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="140179079" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 08 Nov 2012 15:35:52 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8FZqXA029959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Nov 2012 15:35:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 09:35:52 -0600 From: "David McGrew (mcgrew)" To: "cfrg@irtf.org" Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" Thread-Index: AQHNvca7/MOdrFKel0OB6840UXiC1A== Date: Thu, 8 Nov 2012 15:35:51 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F5097FA@xmb-rcd-x04.cisco.com> In-Reply-To: <9B93EFAD-AD9B-4402-8CC2-79239EB3DF2E@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.150.68.103] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--31.351100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1DF86DD9FD74EC4C8EA477551E68B2D5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Cfrg] FW: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:35:53 -0000 On 11/8/12 7:29 AM, "Paul Hoffman" wrote: >Greetings again. Bruce Schneier and I have started an update to RFC 4270, >"Attacks on Cryptographic Hashes in Internet Protocols". This revision is >meant to deal with new and more devastating attacks on MD5, the fact that >SHA-1 collisions will be financially feasible in the foreseeable future, >and NIST's upcoming SHA-3 announcements. We expect to keep this revision >process open for at least five months because NIST probably won't >finalize the parameters and naming and so on for KECCAK until then; that >is, we won't send this to RFC Editor until SHA-3 is finalized. Please >take a look at=20 > >http://tools.ietf.org/html/draft-hoffman-schneier-4270bis > >Sean and Stephen have agreed that we should use the SAAG mailing list for >discussing this draft. > >--Paul Hoffman >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From mcgrew@cisco.com Mon Nov 12 10:20:59 2012 Return-Path: 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 A78B521F8609 for ; Mon, 12 Nov 2012 10:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 zYehuN4G3MDU for ; Mon, 12 Nov 2012 10:20:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9FD21F859E for ; Mon, 12 Nov 2012 10:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4396; q=dns/txt; s=iport; t=1352744459; x=1353954059; h=from:to:cc:subject:date:message-id:mime-version; bh=4X7UHtJe3TJVIAY1M3sG63OuFd+Me+j/hqUClsItXCM=; b=jtQc9vsVWMyjJZAGdY+QD3FH2oeIGSdBXRj6N/5wmcRD6CwV1/bLdkSa GQbRWW58hgSZWV4/vjIBjVZiq4yGcISpvZz4Ec5dqdCo6FVGvG6NvCtx7 kdQG1xg3LTNaBYRmnNgBAOcWfK+lZqrPvkJVKLkqFc4LzK8k+0PDJueAJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAJs9oVCtJV2Z/2dsb2JhbABEgkmvHIkFAYhvgQiCIAEEEgFmEgEMHlYnBAENDQEZh2gLmWWffJF+YQOXGI08gWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141162395" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2012 18:20:58 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qACIKwqX022002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 18:20:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 12:20:57 -0600 From: "David McGrew (mcgrew)" To: "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwQ== Date: Mon, 12 Nov 2012 18:20:57 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--30.318000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:20:59 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at = The diff between the current and the previous version is available at This draft has been proposed for use in the JOSE WG , where its adoption would allow the working group to omit = "raw" unauthenticated encryption, e.g. AES-CBC, and only include authentica= ted encryption. Thus I am asking for your help in making John Foley generated test cases that correspond to the current version of t= he 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 af= ter I get confirmation. Thanks, David --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
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 &= lt;https://datatracker.ietf.org/doc/draft-mcgre= w-aead-aes-cbc-hmac-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-a= es-cbc-hmac-sha2-01>


John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation.   With hope, t= here will not be any need for any normative changes, and I will include these after I get confirmation.  

Thanks,

David
--_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_-- From mcgrew@cisco.com Mon Nov 12 11:42:39 2012 Return-Path: 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 6820421F875C for ; Mon, 12 Nov 2012 11:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 f8XnRrUb6-ab for ; Mon, 12 Nov 2012 11:42:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 168C021F8748 for ; Mon, 12 Nov 2012 11:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14309; q=dns/txt; s=iport; t=1352749358; x=1353958958; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ufHUlhNVBUCu4Iq/mwoHq+dzKkXjb4UwLuBIU06fEwA=; b=c5mTZ9uhhrVnbxxCirEoSoR4I6BkaqzqJBHO4LWS95pfmeuwmHk5npTB duyu7gJwHorvkaGe+zqvEAUuDOnbIn3SgyoBS9I7qRdd0NVWRq+HOmfix QC45Qxl1LXfvksEdkJhDjx1ZqYNTBhS6oGPDZToO079UvbTX2xI2Gorxu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFAD1QoVCtJXG+/2dsb2JhbABEgkmvHIkFAYhvgQiCHgEBAQQSARpeAQgOAwMBAQELHTkUCQgCBAESCAEZh2gLmVWgA4wVhWlhA5cYjTyBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="138404565" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2012 19:42:37 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACJgbCu017622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 19:42:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:42:36 -0600 From: "David McGrew (mcgrew)" To: Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQ3d4t8orcyRa0OnKgA6UvxDXw== Date: Mon, 12 Nov 2012 19:42:36 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--38.562600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:42:39 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, From: Mike Jones > Date: Monday, November 12, 2012 1:55 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 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=92s use case. I believe that what you are referring to is the inclusion of the authentica= tion 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-ae= ad-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 fo= rmed 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: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mike,

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Monday, November 12, 2012 1:5= 5 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [Cfrg] Authenticated E= ncryption with AES-CBC and HMAC-SHA, version 01

As background, if there was a vers= ion of this spec that did not assume that the parameters would be concatena= ted 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=92s use case.


I believe that what you are referring to is the inclusion of the authe= ntication tag in the authenticated ciphertext.   This is not just a pr= operty 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 sa= ys 

       The AEAD Ciphertext consists of the string = S, with the string T
       appended to it.  This Ciphertext is re= turned as the output of the
       AEAD encryption operation.

Where S is the ciphertext and T is the authentication tag.   = ;RFC 5116 says

                    =                  "The AEA= D_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

 

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] 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 https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hma= c-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been proposed for use in the= JOSE WG <http://dat= atracker.ietf.org/wg/jose/> , where its adoption would allow the working group to omit "raw" unauthentic= ated encryption, e.g. AES-CBC, and only include authenticated encryption. &= nbsp; Thus I am asking for your help in making 

 

John Foley generated test cases that corres= pond 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 ge= t confirmation.  

 

Thanks,

 

David

 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_-- From dharkins@lounge.org Mon Nov 12 12:21:14 2012 Return-Path: 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 D992C21F8681 for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 zKtEn-oftuco for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5359621F862C for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0F22B1022400A; Mon, 12 Nov 2012 12:21:13 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 12:21:13 -0800 (PST) Message-ID: <3bfc8545d5829d56d26ceafba6d8d1f3.squirrel@www.trepanning.net> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> Date: Mon, 12 Nov 2012 12:21:13 -0800 (PST) From: "Dan Harkins" To: "David McGrew (mcgrew)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:21:15 -0000 Hi Mike, > From: Mike Jones > > > Date: Monday, November 12, 2012 1:55 PM > To: Cisco Employee >, > "cfrg@irtf.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 encourage you to look into SIV mode, an AEAD scheme found in RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper found in the RFC) and is provably secure. It takes a vector of input as additional authenticated data which will be authenticated, and a plaintext which will be authenticated and encrypted. It does not assume that the parameters are concatenated together, it's just a vector of separate inputs. Additionally, SIV mode does not require a random IV/nonce. It works just fine if you have one, and it won't collapse if it is repeated (as GCM does) or is predictable (as CBC-HMAC does), and it works if you don't have, or want to have, one. In that fashion it is more robust than other AEAD schemes. The downside is that it's slower than GCM but is probably faster than CBC-HMAC with SHA2. regards, Dan. From michael_b_jones@hotmail.com Mon Nov 12 12:25:06 2012 Return-Path: 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 A658A21F8536 for ; Mon, 12 Nov 2012 12:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RUBjxBmzrQY9 for ; Mon, 12 Nov 2012 12:25:05 -0800 (PST) Received: from bay0-omc1-s2.bay0.hotmail.com (bay0-omc1-s2.bay0.hotmail.com [65.54.190.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAC521F84BA for ; Mon, 12 Nov 2012 12:25:05 -0800 (PST) Received: from BAY171-W133 ([65.54.190.60]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 12:25:04 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e8f7860d-ce2d-4929-9424-1c73cd8e9749_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , , Date: Mon, 12 Nov 2012 12:25:04 -0800 Importance: Normal In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 20:25:04.0774 (UTC) FILETIME=[CCC6EA60:01CDC113] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:25:06 -0000 --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK=2C I admit that the way I phrased my request may not be exactly in line with the way the =93AEAD=94 terminology is used.=20 I can correct that. That=92s syntax.=20 I was using =93AEAD=94 as a shorthand for the working group=92s decision to use only authenticated encryption algorithms =96 not to mean the particular combined representation of those parameters apparently specified in the AEA= D draft. I will correct the terminology usage in the next revision of the JOSE specifications. The semantic point remains that it=92s cleaner and more flexible to have the Key=2C the Plaintext=2C IV=2C and =93additional authenticated data=94 p= arameters all be separate inputs and the Ciphertext and =93authentication tag=94 all be s= eparate outputs. In JOSE=92s particular use case=2C that would be a significantly better match and easier for implementers to u= se. JOSE already has a way of combining the inputs and outputs that=92s inherent to its representation=2C and it doesn=92t match the one you=92ve specified. GCM=2C CTR=2C and the current JOSE-specified algorithms are a great fit for this=2C 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 JO= SE representations and then reassembly at decryption time. That=92s just more= work for implementers=2C and it=92s not semantically necessary work. Are you open to specifying versions of your algorithms that don=92t require a particular combination method for the parameters=2C but instead leave the= combination up to the use case? I=92m fine with you also specifying a specific combination method as an optional feature of the specification. But it shouldn=92t be part of the algorithm definition=2C just like it isn=92t for GCM. Best wishes=2C -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com]=20 Sent: Monday=2C November 12=2C 2012 11:43 AM To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01 Hi Mike=2C From: Mike Jones Date: Monday=2C November 12=2C 2012 1:55 PM To: Cisco Employee =2C "cfrg@irtf.org" =2C "jose@ietf.org" Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01 As background=2C if there was a version of this spec that did not assume that the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AES GCM and AE= S CTR do=2C it would be a better match for JOSE=92s 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=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far. For comparison=2C draft-mcgrew-aead-aes-cbc-hmac-sha2 says=20 =20 The AEAD Ciphertext consists of the string S=2C with the string T =20 appended to it. This Ciphertext is returned as the output of the =20 AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says =20 =20 "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=20 operation." David =20 -- Mike From: mcgrew@cisco.com To: cfrg@irtf.org=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01 Hi=2C There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA"=2C and I would appreciate your review. It is online at = =20 The diff between the current and the previous version is available at This draft has been proposed for use in the JOSE WG =2C where its adoption would allow the working group to omi= t "raw" unauthenticated encryption=2C e.g. AES-CBC=2C and only include authenticated encryption. Thus I am asking for your help in maki= ng=20 John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation. With hope=2C th= ere will not be any need for any normative changes=2C and I will include these after I get confirmation. =20 Thanks=2C David _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

OK=2C I admit that the w= ay I phrased my request may not be exactly in line with the way the =93AEAD=94 terminology is used. =3B I can correct that. That=92s syntax. =3B I was using =93AEAD=94 as a shorthand for the working group=92s deci= sion to use only authenticated encryption algorithms =96 not to mean the particular combined representation of those parameters apparently specified in the AEA= D draft. =3B I will correct t= he terminology usage in the next revision of the JOSE specifications.


The semantic point remai= ns that it=92s cleaner and more flexible to have the Key=2C the Plaintext=2C IV=2C and =93additional authenticated data=94 p= arameters all be separate inputs and the Ciphertext and =93authentication tag=94 all be s= eparate outputs. =3B In JOSE=92s pa= rticular use case=2C that would be a significantly better match and easier for implementers to u= se.


JOSE already has a way o= f combining the inputs and outputs that=92s inherent to its representation=2C and it doesn=92t match the one you=92ve specified. =3B GCM=2C CTR= =2C and the current JOSE-specified algorithms are a great fit for this=2C as they can directly = use that representation. =3B Th= e 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 JO= SE representations and then reassembly at decryption time. =3B That=92s just more work for implementers= =2C and it=92s not semantically necessary work.


Are you open to specifyi= ng versions of your algorithms that don=92t require a particular combination method for the parameters=2C but instead leave the= combination up to the use case? =3B I= =92m fine with you also specifying a specific combination method as an optional feature of the specification.  =3BBut it s= houldn=92t be part of the algorithm definition=2C just like it isn=92t for GCM.


 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B Best wishes=2C

 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B -- Mike



From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com= ]
Sent: Monday=2C November 12=2C 2012 11:43 AM
To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


Hi Mike=2C<= /p>

From: Mike Jones <=3BMichael.J= ones@microsoft.com>=3B
Date: Monday=2C November 12=2C 2012 1:55 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "cfrg@irtf.org" <=3Bcfr= g@irtf.org>=3B=2C "jose@ietf.org" <=3Bjose@ietf.org>=3B
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


As background=2C if there was a version of this spe= c that did not assume that the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AES GCM and AE= S CTR do=2C it would be a better match for JOSE=92s use case.

I believ= e that what you are referring to is the inclusion of the authentication tag in the authenticated ciphertext.  =3B This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far.  =3B For comparison=2C =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2 says =3B<= /o:p>


 =3B  =3B =  =3B  =3BThe AEAD Ciphertext consists of the string S=2C with the string T

 =3B  =3B &n= bsp=3B  =3Bappended to it.  =3BThis Ciphertext is returned as the output o= f the

 =3B &nbs= p=3B  =3B  =3BAEAD encryption operation.

 =3B

Where S is the ciphertext and T is the authentication tag.  =3B =3BRFC 5116 says


 =3B  =3B =  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B"The AEAD_AES_128_GCM ciphertex= t is formed by

 =3B =  =3Bappending the authentication tag provided as an output to the GCM

 =3B  =3Bencryption operation to the ciphertext that is output by that

 =3B  =3Boperation."


David


 =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B -- Mike


From: mcgrew@cisco.com
To: cfrg@irtf.org=3B jose@ietf.org
Date: Mo= n=2C 12 Nov 2012 18:20:57 +0000
CC: Kenny.Paterson@rhul.ac.uk
Subject= : [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01
Hi=2C
There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA"=2C a= nd =3BI would appreciate your review.  =3B It is online at &= lt=3Bhttps://datatracker.ietf.= org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=3D1>=3B&nbs= p=3B  =3BThe diff between the current and the previous version is available= at <=3Bhttp://www.ietf.org/rfcdiff?url2= =3Ddraft-mcgrew-aead-aes-cbc-hmac-sha2-01>=3B
This draft has been proposed for use in the JOSE WG <=3Bhttp://datatracker.iet= f.org/wg/jose/>=3B =3B=2C where its adoption would allow the work= ing group to omit "raw" unauthenticated encryption=2C e.g. AES-CBC=2C and o= nly include authenticated encryption.  =3B Thus I am asking for your help = in making =3B
John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation.  =3B With hop= e=2C there will not be any need for any normative changes=2C and I will include these after I get confirmation.  =3B
Thanks=2C
David

_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_-- From mcgrew@cisco.com Mon Nov 12 15:19:52 2012 Return-Path: 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 C61D221F8614 for ; Mon, 12 Nov 2012 15:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 cm8Mxvz9KKmc for ; Mon, 12 Nov 2012 15:19:51 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0D21F84D4 for ; Mon, 12 Nov 2012 15:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35742; q=dns/txt; s=iport; t=1352762391; x=1353971991; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0K7E90smBCTodgctihD4gQHc+cggu6Vd04ItE62eki8=; b=hYU8nuTiy5vHcMhhz8GdbhSw1gFUl7RtJWqLgIPV0N04fzFBDgEkJK1J bxi4RIx0EWNrrwqAn3P4ekswxtvq43yAKhLdtS6g23BMHQlmqJhfE3HQn dzZbpZjkxHlCRpUWV2ThTQtbYmB/ZYMzvW9i66MolWAmHXWr9y/4ACk7B g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAGeCoVCtJXG+/2dsb2JhbABEgkmuajOJBQGId4EIgh4BAQEEAQEBDwEaQQsSAQgRAwEBAQsWAQYuCxQJCAIEAQ0FCAESB4dWAw8LmXqgDIssaYNugXthA5QognCKFoMmgWuCYg2CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141473985" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2012 23:19:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACNJnrx010934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 23:19:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 17:19:49 -0600 From: "David McGrew (mcgrew)" To: Michael Jones , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgA= Date: Mon, 12 Nov 2012 23:19:48 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--30.170200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:19:52 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Michael Jones > Date: Monday, November 12, 2012 3:25 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 OK, I admit that the way I phrased my request may not be exactly in line wi= th the way the =93AEAD=94 terminology is used. I can correct that. That=92= s syntax. I was using =93AEAD=94 as a shorthand for the working group=92s = decision to use only authenticated encryption algorithms =96 not to mean th= e particular combined representation of those parameters apparently specifi= ed in the AEAD draft. I will correct the terminology usage in the next rev= ision of the JOSE specifications. The semantic point remains that it=92s cleaner and more flexible to have th= e Key, the Plaintext, IV, and =93additional authenticated data=94 parameter= s all be separate inputs and the Ciphertext and =93authentication tag=94 al= l be separate outputs. In JOSE=92s particular use case, that would be a sig= nificantly better match and easier for implementers to use. JOSE already has a way of combining the inputs and outputs that=92s inheren= t to its representation, and it doesn=92t match the one you=92ve specified.= GCM, CTR, and the current JOSE-specified algorithms are a great fit for t= his, as they can directly use that representation. The AEAD pattern you ci= te requires disassembly of the components of the AEAD-specific representati= on to be able to use the combinations already present in the JOSE represent= ations and then reassembly at decryption time. That=92s just more work for= implementers, and it=92s not semantically necessary work. One could just as easily argue that the unnecessary work comes from the fac= t that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorith= ms, which do not use the RFC 5116 interface. The draft confusingly refere= nces that RFC after it defines AEAD, but then does something different. I= f the plan is really going to be for the JOSE WG to define its own AEAD alg= orithms that are incompatible (which I hope is not the case), the differenc= es and motivation deserve to be documented. The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface. These are still valid motivations, though at th= is point the most important reason to use the interface is to avoid gratuit= ous incompatibility. Other protocols have not had any trouble in using the= 5116 interface; See RFC 5288 (TLSv1.2) Section 6.2.3.3, RFC 5647 (SSH GCM)= , or draft-ietf-avtcore-srtp-aes-gcm, for instance. Are you open to specifying versions of your algorithms that don=92t require= a particular combination method for the parameters, but instead leave the = combination up to the use case? I=92m fine with you also specifying a spec= ific combination method as an optional feature of the specification. But i= t shouldn=92t be part of the algorithm definition, just like it isn=92t for= GCM. I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs, as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header, a period ('.') character, the Encoded JWE Encrypted Key, a second period character ('.'), and the Encoded JWE Initialization Vector, per Section 5 of the JWE specification. The plaintext , which contains the data to be encrypted and authenticated. A nonce N, with a length of either 0 or 96 bits. If the length is zero, the nonce is omitted. Otherwise, the nonce is as described in Section 3 of RFC 5116. There is a single output, the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. If we want to make actual progress on crypto interfaces, the thing that wou= ld be worth doing is defining a simpler interface that moves the nonce deta= ils into the ciphertext (and thus away from the user). Moving the authent= ication data out of the ciphertext would be movement in the wrong direction= , in my opinion. David 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, ver= sion 01 Hi Mike, From: Mike Jones > Date: Monday, November 12, 2012 1:55 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 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=92s use case. I believe that what you are referring to is the inclusion of the authentica= tion 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-ae= ad-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 fo= rmed 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-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David _______________________________________________ jose mailing list jose@ietf= .org https://www.ietf.org/mailman/listinfo/jose --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7261A6CFF5A1E0429F29B0D910A05A09@cisco.com> Content-Transfer-Encoding: quoted-printable


From: Michael Jones <michael_b_jones@hotmail.com>
Date: Monday, November 12, 2012 3:2= 5 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [jose] Authenticated E= ncryption with AES-CBC and HMAC-SHA, version 01


OK,= I admit that the way I phrased my request may not be exactly in line with = the way the =93AEAD=94 terminology is used.  I can correct that. That=92s syntax.  I was using =93AEAD=94 as a shorthand for the working group=92s decision to= use only authenticated encryption algorithms =96 not to mean the particula= r combined representation of those parameters apparently specified in the A= EAD draft.  I will correct the terminology usage in the next revision of the JOS= E specifications.


The= semantic point remains that it=92s cleaner and more flexible to have the K= ey, the Plaintext, IV, and =93additional authenticated data=94 parameters all be separate inputs and the Ciphertext and =93authen= tication tag=94 all be separate outputs.=  In JOSE=92s particular use case, that would be a significantly= better match and easier for implementers to use.



JOS= E already has a way of combining the inputs and outputs that=92s inherent t= o its representation, and it doesn=92t match the one you=92ve specified.  GCM, CTR, and the current JOSE-specified algorithms are a great fit for t= his, 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=92s just more work for implementers, and it=92s not semanticall= y necessary work.

One could just as easily argue that the unnecessary work comes from th= e fact that draft-ietf-jose-json-web-algorithms-07 defines its own AEA= D algorithms, which do not use the RFC 5116 interface.   The draft con= fusingly references that RFC after it defines AEAD, but then does something different.   If the plan is really going to b= e for the JOSE WG to define its own AEAD algorithms that are incompatible (= which I hope is not the case), the differences and motivation deserve to be= documented.  

The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface.   These are still valid motivations, though = at this point the most important reason to use the interface is to avoid gratuitous incompatibility.  Other p= rotocols have not had any trouble in using the 5116 interface; See RFC 5288= (TLSv1.2) Section 6.2.3.3, RFC 5647 (SSH GCM), or draft-ietf-avtcore-= srtp-aes-gcm, for instance.  


Are= you open to specifying versions of your algorithms that don=92t require a = particular combination method for the parameters, but instead leave the combination up to the use case?  I=92m fine with you also specifying a specific combination method as= an optional feature of the specification.  But it shouldn=92t be part = of the algorithm definition, just like it isn=92t for GCM.

I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this:

X.Y. Auth= enticated Encryption

  &n= bsp;This section defines the specifics of encrypting the JWE Plaintext
  &n= bsp;Using the Authenticated Encryption with Associated Data (AEAD)
  &n= bsp;as defined in RFC 5116.   The authenticated encryption operation 
   has four inputs, as follows:

     The secret key is the CMK.

     The associated data is the bytes of the ASCII= representation of the concatenation of
     the Encoded JWE Header, a period ('.') character, = the Encoded JWE
     Encrypted Key, a second period character ('.'), an= d the Encoded JWE
     Initialization Vector, per Section 5 of the JWE sp= ecification.
      The plaintext , which contains the data to be enc= rypted and
      authenticated.

      A nonce N, with a length of either 0 or 96 b= its.   If the length
  &n= bsp;   is zero, the nonce is omitted.  Otherwise, the nonce
  &n= bsp;   is as described in Section 3 of RFC 5116.   

   There is a single output, the Ciphertext.  

   The "enc" header  parameter v= alues are set as follows:

    "enc"           &n= bsp;      Algorithm            = ;             
  &n= bsp; ----------------------------------------------------------------------= -
    "A128GCM"     = ;AEAD_AES_128_GCM                 &= nbsp;                
    "A256GCM"     AEAD_AES_256_GCM &n= bsp;                     =             
     "A128CHS"      AEAD_AE= S_128_CBC_HMAC_SHA_256    
     "A256CHS&= quot;      AEAD_AES_256_CBC_HMAC_SHA_512  
      "A128SIV"      AEAD_AES_= SIV_CMAC_256
      "A256SIV"      AEAD_AES_= SIV_CMAC_384

  &n= bsp;  references corresponding to these symbolic names.=  

If we wan= t to make actual progress on crypto interfaces, the thing that would be wor= th doing is defining a simpler interface that moves the nonce details into = the ciphertext (and thus away from the user).   Moving the authentication data out of the ciphertext would b= e movement in the wrong direction, in my opinion.   

David


       &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  Best wishes,

       &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  -- Mike



From: David McGrew (mcg= rew) [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-S= HA, version 01


Hi Mike,


From: Mike Jones <Michael.Jones@microsoft.com&= gt;
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "jose@ietf.o= rg" <jose@ietf.org>
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01


As = background, if there was a version of this spec that did not assume that th= e 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=92s use case.

 

I believe th= at 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 featur= e of all 19 of the AEAD algorithms that have been defined so far.   Fo= r comparison, draft-mcgrew-aead-aes-cbc-hmac-sha2 says 


   = ;    The AEAD Ciphertext consists of the string S, with the strin= g T

   = ;    appended to it.  This Ciphertext is returned as the out= put of the

   = ;    AEAD encryption operation.

 

Where S is t= he ciphertext and T is the authentication tag.   RFC 5116 says


   = ;                     &nb= sp;            "The AEAD_AES_128_GCM cip= hertext 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


&nb= sp;            =             &nb= sp;            =             &nb= sp;         -- 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<= /a>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01

Hi,
This draft has been proposed for use in the JOSE WG <http://datatracker.ietf.= org/wg/jose/> , where its adoption would allow the working grou= p to omit "raw" unauthenticated encryption, e.g. AES-CBC, and only include authenticated encryption.   Thus I am askin= g for your help in making 
John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation.   With hope, t= here 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 ht= tps://www.ietf.org/mailman/listinfo/jose
 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_-- From mcgrew@cisco.com Mon Nov 12 15:39:36 2012 Return-Path: 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 7A2C321F877F for ; Mon, 12 Nov 2012 15:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hWmw8vK-XocO for ; Mon, 12 Nov 2012 15:39:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A9CD921F8696 for ; Mon, 12 Nov 2012 15:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2468; q=dns/txt; s=iport; t=1352763575; x=1353973175; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfhQMd/wi5U9Z3cUDSDgdUCOlZv597bwG8WrdKDjZ5k=; b=RShkj5zpEIguV6Gn6a3VlEY4f/bSR7ey/HTqWfU6xcB2wi25fyK+yNX7 kxBE/Oxg095o51+vnFj3NuFR9AVTMUjsqFFN0/x3fAvV8rejdJmTWRg1d PE2kxLsBBGkTLIi9BBnKpVJPYfUkF1Pt+k3sLqQVZWaGEzkMyEXrbeTzU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+HoVCtJV2c/2dsb2JhbABEw2OBCIIeAQEBAwESAQVhEgEIDgMDAQILHTkUCQgCBA4FCBqHYgaaBKANjBWDboF7YQOIJZwvgWuCYg2CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141455826" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2012 23:39:35 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qACNdY8V000976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 23:39:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 17:39:34 -0600 From: "David McGrew (mcgrew)" To: Dan Harkins Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwRNEN8doFmnIpEGgEt2l6seQrpfm7JkA Date: Mon, 12 Nov 2012 23:39:33 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> In-Reply-To: <3bfc8545d5829d56d26ceafba6d8d1f3.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--40.253500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:39:36 -0000 On 11/12/12 3:21 PM, "Dan Harkins" wrote: > > Hi Mike, > >> From: Mike Jones >> > >> Date: Monday, November 12, 2012 1:55 PM >> To: Cisco Employee >, >> "cfrg@irtf.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=B9s use case. > > I encourage you to look into SIV mode, an AEAD scheme found in >RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper >found in the RFC) and is provably secure. > > It takes a vector of input as additional authenticated data which will >be authenticated, and a plaintext which will be authenticated and >encrypted. It does not assume that the parameters are concatenated >together, it's just a vector of separate inputs. > > Additionally, SIV mode does not require a random IV/nonce. It works >just fine if you have one, and it won't collapse if it is repeated (as GCM >does) or is predictable (as CBC-HMAC does), and it works if you don't >have, or want to have, one. In that fashion it is more robust than other >AEAD schemes. The downside is that it's slower than GCM but is probably >faster than CBC-HMAC with SHA2. AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA. However, the motivation to use the latter algorithm is its widespread availability, as I understand it. Mike and some other folks did a survey of what crypto that is available. (Perhaps someone can send a reference, it is a good survey.) Despite SIV's flexibility, it doesn't address Mike's complaint, because it does not have an authentication tag that is separate from the ciphertext. Instead, it has the synthetic IV (which acts like an auth tag) combined with the ciphertext. As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface (see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so. =20 David > > regards, > > Dan. > > > From dharkins@lounge.org Mon Nov 12 16:06:45 2012 Return-Path: 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 B2F7921F875C for ; Mon, 12 Nov 2012 16:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 XdwXfALaraYA for ; Mon, 12 Nov 2012 16:06:45 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54421F8781 for ; Mon, 12 Nov 2012 16:06:45 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 42DAB1022400A; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Message-ID: <20a4747903e232548d778f1f1d171868.squirrel@www.trepanning.net> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> Date: Mon, 12 Nov 2012 16:06:44 -0800 (PST) From: "Dan Harkins" To: "David McGrew (mcgrew)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:06:45 -0000 Hi David, On Mon, November 12, 2012 3:39 pm, David McGrew (mcgrew) wrote: > > > On 11/12/12 3:21 PM, "Dan Harkins" wrote: > >> >> Hi Mike, >> >>> From: Mike Jones >>> > >>> Date: Monday, November 12, 2012 1:55 PM >>> To: Cisco Employee >, >>> "cfrg@irtf.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 encourage you to look into SIV mode, an AEAD scheme found in >>RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper >>found in the RFC) and is provably secure. >> >> It takes a vector of input as additional authenticated data which will >>be authenticated, and a plaintext which will be authenticated and >>encrypted. It does not assume that the parameters are concatenated >>together, it's just a vector of separate inputs. >> >> Additionally, SIV mode does not require a random IV/nonce. It works >>just fine if you have one, and it won't collapse if it is repeated (as >> GCM >>does) or is predictable (as CBC-HMAC does), and it works if you don't >>have, or want to have, one. In that fashion it is more robust than other >>AEAD schemes. The downside is that it's slower than GCM but is probably >>faster than CBC-HMAC with SHA2. > > AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA. > However, the motivation to use the latter algorithm is its widespread > availability, as I understand it. Mike and some other folks did a survey > of what crypto that is available. (Perhaps someone can send a reference, > it is a good survey.) Well, there is no widespread availability of AES-CBC-HMAC-SHA either. There may be availability of AES-CBC and HMAC-SHA separately but then there is, probably, availability of AES-CTR and AES-CMAC too and that is all SIV is, a provably secure construction of those two primitives. > Despite SIV's flexibility, it doesn't address Mike's complaint, because it > does not have an authentication tag that is separate from the ciphertext. > Instead, it has the synthetic IV (which acts like an auth tag) combined > with the ciphertext. Ahh, I missed that. But I think that is probably a trivial complaint of any 5116 AEAD scheme. It should be straightforward to extract the specific sub-string from the bitstring returned by any of the appropriate schemes if he wants to copy the IV/MAC/tag/whatever into a field that is separate from the encrypted plaintext. > As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface > (see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so. Good point! Regards, Dan. > David > >> >> regards, >> >> Dan. >> >> >> > > From michael_b_jones@hotmail.com Mon Nov 12 17:36:52 2012 Return-Path: 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 32A0C21F87E7 for ; Mon, 12 Nov 2012 17:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 A3PsHSHMlLlM for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from col0-omc4-s3.col0.hotmail.com (col0-omc4-s3.col0.hotmail.com [65.55.34.205]) by ietfa.amsl.com (Postfix) with ESMTP id 534C921F87AF for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from COL401-EAS436 ([65.55.34.199]) by col0-omc4-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 17:36:49 -0800 X-Originating-IP: [32.173.214.130] X-EIP: [RksFGqcBip46A6Ga1yMGpVuM3wAb7cN8] X-Originating-Email: [michael_b_jones@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c18d8d59-6f64-4747-8f62-240c572c3402_" MIME-Version: 1.0 From: Michael Jones Date: Mon, 12 Nov 2012 17:36:33 -0800 To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" X-OriginalArrivalTime: 13 Nov 2012 01:36:49.0811 (UTC) FILETIME=[59D90E30:01CDC13F] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:36:52 -0000 --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Believe me=2C if there were out of the box AEAD algorithm implementations a= vailable in most crypto libraries=2C I'd be eager to use them. As it is th= ough=2C all we can count on really being there are AES CBC and SHA-2. The J= WE algs are intended to be as easy to securely and interoperably implement = with those building blocks as possible. Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. That's my primary motivation in all of these (very useful) d= iscussions. I'm sure that's a goal we all share. Cheers=2C -- Mike Sent from my Windows Phone ________________________________ From: David McGrew (mcgrew) Sent: 11/12/2012 3:20 PM To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org Cc: Paterson=2C Kenny Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 From: Michael Jones > Date: Monday=2C November 12=2C 2012 3:25 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 OK=2C I admit that the way I phrased my request may not be exactly in line = with the way the =E2=80=9CAEAD=E2=80=9D terminology is used. I can correct= that. That=E2=80=99s syntax. I was using =E2=80=9CAEAD=E2=80=9D as a shor= thand for the working group=E2=80=99s decision to use only authenticated en= cryption algorithms =E2=80=93 not to mean the particular combined represent= ation of those parameters apparently specified in the AEAD draft. I will c= orrect the terminology usage in the next revision of the JOSE specification= s. The semantic point remains that it=E2=80=99s cleaner and more flexible to h= ave the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated= data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs. In JOSE=E2=80=99= s particular use case=2C that would be a significantly better match and eas= ier for implementers to use. JOSE already has a way of combining the inputs and outputs that=E2=80=99s i= nherent to its representation=2C and it doesn=E2=80=99t match the one you= =E2=80=99ve specified. GCM=2C CTR=2C and the current JOSE-specified algori= thms are a great fit for this=2C as they can directly use that representati= on. The AEAD pattern you cite requires disassembly of the components of th= e AEAD-specific representation to be able to use the combinations already p= resent in the JOSE representations and then reassembly at decryption time. = That=E2=80=99s just more work for implementers=2C and it=E2=80=99s not sem= antically necessary work. One could just as easily argue that the unnecessary work comes from the fac= t that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorith= ms=2C which do not use the RFC 5116 interface. The draft confusingly refe= rences that RFC after it defines AEAD=2C but then does something different.= If the plan is really going to be for the JOSE WG to define its own AEAD= algorithms that are incompatible (which I hope is not the case)=2C the dif= ferences and motivation deserve to be documented. The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface. These are still valid motivations=2C though at = this point the most important reason to use the interface is to avoid gratu= itous incompatibility. Other protocols have not had any trouble in using t= he 5116 interface=3B See RFC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SS= H GCM)=2C or draft-ietf-avtcore-srtp-aes-gcm=2C for instance. Are you open to specifying versions of your algorithms that don=E2=80=99t r= equire a particular combination method for the parameters=2C but instead le= ave the combination up to the use case? I=E2=80=99m fine with you also spe= cifying a specific combination method as an optional feature of the specifi= cation. But it shouldn=E2=80=99t be part of the algorithm definition=2C ju= st like it isn=E2=80=99t for GCM. I am not dogmatically opposed to other interfaces=2C but the best solution = here is for JOSE to actually use the 5116 interface=2C like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs=2C as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header=2C a period ('.') character=2C the Encoded JWE Encrypted Key=2C a second period character ('.')=2C and the Encoded JW= E Initialization Vector=2C per Section 5 of the JWE specification. The plaintext =2C which contains the data to be encrypted and authenticated. A nonce N=2C with a length of either 0 or 96 bits. If the length is zero=2C the nonce is omitted. Otherwise=2C the nonce is as described in Section 3 of RFC 5116. There is a single output=2C the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. If we want to make actual progress on crypto interfaces=2C the thing that w= ould be worth doing is defining a simpler interface that moves the nonce de= tails into the ciphertext (and thus away from the user). Moving the authe= ntication data out of the ciphertext would be movement in the wrong directi= on=2C in my opinion. David Best wishes=2C -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Monday=2C November 12=2C 2012 11:43 AM To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 Hi Mike=2C From: Mike Jones > Date: Monday=2C November 12=2C 2012 1:55 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 As background=2C if there was a version of this spec that did not assume th= at the parameters would be concatenated together in a specific way=2C but l= eft them as independent inputs and outputs=2C as AES GCM and AES CTR do=2C = it would be a better match for JOSE=E2=80=99s use case. I believe that what you are referring to is the inclusion of the authentica= tion tag in the authenticated ciphertext. This is not just a property of = draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far. For comparison=2C draft-mcgre= w-aead-aes-cbc-hmac-sha2 says The AEAD Ciphertext consists of the string S=2C 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 fo= rmed 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=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01 Hi=2C There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA"=2C and I would appreciate your review. It is online at <= https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu= de_text=3D1%3e> The diff between the current and the previous version is = available at This draft has been proposed for use in the JOSE WG =2C where its adop= tion would allow the working group to omit "raw" unauthenticated encryption= =2C e.g. AES-CBC=2C 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 t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation. With hope=2C th= ere will not be any need for any normative changes=2C and I will include th= ese after I get confirmation. Thanks=2C David _______________________________________________ jose mailing list jose@ietf= .org https://www.ietf.org/mailman/listinfo/jose --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Beli= eve me=2C if there were out of the box AEAD algorithm implementations avail= able in most crypto libraries=2C I'd be eager to use them. =3B As it is= though=2C all we can count on really being there are AES CBC and SHA-2. The JWE algs are intended to be as easy to securely and= interoperably implement with those building blocks as possible.

Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. =3B That's my primary motivation in all of these (very us= eful) discussions. =3B I'm sure that's a goal we all share.

Cheers=2C
-- Mike

Sent from my Windows Phone
From: David McGrew (mcgrew)
Sent: 11/12/2012 3:20 PM
To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org
Cc: Paterson=2C Kenny
Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01



From: Michael Jones <=3Bmichael_b_jones@hotmail.com>= =3B
Date: Monday=2C November 12=2C 2012= 3:25 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"=3B <=3Bcfrg@irtf.org>=3B=2C "=3Bjose@ietf.org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [jose] Authenticated E= ncryption with AES-CBC and HMAC-SHA=2C version 01


O= K=2C I admit that the way I phrased my request may not be exactly in line w= ith the way the =E2=80=9CAEAD=E2=80=9D terminology is used. =3B I can correct that. That=E2=80=99s syntax. =3B = I was using =E2=80=9CAEAD=E2=80=9D as a shorthand for the working gr= oup=E2=80=99s decision to use only authenticated encryption algorithms =E2= =80=93 not to mean the particular combined representation of those paramete= rs apparently specified in the AEAD draft. =3B I will correc= t the terminology usage in the next revision of the JOSE specifications.


T= he semantic point remains that it=E2=80=99s cleaner and more flexible to ha= ve the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs.=  =3BIn JOSE=E2=80=99s particular use case=2C that would be a sig= nificantly better match and easier for implementers to use.



J= OSE already has a way of combining the inputs and outputs that=E2=80=99s in= herent to its representation=2C and it doesn=E2=80=99t match the one you=E2=80=99ve specified. =3B GCM=2C CTR=2C an= d the current JOSE-specified algorithms are a great fit for this=2C as they= can directly use that representation. =3B 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= . =3B That=E2=80=99s just more work for implementers=2C and it=E2=80=99s n= ot semantically necessary work.

One could just as easily argue that =3Bthe unnecessary w= ork comes from the fact that =3Bdraft-ietf-jose-json-web-algorithms-07 = defines its own AEAD algorithms=2C which do not use the RFC 5116 interface.  =3B The draft confusingly references that RFC after i= t defines AEAD=2C but then does something different.  =3B If the plan i= s really going to be for the JOSE WG to define its own AEAD algorithms that= are incompatible (which I hope is not the case)=2C the differences and motivation deserve to be documented.  =3B

The motivation for 5116 incorporating the authentication dat= a into the ciphertext was to simplify the interface and move more of the cr= ypto details under the crypto interface.  =3B These are still valid motivations=2C though at this point the most important rea= son to use the interface is to avoid gratuitous incompatibility.  =3BOt= her protocols have not had any trouble in using the 5116 interface=3B See R= FC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SSH GCM)=2C or =3Bdraft-ietf-avtcore-srtp-aes-gcm=2C for instance. &n= bsp=3B


A= re you open to specifying versions of your algorithms that don=E2=80=99t re= quire a particular combination method for the parameters=2C but instead leave the combination up to the use case?&nbs= p=3B I=E2=80=99m fine with you also specifying a specific combinatio= n method as an optional feature of the specification.  =3BBut it shouldn=E2=80=99t be part of the alg= orithm definition=2C just like it isn=E2=80=99t for GCM.

I am not dogmatically opposed to other interfaces=2C but the= best solution here is for JOSE to actually use the 5116 interface=2C like = this:

X.Y. = Authenticated Encryption

 = =3B  =3BThis section defines the specifics of encrypting the JWE Plaint= ext
 = =3B  =3BUsing the Authenticated Encryption with Associated Data (AEAD)<= /font>
 = =3B  =3Bas defined in RFC 5116.  =3B =3BThe= authenticated encryption operation =3B
 =3B  =3Bhas four inputs=2C as follows:

 =3B  =3B  =3BThe secret key is the CMK.

 =3B  =3B  =3BThe associated data is the bytes of the= ASCII representation of the concatenation of
 =3B  =3B  =3Bthe Encoded JWE Header=2C a period ('.') cha= racter=2C the Encoded JWE
 =3B  =3B  =3BEncrypted Key=2C a second period character (= '.')=2C and the Encoded JWE
 =3B  =3B  =3BInitialization Vector=2C per Section 5 of th= e JWE specification.
 =3B  =3B  =3B The plaintext =2C which contains the data t= o be encrypted and
 =3B  =3B  =3B authenticated.

 =3B  =3B  =3B A nonce N=2C with a length of either 0= or 96 bits.  =3B If the length
 = =3B  =3B  =3B is zero=2C the nonce is omitted.  =3BOtherwise=2C= the nonce
 = =3B  =3B  =3B is as described in Section 3 of RFC 5116.  =3B&nb= sp=3B

 =3B  =3BThere is a single output=2C the Ciphertext.  =3B<= /div>

 =3B  =3BThe "=3Benc"=3B header =3B= parameter values are set as follows:

 =3B  =3B "=3Benc"=3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3BAlgorithm  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B =3B
 = =3B  =3B --------------------------------------------------------------= ---------
 =3B  =3B =3B"=3BA128GCM"=3B  =3B=  =3B =3BAEAD_AES_128_GCM  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B  =3B  =3B
 =3B  =3B "=3BA256GCM"=3B  =3B  =3B AEAD_AE= S_256_GCM  =3B  =3B  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B =3B
 =3B  =3B  =3B"=3BA128CHS"=3B  =3B  =3B=  =3BAEAD_AES_128_CBC_HMAC_SHA_256  =3B  =3B
 =3B  =3B  =3B"=3BA25= 6CHS"=3B  =3B  =3B  =3BAEAD_AES_256_CBC_HMAC_SHA_512  = =3B
 =3B  =3B  =3B "=3BA128SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_256
 =3B  =3B  =3B "=3BA256SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_384

 = =3B  =3B  =3Breferences corresponding to =3Bthese sym= bolic names.  =3B

If we= want to make actual progress on crypto interfaces=2C the thing that would = be worth doing is defining a simpler interface that moves the nonce details= into the ciphertext (and thus away from the user).  =3B Moving the authentication data out of the ciphertext w= ould be movement in the wrong direction=2C in my opinion.  =3B =3B<= /font>

David


<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B Best wishes=2C

<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B -- Mike



From: David McGrew (mcgre= w) [mailto:mcgrew@cisco.com]
Sent: Monday=2C November 12=2C 2012 11:43 AM
To: Mike Jones=3B cfrg@irtf.org= =3B jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


Hi Mike=2C


From: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
Date: Monday=2C November 12=2C 2012 1:55 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"= =3B <=3Bcfrg@irt= f.org>=3B=2C "=3Bjose@ietf= .org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


A= s background=2C if there was a version of this spec that did not assume tha= t the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AE= S GCM and AES CTR do=2C it would be a better match for JOSE=E2=80=99s use c= ase.

 =3B

I believe th= at what you are referring to is the inclusion of the authentication tag in = the authenticated ciphertext.  =3B This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature = of all 19 of the AEAD algorithms that have been defined so far.  =3B Fo= r comparison=2C =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2 says =3B


 =3B &nb= sp=3B  =3B  =3BThe AEAD Ciphertext consists of the string S=2C with= the string T

 =3B &nb= sp=3B  =3B  =3Bappended to it.  =3BThis Ciphertext is returned = as the output of the

 =3B &nb= sp=3B  =3B  =3BAEAD encryption operation.

 =3B

Where S is t= he ciphertext and T is the authentication tag.  =3B =3BRFC 5116 say= s


 =3B &nb= sp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B"=3BThe AEAD_AES_128_GCM ciphertext is formed by

 =3B &nb= sp=3Bappending the authentication tag provided as an output to the GCM

 =3B &nb= sp=3Bencryption operation to the ciphertext that is output by that

 =3B &nb= sp=3Boperation."=3B


David=


&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B -- Mike


From: mcgrew@cisco.com
To: cfrg@irtf.org=3B jose@ietf.org
Date: Mon=2C 12 Nov 2012 18:20:57 +=3B0000
CC: Kenny.Paterson@rhul.ac.uk<= /a>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01

Hi=2C
This draft has been proposed for use in the JOSE WG <=3Bhttp://= datatracker.ietf.org/wg/jose/>=3B =3B=2C where its adoption would allow the working group to omit "=3Braw"=3B unauthenticated = encryption=2C e.g. AES-CBC=2C and only include authenticated encryption. &n= bsp=3B Thus I am asking for your help in making =3B
John Foley generated test cases that correspond to the curre= nt version of the draft=2C but I didn't include these in the draft because = I did not yet get confirmation from a second independent implementation.  =3B With hope=2C there will not be any need for any n= ormative changes=2C and I will include these after I get confirmation. &nbs= p=3B
Thanks=2C
David

_______________________________________________ jose mailing list jose@ietf.org ht= tps://www.ietf.org/mailman/listinfo/jose
--_c18d8d59-6f64-4747-8f62-240c572c3402_-- From dharkins@lounge.org Mon Nov 12 18:58:13 2012 Return-Path: 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 2C6C021F8853 for ; Mon, 12 Nov 2012 18:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 lKvDSXJQdtKf for ; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A53CD21F8850 for ; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 14D301022400A; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Message-ID: In-Reply-To: References: Date: Mon, 12 Nov 2012 18:58:12 -0800 (PST) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mcgrew@cisco.com, cfrg@irtf.org, jose@ietf.org Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:58:13 -0000 On Mon, November 12, 2012 5:43 pm, Peter Gutmann wrote: > Dan Harkins writes: > >>The downside is that it's slower than GCM but is probably faster than >> CBC- >>HMAC with SHA2. > > A much bigger downside is that it requires two passes over the data, > making it > unusable with any streaming implementation. This limits its applicability > to > protocols with very short PDUs. That is exactly why it's slower than GCM. But the alternative that's being discussed for JOSE does 2 passes of the data anyway, one with HMAC-SHA256 and another with AES-CBC, so it sounds a little hard to believe that 2 passes is a limitation for the application at hand. Dan. From James.H.Manger@team.telstra.com Mon Nov 12 22:33:36 2012 Return-Path: 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 B6B5621F88EA for ; Mon, 12 Nov 2012 22:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 QJJi0yFsNuzN for ; Mon, 12 Nov 2012 22:33:35 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id BD24B21F88E4 for ; Mon, 12 Nov 2012 22:33:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,765,1344175200"; d="scan'208,217";a="108602605" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="92856483" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 13 Nov 2012 17:33:31 +1100 From: "Manger, James H" To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" Date: Tue, 13 Nov 2012 17:33:30 +1100 Thread-Topic: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgCAAFxuQA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115004FD4BA@WSMSG3153V.srv.dir.telstra.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.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_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 06:33:36 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEwDQoNClRoaXMgaXMgbXVjaCBjbGVhcmVyLCBhbmQgbXVjaCBtb3JlIHN1aXRhYmxlIGZvciBz ZXBhcmF0aW5nIHdoYXQgZ29lcyBpbiBhIEpPU0UgbGlicmFyeSB2cyB3aGF0IGdvZXMgaW4gYSBn ZW5lcmFsLXB1cnBvc2UgY3J5cHRvIGxpYnJhcnkuIEV2ZW4gaWYgYSBKT1NFIGxpYnJhcnkgbmVl ZHMgdG8gaW1wbGVtZW50IHBhcnRzIG9mIHRoZSBjcnlwdG8gdG9kYXkgYmVjYXVzZSBuYXRpdmUg QUVBRCBzdXBwb3J0IGlzIG5vdCB5ZXQgcHJlc2VudCwgdGhpcyBzb2x1dGlvbiBtYWtlcyBpdCBt dWNoIG1vcmUgbGlrZWx5IEpPU0Ugd2lsbCBiZSBjb21wYXRpYmxlIHdpdGggbmF0aXZlIEFFQUQg YXMgaXQgYmVjb21lcyBhdmFpbGFibGUuIEkgdGhpbmsgaXQgaXMgdW5saWtlbHkgdGhhdCBuYXRp dmUgQUVBRCBzdXBwb3J0IChvbmNlIGF2YWlsYWJsZSkgd291bGQgc3VwcG9ydCBib3RoIEpPU0Ug YW5kIGRyYWZ0LW1jZ3JldyB2YXJpYW50cyBvZiBBRUFELWZyb20tQUVTLUNCQy1ITUFDLiBUaGUg ZHJhZnQtbWNncmV3IHZhcmlhbnQgaGFzIGEgYmV0dGVyIGNoYW5jZSBvZiBiZWluZyBpbXBsZW1l bnRlZCBiZWNhdXNlIGl0IGRvZXNu4oCZdCBpbXBvc2UgYSAzMyUgcGVyZm9ybWFuY2UgcGVuYWx0 eSBmb3IgdGhlIE1BQ2luZyBwYXJ0LCBhbmQgdGhlIG90aGVyIGRpZmZlcmVuY2VzIGFyZSB0cml2 aWFsLg0KDQpUaGUgZmFjdCB0aGF0IHNvbWUgZXhpc3RpbmcgQUVBRCBhbGdvcml0aG1zIChTSVYg W1JGQyA1Mjk3XSkgZG9u4oCZdCBwcm9kdWNlIGEgc2VwYXJhdGUgYXV0aGVudGljYXRpb24gdGFn IGlzIGEgY2xlYXIgaW5kaWNhdGlvbiB0aGF0IGEgc2luZ2xlIGNpcGhlcnRleHQgb3V0cHV0IGlz IGEgYmV0dGVyIGdlbmVyYWwgbW9kZWwgZm9yIEFFQUQgaW4gSk9TRSB0aGFuIHNlcGFyYXRlIGNp cGhlcnRleHQgYW5kIGludGVncml0eSB2YWx1ZXMgYXMgaW4gSldFIHRvZGF5Lg0KDQpFZGl0b3Jp YWxzOg0K4oCcSldFIEluaXRpYWxpemF0aW9uIFZlY3RvcuKAnSBzaG91bGQgYmUgcmVuYW1lZCDi gJxKV0UgTm9uY2XigJ0uDQpUaGUgbm9uY2UgcGFyYWdyYXBoIG5lZWRu4oCZdCBoYXJkd2lyZSAy IGxlbmd0aHMgKDAgYW5kIDk2IGJpdHMpIOKAkyBsZWF2ZSBpdCB0byBlYWNoIGFsZyB0byBzcGVj aWZ5Lg0KVGhlIHRhYmxlIGNhbiBpbmNsdWRlIGtleSBhbmQgbm9uY2Ugc2l6ZXMuDQogICAgImVu YyIgICAgICAgICAgICAgICAga2V5IHNpemUgICAgbm9uY2Ugc2l6ZSAgQWxnb3JpdGhtDQogICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICAiQTEyOEdDTSIgICAxNiBieXRlcyAgICAxMiBieXRlcyAgICAg QUVBRF9BRVNfMTI4X0dDTQ0KICAgICJBMjU2R0NNIiAgIDMyIGJ5dGVzICAgIDEyIGJ5dGVzICAg ICBBRUFEX0FFU18yNTZfR0NNDQogICAgICJBMTI4Q0hTIiAgICAgNDggYnl0ZXMgICAgIDAgYnl0 ZXMgICAgICBBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1Ng0KICAgICAiQTI1NkNIUyIgICAg IDY0IGJ5dGVzICAgICAwIGJ5dGVzICAgICAgQUVBRF9BRVNfMjU2X0NCQ19ITUFDX1NIQV81MTIN Cg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0 bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBNY0dyZXcgKG1jZ3Jl dykNClNlbnQ6IFR1ZXNkYXksIDEzIE5vdmVtYmVyIDIwMTIgMTA6MjAgQU0NClRvOiBNaWNoYWVs IEpvbmVzOyBjZnJnQGlydGYub3JnOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Nmcmdd IFtqb3NlXSBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBRVMtQ0JDIGFuZCBITUFDLVNI QSwgdmVyc2lvbiAwMQ0KDQrigKYNCkkgYW0gbm90IGRvZ21hdGljYWxseSBvcHBvc2VkIHRvIG90 aGVyIGludGVyZmFjZXMsIGJ1dCB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlIGlzIGZvciBKT1NFIHRv IGFjdHVhbGx5IHVzZSB0aGUgNTExNiBpbnRlcmZhY2UsIGxpa2UgdGhpczoNCg0KWC5ZLiBBdXRo ZW50aWNhdGVkIEVuY3J5cHRpb24NCg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHNwZWNp ZmljcyBvZiBlbmNyeXB0aW5nIHRoZSBKV0UgUGxhaW50ZXh0DQogICBVc2luZyB0aGUgQXV0aGVu dGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKQ0KICAgYXMgZGVm aW5lZCBpbiBSRkMgNTExNi4gICBUaGUgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIG9wZXJhdGlv bg0KICAgaGFzIGZvdXIgaW5wdXRzLCBhcyBmb2xsb3dzOg0KDQogICAgIFRoZSBzZWNyZXQga2V5 IGlzIHRoZSBDTUsuDQoNCiAgICAgVGhlIGFzc29jaWF0ZWQgZGF0YSBpcyB0aGUgYnl0ZXMgb2Yg dGhlIEFTQ0lJIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mDQogICAgIHRo ZSBFbmNvZGVkIEpXRSBIZWFkZXIsIGEgcGVyaW9kICgnLicpIGNoYXJhY3RlciwgdGhlIEVuY29k ZWQgSldFDQogICAgIEVuY3J5cHRlZCBLZXksIGEgc2Vjb25kIHBlcmlvZCBjaGFyYWN0ZXIgKCcu JyksIGFuZCB0aGUgRW5jb2RlZCBKV0UNCiAgICAgSW5pdGlhbGl6YXRpb24gVmVjdG9yLCBwZXIg U2VjdGlvbiA1IG9mIHRoZSBKV0Ugc3BlY2lmaWNhdGlvbi4NCg0KICAgICAgVGhlIHBsYWludGV4 dCAsIHdoaWNoIGNvbnRhaW5zIHRoZSBkYXRhIHRvIGJlIGVuY3J5cHRlZCBhbmQNCiAgICAgIGF1 dGhlbnRpY2F0ZWQuDQoNCiAgICAgIEEgbm9uY2UgTiwgd2l0aCBhIGxlbmd0aCBvZiBlaXRoZXIg MCBvciA5NiBiaXRzLiAgIElmIHRoZSBsZW5ndGgNCiAgICAgIGlzIHplcm8sIHRoZSBub25jZSBp cyBvbWl0dGVkLiAgT3RoZXJ3aXNlLCB0aGUgbm9uY2UNCiAgICAgIGlzIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMgb2YgUkZDIDUxMTYuDQoNCiAgIFRoZXJlIGlzIGEgc2luZ2xlIG91dHB1dCwg dGhlIENpcGhlcnRleHQuDQoNCiAgIFRoZSAiZW5jIiBoZWFkZXIgIHBhcmFtZXRlciB2YWx1ZXMg YXJlIHNldCBhcyBmb2xsb3dzOg0KDQogICAgImVuYyIgICAgICAgICAgICAgICAgICBBbGdvcml0 aG0NCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICJBMTI4R0NNIiAgICAgQUVBRF9BRVNfMTI4X0dD TQ0KICAgICJBMjU2R0NNIiAgICAgQUVBRF9BRVNfMjU2X0dDTQ0KICAgICAiQTEyOENIUyIgICAg ICBBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1Ng0KICAgICAiQTI1NkNIUyIgICAgICBBRUFE X0FFU18yNTZfQ0JDX0hNQUNfU0hBXzUxMg0KICAgICAgIkExMjhTSVYiICAgICAgQUVBRF9BRVNf U0lWX0NNQUNfMjU2DQogICAgICAiQTI1NlNJViIgICAgICBBRUFEX0FFU19TSVZfQ01BQ18zODQN Cg0KICAgICAgU2VlIDxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2FlYWQtcGFyYW1l dGVycy9hZWFkLXBhcmFtZXRlcnMueG1sPjxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L2FlYWQtcGFyYW1ldGVycy9hZWFkLXBhcmFtZXRlcnMueG1sJTNlPiBmb3IgdGhlDQogICAgIHJl ZmVyZW5jZXMgY29ycmVzcG9uZGluZyB0byB0aGVzZSBzeW1ib2xpYyBuYW1lcy4NCg== --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5lY3hhcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOmVjeGFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KzEwPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGlzIGlzIG11Y2ggY2xlYXJlciwgYW5kIG11Y2ggbW9yZSBzdWl0YWJs ZSBmb3Igc2VwYXJhdGluZyB3aGF0IGdvZXMgaW4gYSBKT1NFIGxpYnJhcnkgdnMgd2hhdCBnb2Vz IGluIGEgZ2VuZXJhbC1wdXJwb3NlIGNyeXB0byBsaWJyYXJ5LiBFdmVuIGlmIGEgSk9TRSBsaWJy YXJ5IG5lZWRzIHRvIGltcGxlbWVudCBwYXJ0cyBvZiB0aGUgY3J5cHRvIHRvZGF5IGJlY2F1c2Ug bmF0aXZlIEFFQUQgc3VwcG9ydCBpcyBub3QgeWV0IHByZXNlbnQsIHRoaXMgc29sdXRpb24gbWFr ZXMgaXQgbXVjaCBtb3JlIGxpa2VseSBKT1NFIHdpbGwgYmUgY29tcGF0aWJsZSB3aXRoIG5hdGl2 ZSBBRUFEIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxlLiBJIHRoaW5rIGl0IGlzIHVubGlrZWx5IHRo YXQgbmF0aXZlIEFFQUQgc3VwcG9ydCAob25jZSBhdmFpbGFibGUpIHdvdWxkIHN1cHBvcnQgYm90 aCBKT1NFIGFuZCBkcmFmdC1tY2dyZXcgdmFyaWFudHMgb2YgQUVBRC1mcm9tLUFFUy1DQkMtSE1B Qy4gVGhlIGRyYWZ0LW1jZ3JldyB2YXJpYW50IGhhcyBhIGJldHRlciBjaGFuY2Ugb2YgYmVpbmcg aW1wbGVtZW50ZWQgYmVjYXVzZSBpdCBkb2VzbuKAmXQgaW1wb3NlIGEgMzMlIHBlcmZvcm1hbmNl IHBlbmFsdHkgZm9yIHRoZSBNQUNpbmcgcGFydCwgYW5kIHRoZSBvdGhlciBkaWZmZXJlbmNlcyBh cmUgdHJpdmlhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBmYWN0IHRoYXQgc29tZSBleGlzdGlu ZyBBRUFEIGFsZ29yaXRobXMgKFNJViBbUkZDIDUyOTddKSBkb27igJl0IHByb2R1Y2UgYSBzZXBh cmF0ZSBhdXRoZW50aWNhdGlvbiB0YWcgaXMgYSBjbGVhciBpbmRpY2F0aW9uIHRoYXQgYSBzaW5n bGUgY2lwaGVydGV4dCBvdXRwdXQgaXMgYSBiZXR0ZXIgZ2VuZXJhbCBtb2RlbCBmb3IgQUVBRCBp biBKT1NFIHRoYW4gc2VwYXJhdGUgY2lwaGVydGV4dCBhbmQgaW50ZWdyaXR5IHZhbHVlcyBhcyBp biBKV0UgdG9kYXkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FZGl0b3JpYWxzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7igJxKV0Ug SW5pdGlhbGl6YXRpb24gVmVjdG9y4oCdIHNob3VsZCBiZSByZW5hbWVkIOKAnEpXRSBOb25jZeKA nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+VGhlIG5vbmNlIHBhcmFncmFwaCBuZWVkbuKAmXQgaGFyZHdpcmUgMiBsZW5ndGhz ICgwIGFuZCA5NiBiaXRzKSDigJMgbGVhdmUgaXQgdG8gZWFjaCBhbGcgdG8gc3BlY2lmeS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhlIHRhYmxlIGNhbiBpbmNsdWRlIGtleSBhbmQgbm9uY2Ugc2l6ZXMuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDC oCAmcXVvdDtlbmMmcXVvdDvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAga2V5IHNpemXC oCDCoMKgbm9uY2Ugc2l6ZcKgIEFsZ29yaXRobcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7C oMKgwqAgJnF1b3Q7QTEyOEdDTSZxdW90O8KgwqAgMTYgYnl0ZXPCoCDCoMKgMTIgYnl0ZXPCoMKg wqDCoCBBRUFEX0FFU18xMjhfR0NNwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoCZxdW90O0EyNTZH Q00mcXVvdDvCoMKgIDMyIGJ5dGVzwqDCoMKgIDEyIGJ5dGVzwqAgwqDCoMKgQUVBRF9BRVNfMjU2 X0dDTcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgJnF1b3Q7QTEyOENIUyZxdW90O8KgwqDC oMKgIDQ4IGJ5dGVzwqDCoMKgwqAgMCBieXRlc8KgwqDCoMKgIMKgQUVBRF9BRVNfMTI4X0NCQ19I TUFDX1NIQV8yNTbCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAmcXVvdDtBMjU2Q0hTJnF1b3Q7wqDC oMKgwqAgNjQgYnl0ZXPCoMKgwqDCoCAwIGJ5dGVzwqDCoMKgwqAgwqBBRUFEX0FFU18yNTZfQ0JD X0hNQUNfU0hBXzUxMsKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBN YW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmdd IDxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgTWNHcmV3IChtY2dyZXcpPGJyPjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCAxMyBOb3ZlbWJlciAyMDEyIDEwOjIwIEFNPGJyPjxiPlRvOjwvYj4gTWljaGFl bCBKb25lczsgY2ZyZ0BpcnRmLm9yZzsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFtDZnJnXSBbam9zZV0gQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQUVTLUNCQyBh bmQgSE1BQy1TSEEsIHZlcnNpb24gMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5JIGFtIG5vdCBkb2dtYXRpY2FsbHkgb3Bwb3NlZCB0byBvdGhl ciBpbnRlcmZhY2VzLCBidXQgdGhlIGJlc3Qgc29sdXRpb24gaGVyZSBpcyBmb3IgSk9TRSB0byBh Y3R1YWxseSB1c2UgdGhlIDUxMTYgaW50ZXJmYWNlLCBsaWtlIHRoaXM6PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Y LlkuIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+Jm5ic3A7ICZuYnNwO1RoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBzcGVjaWZpY3Mg b2YgZW5jcnlwdGluZyB0aGUgSldFIFBsYWludGV4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO1VzaW5nIHRoZSBBdXRoZW50aWNhdGVkIEVu Y3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7YXMgZGVmaW5lZCBpbiBSRkMgNTEx Ni4gJm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj4mbmJzcDtUaGUgYXV0aGVudGlj YXRlZCBlbmNyeXB0aW9uIG9wZXJhdGlvbiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUt c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5i c3A7ICZuYnNwO2hhcyBmb3VyIGlucHV0cywgYXMgZm9sbG93czo8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2Vj cmV0IGtleSBpcyB0aGUgQ01LLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBhc3NvY2lhdGVk IGRhdGEgaXMgdGhlIGJ5dGVzIG9mIHRoZSBBU0NJSSByZXByZXNlbnRhdGlvbiBvZiB0aGUgY29u Y2F0ZW5hdGlvbiBvZjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgRW5jb2RlZCBKV0UgSGVhZGVyLCBhIHBlcmlv ZCAoJy4nKSBjaGFyYWN0ZXIsIHRoZSBFbmNvZGVkIEpXRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtFbmNyeXB0ZWQgS2V5LCBh IHNlY29uZCBwZXJpb2QgY2hhcmFjdGVyICgnLicpLCBhbmQgdGhlIEVuY29kZWQgSldFPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNw O0luaXRpYWxpemF0aW9uIFZlY3RvciwgcGVyIFNlY3Rpb24gNSBvZiB0aGUgSldFIHNwZWNpZmlj YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAm bmJzcDsgJm5ic3A7IFRoZSBwbGFpbnRleHQgLCB3aGljaCBjb250YWlucyB0aGUgZGF0YSB0byBi ZSBlbmNyeXB0ZWQgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZu YnNwOyBBIG5vbmNlIE4sIHdpdGggYSBsZW5ndGggb2YgZWl0aGVyIDAgb3IgOTYgYml0cy4gJm5i c3A7IElmIHRoZSBsZW5ndGg8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB6ZXJvLCB0aGUgbm9uY2UgaXMgb21p dHRlZC4gJm5ic3A7T3RoZXJ3aXNlLCB0aGUgbm9uY2U8L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMgb2YgUkZDIDUxMTYuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7VGhlcmUgaXMgYSBzaW5nbGUgb3V0cHV0LCB0aGUgQ2lw aGVydGV4dC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO1RoZSAmcXVvdDtlbmMm cXVvdDsgaGVhZGVyJm5ic3A7IHBhcmFtZXRlciB2YWx1ZXMgYXJlIHNldCBhcyBmb2xsb3dzOjwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g Y2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmcXVvdDtlbmMmcXVvdDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbGdvcml0 aG0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtBMTI4R0NNJnF1b3Q7ICZu YnNwOyAmbmJzcDsmbmJzcDtBRUFEX0FFU18xMjhfR0NNICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxl LXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPiZuYnNwOyAmbmJzcDsgJnF1b3Q7QTI1NkdDTSZxdW90OyAmbmJzcDsgJm5ic3A7IEFFQURf QUVTXzI1Nl9HQ00gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNw OyAmbmJzcDsmcXVvdDtBMTI4Q0hTJnF1b3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QUVBRF9BRVNf MTI4X0NCQ19ITUFDX1NIQV8yNTYgJm5ic3A7ICZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFz cz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0EyNTZDSFMmcXVvdDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtBRUFEX0FFU18yNTZfQ0JDX0hNQUNfU0hBXzUxMiAmbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZxdW90O0ExMjhTSVYmcXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBRUFEX0FFU19T SVZfQ01BQ18yNTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O0EyNTZTSVYmcXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtBRUFEX0FFU19TSVZfQ01BQ18zODQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlZSAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9hZWFkLXBhcmFtZXRlcnMvYWVhZC1wYXJhbWV0ZXJzLnht bCUzZSI+aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9hZWFkLXBhcmFtZXRlcnMvYWVh ZC1wYXJhbWV0ZXJzLnhtbCZndDs8L2E+Jm5ic3A7Zm9yIHRoZSZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZWZlcmVu Y2VzIGNvcnJlc3BvbmRpbmcgdG88c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPiZuYnNwO3Ro ZXNlIHN5bWJvbGljIG5hbWVzLiAmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_-- From mcgrew@cisco.com Tue Nov 13 08:31:54 2012 Return-Path: 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 70AB721F8771 for ; Tue, 13 Nov 2012 08:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 dIgCe2CtVJWh for ; Tue, 13 Nov 2012 08:31:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BB5E121F8743 for ; Tue, 13 Nov 2012 08:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24252; q=dns/txt; s=iport; t=1352824307; x=1354033907; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=HOAweE7u4s4DT3cNeIP4WIBrnrr2Mu0ih4Y27BymVsQ=; b=SAlY6fATgy5x/j+5hkwRef4P2kReUdlaGw2bxlKz27hbyBE+ifdpZqDf Mu56PFy9X4iZAM0U2XA4pEwyYsf1fUc5F4RGzJRfKMIb3S/GmwyL5jM2Z 23nkftno7kQWIsuPEWYoxGHwe3cWcbPB3hB0GJ7YI/h2Xrmka4kWxUPlH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIt0olCtJV2d/2dsb2JhbABEgknBJIEIgh4BAQEEEgEaXgEIEQMBAQELFgc5FAkIAgQBEggBEgeHVgMPC5oXj2WGTx2JRIwqhXNhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141958792" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2012 16:31:44 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qADGVhuM030265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 16:31:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 10:31:43 -0600 From: "David McGrew (mcgrew)" To: "Manger, James H" , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgCAAFxuQIAAw+YA Date: Tue, 13 Nov 2012 16:31:42 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6@xmb-rcd-x04.cisco.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115004FD4BA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19360.002 x-tm-as-result: No--32.424200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:31:54 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi James, From: , James H > Date: Tuesday, November 13, 2012 1:33 AM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01 +10 This is much clearer, and much more suitable for separating what goes in a = JOSE library vs what goes in a general-purpose crypto library. Even if a JO= SE library needs to implement parts of the crypto today because native AEAD= support is not yet present, this solution makes it much more likely JOSE w= ill be compatible with native AEAD as it becomes available. I think it is u= nlikely that native AEAD support (once available) would support both JOSE a= nd draft-mcgrew variants of AEAD-from-AES-CBC-HMAC. The draft-mcgrew varian= t has a better chance of being implemented because it doesn=92t impose a 33= % performance penalty for the MACing part, and the other differences are tr= ivial. The fact that some existing AEAD algorithms (SIV [RFC 5297]) don=92t produc= e a separate authentication tag is a clear indication that a single ciphert= ext output is a better general model for AEAD in JOSE than separate ciphert= ext and integrity values as in JWE today. Editorials: =93JWE Initialization Vector=94 should be renamed =93JWE Nonce=94. The nonce paragraph needn=92t hardwire 2 lengths (0 and 96 bits) =96 leave = it to each alg to specify. The table can include key and nonce sizes. "enc" key size nonce size Algorithm ----------------------------------------------------------------------- "A128GCM" 16 bytes 12 bytes AEAD_AES_128_GCM "A256GCM" 32 bytes 12 bytes AEAD_AES_256_GCM "A128CHS" 48 bytes 0 bytes AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" 64 bytes 0 bytes AEAD_AES_256_CBC_HMAC_SHA_512 Thanks for the good suggestions (agreed on all of them) and support. Regards, David -- James Manger From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Tuesday, 13 November 2012 10:20 AM To: Michael Jones; cfrg@irtf.org; jose@ietf.org Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01 =85 I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs, as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header, a period ('.') character, the Encoded JWE Encrypted Key, a second period character ('.'), and the Encoded JWE Initialization Vector, per Section 5 of the JWE specification. The plaintext , which contains the data to be encrypted and authenticated. A nonce N, with a length of either 0 or 96 bits. If the length is zero, the nonce is omitted. Otherwise, the nonce is as described in Section 3 of RFC 5116. There is a single output, the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94533B1A0135D84F9C9FB7FEBA90D1A7@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi James,

From: <Manger>, James H <<= a href=3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telst= ra.com>
Date: Tuesday, November 13, 2012 1:= 33 AM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [Cfrg] [jose] Authenti= cated Encryption with AES-CBC and HMAC-SHA, version 01

+10

 

This is much clearer, and much mor= e suitable for separating what goes in a JOSE library vs what goes in a gen= eral-purpose crypto library. Even if a JOSE library needs to implement parts of the crypto today because native= AEAD support is not yet present, this solution makes it much more likely J= OSE will be compatible with native AEAD as it becomes available. I think it= is unlikely that native AEAD support (once available) would support both JOSE and draft-mcgrew variants of AEAD= -from-AES-CBC-HMAC. The draft-mcgrew variant has a better chance of being i= mplemented because it doesn=92t impose a 33% performance penalty for the MA= Cing part, and the other differences are trivial.

 

The fact that some existing AEAD a= lgorithms (SIV [RFC 5297]) don=92t produce a separate authentication tag is= a clear indication that a single ciphertext output is a better general model for AEAD in JOSE than separate ciphertext= and integrity values as in JWE today.

 

Editorials:

=93JWE Initialization Vector=94 sh= ould be renamed =93JWE Nonce=94.

The nonce paragraph needn=92t hard= wire 2 lengths (0 and 96 bits) =96 leave it to each alg to specify.

The table can include key and nonc= e sizes.

    "enc"=             &nb= sp;   key size    nonce size  Algorithm =             &nb= sp;          

    ----------= -------------------------------------------------------------

    "A128GCM&q= uot;   16 bytes    12 bytes    = ; AEAD_AES_128_GCM          &n= bsp;            = ;           

    "A256= GCM"   32 bytes    12 bytes    = ; AEAD_AES_256_GCM        &nbs= p;            &= nbsp;           &nbs= p;

     &quo= t;A128CHS"     48 bytes     0 = bytes      AEAD_AES_128_CBC_HMAC_SHA_256 &nbs= p; 

     &quo= t;A256CHS"     64 bytes     0 = bytes      AEAD_AES_256_CBC_HMAC_SHA_512 

Thanks for the good suggestions (agreed on all of them) and support.

Regards,

David

 

--

James Manger

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; cfrg@irtf.org; jose@ietf.org
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and= HMAC-SHA, version 01

 

=85

I am not dogmatically opposed to other inte= rfaces, but the best solution here is for JOSE to actually use the 5116 int= erface, like this:

 

X= .Y. Authenticated Encryption

 

&= nbsp;  This section defines the specifics of encrypting the JWE Plaint= ext

&= nbsp;  Using the Authenticated Encryption with Associated Data (AEAD)<= /span>

&= nbsp;  as defined in RFC 5116.  =  The authenticated encryption operation =

   has four inputs, as follows:

<= o:p> 

&= nbsp;    The secret key is the CMK.

<= o:p> 

     The associated data is = the bytes of the ASCII representation of the concatenation of=

&= nbsp;    the Encoded JWE Header, a period ('.') character, the En= coded JWE

&= nbsp;    Encrypted Key, a second period character ('.'), and the = Encoded JWE

&= nbsp;    Initialization Vector, per Section 5 of the JWE specific= ation.

<= o:p> 

&= nbsp;     The plaintext , which contains the data to be encrypted= and

&= nbsp;     authenticated.

<= o:p> 

      A nonce N, with a leng= th of either 0 or 96 bits.   If the length

&= nbsp;     is zero, the nonce is omitted.  Otherwise, the non= ce

&= nbsp;     is as described in Section 3 of RFC 5116.   <= o:p>

<= o:p> 

&= nbsp;  There is a single output, the Ciphertext.  

<= o:p> 

   The "enc" header&nbs= p; parameter values are set as follows:

 

    "enc"    =              Algorithm     &n= bsp;                   

&= nbsp;   --------------------------------------------------------------= ---------

    "A128GCM" &nbs= p;   AEAD_AES_128_GCM             &= nbsp;                    =

    "A256GCM"   &n= bsp; AEAD_AES_256_GCM               &nbs= p;                   

     "A128CHS" &nb= sp;    AEAD_AES_128_CBC_HMAC_SHA_256    <= o:p>

     "A256CHS" &nb= sp;    AEAD_AES_256_CBC_HMAC_SHA_512  

&= nbsp;     "A128SIV"      AEAD_AES_SIV_CM= AC_256

&= nbsp;     "A256SIV"      AEAD_AES_SIV_CM= AC_384

 

&= nbsp;    references corresponding to these symbolic names.  

 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_-- From michael_b_jones@hotmail.com Tue Nov 13 15:33:27 2012 Return-Path: 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 44C5821F8793 for ; Tue, 13 Nov 2012 15:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TxRhZqmNFvgn for ; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.190.36]) by ietfa.amsl.com (Postfix) with ESMTP id D4EE621F8447 for ; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from BAY171-W47 ([65.54.190.60]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 15:33:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2df8537d-c1b1-4a26-b683-96413d67d4ed_" X-Originating-IP: [174.7.255.77] From: Michael Jones To: , , Date: Tue, 13 Nov 2012 15:33:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2012 23:33:26.0611 (UTC) FILETIME=[479C2230:01CDC1F7] Cc: cfrg@irtf.org Subject: [Cfrg] Vacationing this week & e-mail address X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:33:27 -0000 --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all=2C I wanted to let you know that I'm vacationing this week=2C and so= mostly won't be participating in discussions. I'll respond next week. Als= o=2C at present I=92m using the e-mail address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com.=20 When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly. Have= a good week=2C everyone! -- Mike=20 = --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all=2C
 =3B
I wanted to let you know that I'm vacationing this= week=2C and so mostly won't be participating in discussions. =3B I'll = respond next week.
&nbs= p=3B

Also=2C at present I=92m using the e-ma= il address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com. =3B When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly.

 =3B
Have a good week=2C everyone!
 =3B
-- Mike
 =3B


= --_2df8537d-c1b1-4a26-b683-96413d67d4ed_-- From Michael.Jones@microsoft.com Tue Nov 13 15:35:34 2012 Return-Path: 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 E97C321F8507 for ; Tue, 13 Nov 2012 15:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2xOwSyXhJiNR for ; Tue, 13 Nov 2012 15:35:33 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7943A21F84FC for ; Tue, 13 Nov 2012 15:35:33 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.201) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.556.9; Mon, 12 Nov 2012 18:56:07 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Mon, 12 Nov 2012 18:56:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.11]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Mon, 12 Nov 2012 18:55:18 +0000 From: Mike Jones To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfmjABA Date: Mon, 12 Nov 2012 18:55:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(377454001)(46102001)(16406001)(5343635001)(5343655001)(31966008)(512954001)(54316001)(54356001)(53806001)(51856001)(47976001)(15202345001)(33656001)(4396001)(47446002)(49866001)(50986001)(76482001)(44976002)(47736001)(74502001)(74662001)(55846005); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0663390E1B Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:35:35 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Dav= id McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David --_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As background, if there w= as 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 b= etter match for JOSE’s use case.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: cfrg-bou= nces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01

 

Hi,

 

There is a new version of &= quot;Authe= nticated 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=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been propose= d for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/> , where its adoptio= n would allow the working group to omit "raw" unauthenticated encr= yption, e.g. AES-CBC, and only include authenticated encryption.   Thu= s I am asking for your help in making 

 

John Foley generated test c= ases that correspond to the current version of the draft, but I didn't incl= ude 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 ge= t confirmation.  

 

Thanks,

 

David

--_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_-- From housley@vigilsec.com Sun Nov 18 04:45:40 2012 Return-Path: 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 8937721F84C0 for ; Sun, 18 Nov 2012 04:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k5A9yz8A2dt5 for ; Sun, 18 Nov 2012 04:45:39 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 71B1321F84B9 for ; Sun, 18 Nov 2012 04:45:39 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 85BFA9A4006; Sun, 18 Nov 2012 07:45:44 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id TjBKGZGNrKKm; Sun, 18 Nov 2012 07:45:33 -0500 (EST) Received: from [5.5.33.15] (vpn.snozzages.com [204.194.22.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AAA919A4002; Sun, 18 Nov 2012 07:45:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-91--874108683 From: Russ Housley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 18 Nov 2012 07:45:29 -0500 Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) Cc: IRTF CFRG , jose@ietf.org Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 12:45:40 -0000 --Apple-Mail-91--874108683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Have you looked at the algorithm in RFC 6476? While the discussion is = CMS-specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: > 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=92s use case. > =20 > -- Mike > =20 > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of David McGrew (mcgrew) > Sent: Monday, November 12, 2012 10:21 AM > To: cfrg@irtf.org; jose@ietf.org > Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01 > =20 > Hi, > =20 > There is a new version of "Authenticated Encryption with AES-CBC and = HMAC-SHA", and I would appreciate your review. It is online at = The diff between the current and the previous version = is available at = > =20 > This draft has been proposed for use in the JOSE WG = , 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=20 > =20 > 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. =20 > =20 > Thanks, > =20 > David > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-91--874108683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Have = you looked at the algorithm in RFC 6476?  While the discussion is = CMS-specific, the algorithm could be used with another = syntax.

Russ


On = Nov 12, 2012, at 1:55 PM, Mike Jones wrote:

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=92s use = case.
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org= ] On Behalf Of David McGrew = (mcgrew)
Sent: Monday, November 12, 2012 = 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated = Encryption with AES-CBC and HMAC-SHA, version = 01
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/?in= clude_text=3D1>   The diff between the current and the = previous version is available at < 
_______________________________= ________________
Cfrg mailing list
 To: "'Russ Housley'" , "'Mike Jones'" References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Sun, 18 Nov 2012 10:44:56 -0800 Message-ID: <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CDC579.C02642A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AQH7LcwHg/ezhejU5qFNOX+NYfYUAwFycKfHApQrwMiXdOUeEA== Cc: 'IRTF CFRG' , jose@ietf.org Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 18:45:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0039_01CDC579.C02642A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Quick feedback on the draft . Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme. . Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don't know of any, but .), I'd suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn't distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad. . Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above). Best, - Tolga From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: 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. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] 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 > The diff between the current and the previous version is available at > This draft has been proposed for use in the JOSE WG > , 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 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg ------=_NextPart_000_0039_01CDC579.C02642A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Quick feedback on the draft

 

·         = Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear = this is not new, but a reuse of an existing padding = scheme.

·         = Section 2.2, step 3. When MAC verification fails, the draft = recommends halting the operation before CBC decryption. We have seen = timing and error-code based attacks against TLS’ MAC-then-Encrypt = scheme. I realize that the draft is prescribing E-t-M. Nonetheless, = considering a potential flaw in HMAC-SHA2 series (I don’t know of = any, but …), I’d suggest not halting the operation even = after MAC check fails, but continuing on to CBC decryption, and then = returning an error that doesn’t distinguish between a MAC and a = decryption (pad check) error. Yes, this would consume more CPU cycles = only to waste them *under an attack*, which is not necessarily = bad.

·         = Section 2.2, step 5. Unspecified error case of invalid padding (link = to my comment above).

 

Best,

-          = Tolga

 

From:= = cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Russ Housley
Sent: Sunday, November 18, 2012 4:45 = AM
To: Mike Jones
Cc: IRTF CFRG; = jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption = with AES-CBC and HMAC-SHA, version = 01

 

Have you = looked at the algorithm in RFC 6476?  While the discussion is = CMS-specific, the algorithm could be used with another = syntax.

 

Russ

 

 

On = Nov 12, 2012, at 1:55 PM, Mike Jones wrote:



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.

 

           &nbs= p;            = ;            =             &= nbsp;           -- = Mike

 

From:=  cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew = (mcgrew)
Sent: Monday, November 12, 2012 = 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] 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-a= ead-aes-cbc-hmac-sha2/?include_text=3D1>   The diff = between the current and the previous version is available at <http://www.ietf.org/rfcdiff?url2=3Ddraft-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

_________= ______________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/ma= ilman/listinfo/cfrg

 

------=_NextPart_000_0039_01CDC579.C02642A0-- From Michael.Jones@microsoft.com Mon Nov 19 17:48:58 2012 Return-Path: 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 16BD921F87E6 for ; Mon, 19 Nov 2012 17:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zGlAFYL5sdyy for ; Mon, 19 Nov 2012 17:48:56 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1738D21F87E1 for ; Mon, 19 Nov 2012 17:48:55 -0800 (PST) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB007.protection.gbl (10.173.160.227) with Microsoft SMTP Server (TLS) id 15.0.556.9; Tue, 20 Nov 2012 01:48:49 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Tue, 20 Nov 2012 01:48:48 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Tue, 20 Nov 2012 01:48:43 +0000 From: Mike Jones To: Russ Housley Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNxYqe+EdNf2OoW02Ggo3Wp5fiaZfx9t3g Date: Tue, 20 Nov 2012 01:48:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668D8EE3@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(51914002)(377454001)(164054002)(47446002)(54316002)(4396001)(76482001)(49866001)(5343655001)(47736001)(50986001)(16406001)(550184003)(74662001)(47976001)(44976002)(31966008)(5343635001)(56776001)(54356001)(512954001)(15202345001)(53806001)(46102001)(51856001)(56816002)(74502001)(33656001)(55846005); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0671F32598 Cc: IRTF CFRG , "jose@ietf.org" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:48:58 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the pointer, Russ. This is a useful point of reference in sever= al regards. -- Mike From: Russ Housley [mailto:housley@vigilsec.com] Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-= specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: 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. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg --_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the pointer, R= uss.  This is a useful point of reference in several regards.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01

 

Have you looked at the algorithm in RFC 6476?  = While the discussion is CMS-specific, the algorithm could be used with anot= her syntax.

 

Russ

 

 

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:<= /o:p>



As background, if there w= as 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 b= etter match for JOSE’s use case.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: cfrg-bounces@irtf.org [mailt= o:cfrg-bounces@irtf.org] On Behalf Of David McGr= ew (mcgrew)
Sent: Monday, Nove= mber 12, 2012 10:21 AM
To: cfrg@irtf.org;=  jose@ietf.org
Subject: [Cfrg] Au= thenticated Encryption with AES-CBC and HMAC-SHA, version 01

 

Hi,

 

There is a new version of &= quot;Authe= nticated 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=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been propose= d for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/> , where its adoptio= n would allow the working group to omit "raw" unauthenticated encr= yption, e.g. AES-CBC, and only include authenticated encryption.   Thu= s I am asking for your help in making 

 

John Foley generated test c= ases that correspond to the current version of the draft, but I didn't incl= ude 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 ge= t confirmation.  

 

Thanks,

 

David

_____________________________________= __________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/m= ailman/listinfo/cfrg

 

--_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_-- From dmjacobson@sbcglobal.net Mon Nov 19 20:59:41 2012 Return-Path: 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 8E81821F8807 for ; Mon, 19 Nov 2012 20:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6] 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 WAo9Bs27YhmN for ; Mon, 19 Nov 2012 20:59:38 -0800 (PST) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE2821F8804 for ; Mon, 19 Nov 2012 20:59:38 -0800 (PST) Received: from [66.94.237.127] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Nov 2012 04:59:37 -0000 Received: from [68.142.198.207] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Nov 2012 04:59:37 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.mud.yahoo.com with NNFMP; 20 Nov 2012 04:59:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1353387577; bh=N7CmV9TVhbHdB00FTGO/zbLY4jZAL9z7ZSTdWBtU7xY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=FlM5bNNo1qt3YHaHKBJhYDZQ1eC6z9MY1YcGVh14dgZCvsP1QaQbPSY3oP5bHltem1skbPmsvORjr1B8h3s85BYN3XxPPBar8IufmYrE/fSC0HO+qHExUfE805yvUGRhldWSr23oRM16RBpL/Bj3b4t1GTWOtqvJiqiLPXhq5+w= X-Yahoo-Newman-Id: 772578.97549.bm@smtp111.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WcvZtEsVM1nHGcmVxRikrugDfrqFuRa7leClJ4b2RmTTLwY hWokEuuEFL_hVuuJyg8m6HkKaa6k_dd8G5HFXHOmxL3SVnnKzTfsCxX8f7AE xx5q_gU7HknbWvmdbjyXmheBZI38nOqyHJnu_91N5MCxYHMvurobnbqULIHz 5zHPGlEOmXAf4GborLOmGtFodTiozlvPAhClUplbaMxy4Bciro5WhqJEFKog rRzL_zo.LYv_gwS0tqL.kDk.m9GzY30cWXaHL3m9NtBgPcAGbKgWuUNo6Z6u YFOU_GLuhliyyHHEXFxP2JOmLSQqTq4aTiquJ_xWKlgSV3H_zJfhd4AMSG1C KhzJZPUdxIUOvF8Do.zAuw23qxYfkivKzPPFReFOkb0aGaca2hIpB0rQBfuc X.1UZaouEaN7vaiFVBHARQD7GH2beXqQisD2gsIfsXaIG3HplD3uqHMeECz3 BHhK0dDR9BF3xLDZkQ.caea3a3taUwg-- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- Received: from [192.168.1.73] (dmjacobson@99.120.98.171 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 19 Nov 2012 20:59:37 -0800 PST Message-ID: <50AB0E38.9050700@sbcglobal.net> Date: Mon, 19 Nov 2012 20:59:36 -0800 From: David Jacobson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: cfrg@irtf.org References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> In-Reply-To: <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> Content-Type: multipart/alternative; boundary="------------060401070801050705070309" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 04:59:41 -0000 This is a multi-part message in MIME format. --------------060401070801050705070309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I think I'd argue the other way on continuing on on when the MAC fails. One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt. If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there is never even the possibility of padding oracles, timing attacks, etc. If you go ahead with the decryption, you risk revealing something. --David On 11/18/2012 10:44 AM, Tolga Acar wrote: > > Quick feedback on the draft > > ·Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear > this is not new, but a reuse of an existing padding scheme. > > ·Section 2.2, step 3. When MAC verification fails, the draft > recommends halting the operation before CBC decryption. We have seen > timing and error-code based attacks against TLS' MAC-then-Encrypt > scheme. I realize that the draft is prescribing E-t-M. Nonetheless, > considering a potential flaw in HMAC-SHA2 series (I don't know of any, > but ...), I'd suggest not halting the operation even after MAC check > fails, but continuing on to CBC decryption, and then returning an > error that doesn't distinguish between a MAC and a decryption (pad > check) error. Yes, this would consume more CPU cycles only to waste > them **under an attack**, which is not necessarily bad. > > ·Section 2.2, step 5. Unspecified error case of invalid padding (link > to my comment above). > > Best, > > -Tolga > > *From:*cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] *On Behalf > Of *Russ Housley > *Sent:* Sunday, November 18, 2012 4:45 AM > *To:* Mike Jones > *Cc:* IRTF CFRG; jose@ietf.org > *Subject:* Re: [Cfrg] Authenticated Encryption with AES-CBC and > HMAC-SHA, version 01 > > Have you looked at the algorithm in RFC 6476? While the discussion is > CMS-specific, the algorithm could be used with another syntax. > > Russ > > On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: > > > > 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. > > -- Mike > > *From:*cfrg-bounces@irtf.org > [mailto:cfrg-bounces@irtf.org]*On Behalf > Of*David McGrew (mcgrew) > *Sent:*Monday, November 12, 2012 10:21 AM > *To:*cfrg@irtf.org ;jose@ietf.org > > *Subject:*[Cfrg] 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 > > > The diff between the current and the previous version is available at > > > > This draft has been proposed for use in the JOSE WG > > , 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 > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --------------060401070801050705070309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I think I'd argue the other way on continuing on on when the MAC fails.

One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt.  If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there is never even the possibility of padding oracles, timing attacks, etc.  If you go ahead with the decryption, you risk revealing something.

   --David

 

On 11/18/2012 10:44 AM, Tolga Acar wrote:

Quick feedback on the draft

 

·         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme.

·         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS’ MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don’t know of any, but …), I’d suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn’t distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

·         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).

 

Best,

-          Tolga

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

 

Have you looked at the algorithm in RFC 6476?  While the discussion is CMS-specific, the algorithm could be used with another syntax.

 

Russ

 

 

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:



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.

 

                                                            -- Mike

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] 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

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

 



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

--------------060401070801050705070309-- From t.acar@att.net Mon Nov 19 22:27:02 2012 Return-Path: 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 E9CFD21F8D2B for ; Mon, 19 Nov 2012 22:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 OirF74k8+M8q for ; Mon, 19 Nov 2012 22:26:59 -0800 (PST) Received: from nm3-vm0.access.bullet.mail.sp2.yahoo.com (nm3-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.108]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBE21F8B00 for ; Mon, 19 Nov 2012 22:26:59 -0800 (PST) Received: from [98.139.44.100] by nm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000 Received: from [67.195.14.111] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.gq1.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1353392816; bh=ncN+GYx3oNTWEA3KNRsM+KTw2uYucI1VGR7dke0QHIU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=BiyR2nAhOXkCm1Okwcv6aVHLvrUfScRpE15ofAnE6D/xNu7LRRUbOCrO7x40hVL3V8OoUthI+tp/ZygnLOFZfoZbL41BDrrQ/OGg8XITuvyusBJkexDivsK4w3nCLHnMESIGPJDAgNQji9hMsNptHBYzFTqHKXmqQx8NOjyw6Vw= X-Yahoo-Newman-Id: 426450.97242.bm@smtp108.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fa9DmUoVM1myPo.5psJEzJQeeh.nGEiP93751a5MDVCeMBY Sf7m.rMjoWZ80YASZRuQslkw_2lBgtGU7FyHxWP7Ru6JMYKoRwwhjxn1oDU9 ki.gcq6Tfqe.7Sc6PFVhUppK8zzwmMIDrHH88QsvSg27MNUzbNvH3SXBRAl. LDmogiOeX07UuGAfSxr6VLW93ihAAhWo_e64qlX7htCN0.tZK9ZsrKsAE8gE qhfsdDxzl3wlZTnFYAR93XoXKNnfkAFKGqqgi7GjVlJE6iWdBCVScO01ZZtV R.TTwNtlFPAjcBu_58N6zBWzcQ1vgtXAHM9xlX6LANkUoCsvvo9Ez2dQOeGJ EybSQ8AS.Wnz0mT7jz13WlvlAlo6mVQWPK9g0kw3am7EC0o0LR_DYXlDLJxy 2.IPyjqKSrp5N0eJ_zyVXQ0u8XUOm76_yxmG.Ozfyql2gNTlzs_q7_eCJ1dA URUZjbOguGWa3nII- X-Yahoo-SMTP: 3qJt0gGswBA7ciDNaLLHiPpvI7NLZWkkd3zL Received: from tolginator (t.acar@174.61.228.6 with login) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 19 Nov 2012 22:26:56 -0800 PST From: "Tolga Acar" To: "'David Jacobson'" , References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> <50AB0E38.9050700@sbcglobal.net> In-Reply-To: <50AB0E38.9050700@sbcglobal.net> Date: Mon, 19 Nov 2012 22:26:55 -0800 Message-ID: <00b001cdc6e8$09a82820$1cf87860$@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01CDC6A4.FB8A6660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7LcwHg/ezhejU5qFNOX+NYfYUAwFycKfHApQrwMgDFiARxQIEuJ6nl05m/MA= Content-Language: en-us Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 06:27:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B1_01CDC6A4.FB8A6660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 One big advantage of encrypt-then-MAC is that the receiving end = does MACverify-then-decrypt. If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there = is never even the possibility of padding oracles, timing attacks, etc. If = you go ahead with the decryption, you risk revealing something. I realize that is what the theory says up to a negligible probability; = but saying =93never even enter decryption stuff=94 is practically accurate = as far as we know today. I am concerned about not yet existent weaknesses in MAC functions (and perhaps their underlying hash functions if MAC =3D HMAC = as in this case), that would open an avenue for a side-channel leakage. Call = me paranoid, and say this is far-fetched. =20 If you go ahead with decryption regardless of a MAC failure, you will = return a failure if decryption fails. This is about MAC succeeding but = decryption failing, which ends up in a failure to be returned anyhow. If both = succeeds when they are not supposed to, then you found that negligible = probability case (or one of them). =20 - Tolga =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David Jacobson Sent: Monday, November 19, 2012 9:00 PM To: cfrg@irtf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 =20 I think I'd argue the other way on continuing on on when the MAC fails. One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt. If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there = is never even the possibility of padding oracles, timing attacks, etc. If = you go ahead with the decryption, you risk revealing something. --David =20 On 11/18/2012 10:44 AM, Tolga Acar wrote: Quick feedback on the draft =20 =B7 Page 5, item 3, padding string PS. Please \cite PKCS#5 so it = is clear this is not new, but a reuse of an existing padding scheme. =B7 Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen = timing and error-code based attacks against TLS=92 MAC-then-Encrypt scheme. I = realize that the draft is prescribing E-t-M. Nonetheless, considering a = potential flaw in HMAC-SHA2 series (I don=92t know of any, but =85), I=92d suggest = not halting the operation even after MAC check fails, but continuing on to = CBC decryption, and then returning an error that doesn=92t distinguish = between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily = bad. =B7 Section 2.2, step 5. Unspecified error case of invalid = padding (link to my comment above). =20 Best, - Tolga =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Russ Housley Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 =20 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-specific, the algorithm could be used with another syntax. =20 Russ =20 =20 On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: 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=92s use case. =20 -- Mike =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01 =20 Hi, =20 There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review. It is online at > The diff between the current and the previous = version is available at > =20 This draft has been proposed for use in the JOSE WG > , 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=20 =20 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. =20 =20 Thanks, =20 David _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg =20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg =20 ------=_NextPart_000_00B1_01CDC6A4.FB8A6660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  One big advantage of = encrypt-then-MAC is that the receiving end does = MACverify-then-decrypt.  If the message has been tampered with, the = MAC fails to verify and we never even enter the decryption stuff, thus = there is never even the possibility of padding oracles, timing attacks, = etc.  If you go ahead with the decryption, you risk revealing = something.

I realize that is what the theory says up to a negligible = probability; but saying “never even enter decryption stuff” = is practically accurate as far as we know today. I am concerned about = not yet existent weaknesses in MAC functions (and perhaps their = underlying hash functions if MAC =3D HMAC as in this case), that would = open an avenue for a side-channel leakage. Call me paranoid, and say = this is far-fetched.

 

If you go ahead with decryption regardless of a MAC failure, you will = return a failure if decryption fails. This is about MAC succeeding but = decryption failing, which ends up in a failure to be returned anyhow. If = both succeeds when they are not supposed to, then you found that = negligible probability case (or one of them).

 

-          = Tolga

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of David Jacobson
Sent: Monday, November 19, 2012 9:00 = PM
To: cfrg@irtf.org
Subject: Re: [Cfrg] = Authenticated Encryption with AES-CBC and HMAC-SHA, version = 01

 

I think = I'd argue the other way on continuing on on when the MAC = fails.

One big advantage of encrypt-then-MAC is that the = receiving end does MACverify-then-decrypt.  If the message has been = tampered with, the MAC fails to verify and we never even enter the = decryption stuff, thus there is never even the possibility of padding = oracles, timing attacks, etc.  If you go ahead with the decryption, = you risk revealing something.

   = --David

 

On 11/18/2012 10:44 AM, Tolga Acar = wrote:

Quick feedback on the draft

 

=B7         = Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear = this is not new, but a reuse of an existing padding = scheme.

=B7         = Section 2.2, step 3. When MAC verification fails, the draft = recommends halting the operation before CBC decryption. We have seen = timing and error-code based attacks against TLS’ MAC-then-Encrypt = scheme. I realize that the draft is prescribing E-t-M. Nonetheless, = considering a potential flaw in HMAC-SHA2 series (I don’t know of = any, but …), I’d suggest not halting the operation even = after MAC check fails, but continuing on to CBC decryption, and then = returning an error that doesn’t distinguish between a MAC and a = decryption (pad check) error. Yes, this would consume more CPU cycles = only to waste them *under an attack*, which is not necessarily = bad.

=B7         = Section 2.2, step 5. Unspecified error case of invalid padding (link = to my comment above).

 

Best,

-          = Tolga

 

From:= = cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] = On Behalf Of Russ Housley
Sent: Sunday, November 18, = 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org
Subject: Re: = [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version = 01

 

Have you = looked at the algorithm in RFC 6476?  While the discussion is = CMS-specific, the algorithm could be used with another = syntax.

 

Russ

 

 

On = Nov 12, 2012, at 1:55 PM, Mike Jones wrote:




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.

 

           &nbs= p;            = ;            =             &= nbsp;           -- = Mike

 

From:=  cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew = (mcgrew)
Sent: Monday, November 12, 2012 = 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated = Encryption with AES-CBC and HMAC-SHA, version = 01

 

Hi,<= o:p>

 

There is a = new version of "Authenticat= ed Encryption with AES-CBC and HMAC-SHA", = and I would = appreciate your review.   It is online at <https://datatracker.ietf.org/doc/draft-mcgrew-a= ead-aes-cbc-hmac-sha2/?include_text=3D1>   The diff = between the current and the previous version is available at <http://www.ietf.org/rfcdiff?url2=3Ddraft-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

_________= ______________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/ma= ilman/listinfo/cfrg

 




_______________________=
________________________
Cfrg mailing =
list
Cfrg@irtf.org
http://www.irtf.org/ma=
ilman/listinfo/cfrg

 

------=_NextPart_000_00B1_01CDC6A4.FB8A6660-- From kmigoe@nsa.gov Tue Nov 20 09:37:10 2012 Return-Path: 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 BA54621F872A for ; Tue, 20 Nov 2012 09:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 NI7WIIF6MMmX for ; Tue, 20 Nov 2012 09:37:07 -0800 (PST) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 028CF21F86C6 for ; Tue, 20 Nov 2012 09:37:03 -0800 (PST) X-TM-IMSS-Message-ID: <0d7f18b40000d934@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 0d7f18b40000d934 ; Tue, 20 Nov 2012 08:13:50 -0500 Received: from MSMR-GH1-UEA02.corp.nsa.gov (10.215.227.180) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 20 Nov 2012 08:10:21 -0500 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA02.corp.nsa.gov ([10.215.227.180]) with mapi id 14.01.0289.001; Tue, 20 Nov 2012 08:10:20 -0500 From: "Igoe, Kevin M." To: 'David Jacobson' , "cfrg@irtf.org" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNxtvg5dRmH42ImUCxpzeefAod4Zfyrl3w Date: Tue, 20 Nov 2012 13:10:19 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17@MSMR-GH1-UEA03.corp.nsa.gov> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> <50AB0E38.9050700@sbcglobal.net> In-Reply-To: <50AB0E38.9050700@sbcglobal.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.254.27] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17MSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 17:37:10 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17MSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll agree with David's position, but for a slightly different reason. A p= acket with a bad MAC may mean the decrypted PT is malicious. Not decrypting CT with a bad MAC cryptograp= hically enforces the policy that questionable packets MUST NOT be released to the receiving user/proces= ses. Misuse of AES-CBC-HMAC-SHA (we really need a shorter name) by a well intent= ioned application programmer is, in my opinion, the larger risk. By never even decrypting questionable = CT there is no chance the programmers will, with the best of intentions, make a security critical mistake by ac= ting upon malicious PT. From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Dav= id Jacobson Sent: Tuesday, November 20, 2012 12:00 AM To: cfrg@irtf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 I think I'd argue the other way on continuing on on when the MAC fails. One big advantage of encrypt-then-MAC is that the receiving end does MACver= ify-then-decrypt. If the message has been tampered with, the MAC fails to = verify and we never even enter the decryption stuff, thus there is never ev= en the possibility of padding oracles, timing attacks, etc. If you go ahea= d with the decryption, you risk revealing something. --David On 11/18/2012 10:44 AM, Tolga Acar wrote: Quick feedback on the draft * Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is c= lear this is not new, but a reuse of an existing padding scheme. * Section 2.2, step 3. When MAC verification fails, the draft recom= mends halting the operation before CBC decryption. We have seen timing and = error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize th= at the draft is prescribing E-t-M. Nonetheless, considering a potential fla= w in HMAC-SHA2 series (I don't know of any, but ...), I'd suggest not halti= ng the operation even after MAC check fails, but continuing on to CBC decry= ption, and then returning an error that doesn't distinguish between a MAC a= nd a decryption (pad check) error. Yes, this would consume more CPU cycles = only to waste them *under an attack*, which is not necessarily bad. * Section 2.2, step 5. Unspecified error case of invalid padding (l= ink to my comment above). Best, - Tolga From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of Russ Housley Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-= specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: 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. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg --_000_3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17MSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll agree with Dav= id’s position, but for a slightly different reason.  A packet wi= th a bad MAC may mean

the decrypted PT is malic= ious.  Not decrypting CT with a bad MAC cryptographically enforces the= policy

that questionable packets= MUST NOT be released to the receiving user/processes. 

 <= /p>

Misuse of AES-CBC-HMAC-SH= A (we really need a shorter name) by a well intentioned application program= mer

is, in my opinion, the la= rger risk.  By never even decrypting questionable CT there is no chanc= e the programmers

will, with the best of in= tentions,   make a security critical mistake by acting upon malic= ious PT.

 <= /p>

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.o= rg] On Behalf Of David Jacobson
Sent: Tuesday, November 20, 2012 12:00 AM
To: cfrg@irtf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01

 

I think I'd argue the other way on continuing on on = when the MAC fails.

One big advantage of encrypt-then-MAC is that the receiving end does MACver= ify-then-decrypt.  If the message has been tampered with, the MAC fail= s to verify and we never even enter the decryption stuff, thus there is nev= er even the possibility of padding oracles, timing attacks, etc.  If you go ahead with the decryption, you risk r= evealing something.

   --David

 

On 11/18/2012 10:44 AM, Tolga Acar wrote:

Quick feedback on the dra= ft

 <= /p>

·         Page 5, item 3, p= adding string PS. Please \cite PKCS#5 so it is clear this is not new, but a= reuse of an existing padding scheme.

·         Section 2.2, step= 3. When MAC verification fails, the draft recommends halting the operation= before CBC decryption. We have seen timing and error-code based attacks against TLS’ MAC-then-Encrypt scheme. I realize that t= he draft is prescribing E-t-M. Nonetheless, considering a potential flaw in= HMAC-SHA2 series (I don’t know of any, but …), I’d sugge= st not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that does= n’t distinguish between a MAC and a decryption (pad check) error. Yes= , this would consume more CPU cycles only to waste them *under an attack= *, which is not necessarily bad.

·         Section 2.2, step= 5. Unspecified error case of invalid padding (link to my comment above).

 <= /p>

Best,

-      &= nbsp;   Tolga=

 <= /p>

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01

 

Have you looked at the algorithm in RFC 6476?  = While the discussion is CMS-specific, the algorithm could be used with anot= her syntax.

 

Russ

 

 

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:<= /o:p>




As background, if there w= as 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 b= etter match for JOSE’s use case.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: cfrg-bounces@irtf.org [mailt= o:cfrg-bounces@irtf.org] On Behalf Of David McGr= ew (mcgrew)
Sent: Monday, Nove= mber 12, 2012 10:21 AM
To: cfrg@irtf.org;=  jose@ietf.org
Subject: [Cfrg] Au= thenticated 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 you= r review.   It is online at <https://dat= atracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=3D1= >   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-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 co= rrespond 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 confi= rmation.  

 

Thanks,

 

David

_____________________________________= __________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/m= ailman/listinfo/cfrg

 




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.=
org/mailman/listinfo/cfrg

 

--_000_3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17MSMRGH1UEA03cor_-- From mcgrew@cisco.com Tue Nov 20 12:53:24 2012 Return-Path: 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 AD3B221F8817 for ; Tue, 20 Nov 2012 12:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 iFUK+P1uvH6v for ; Tue, 20 Nov 2012 12:53:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88421F8810 for ; Tue, 20 Nov 2012 12:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32136; q=dns/txt; s=iport; t=1353444803; x=1354654403; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xFY7HmrGM7VFLRBFnrDY8hs6RD12q0Or9QD3bGRxB7A=; b=fZayJEVJy9WbsbSRRZGoM8eb1LaXM0TsBgF1Q9ngfdJ59vTfkM+hoHJd 7/cFbhIM83w+t/wGaAIRbimgGGfhNIvuo7oiL0+vgHSBXNMYooo8WTa9y cvdo/0mXfnr5aQ/K7hlfxVkl9HyKKtTZzsCLcsnAky7mmX7kW+h1lRyvT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFAJLsq1CtJXG+/2dsb2JhbABEgkmtfokGAYkNFnOCHgEBAQQBAQEqQQsSAQgOAwMBAQELFgEGLgsUCQgCBAENBQgBh3IDDwuvD4ZdBYlcjDUag3phA5cajyWCb4FkFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144547891" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 20 Nov 2012 20:53:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAKKrMKs011246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 20:53:22 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.108]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 14:53:22 -0600 From: "David McGrew (mcgrew)" To: Tolga Acar , "'Russ Housley'" , "'Mike Jones'" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNx2ETlyAzLxb67Eq9P0wOuMXhUQ== Date: Tue, 20 Nov 2012 20:53:21 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F538AF7@xmb-rcd-x04.cisco.com> In-Reply-To: <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F538AF7xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: 'IRTF CFRG' , "jose@ietf.org" Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:53:24 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F538AF7xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tolga, Thanks for the comments, more inline: From: Tolga Acar > Date: Sunday, November 18, 2012 1:44 PM To: 'Russ Housley' >, 'Mi= ke Jones' > Cc: 'IRTF CFRG' >, "jose@ietf.org" > Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Quick feedback on the draft =B7 Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is= clear this is not new, but a reuse of an existing padding scheme. It makes sense to add a citation, but in Section 4 (Rationale), where PEM a= nd PKCS padding are already mentioned. The right citation seems to be to = add these non-normative references: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, = Modes, and Identifiers - RFC 1423 PKCS #7: Cryptographic Message Syntax v1.5 =96 RFC 2315 Cryptographic Message Syntax (CMS) - RFC 5652 =B7 Section 2.2, step 3. When MAC verification fails, the draft rec= ommends halting the operation before CBC decryption. We have seen timing an= d error-code based attacks against TLS=92 MAC-then-Encrypt scheme. I realiz= e that the draft is prescribing E-t-M. Nonetheless, considering a potential= flaw in HMAC-SHA2 series (I don=92t know of any, but =85), I=92d suggest n= ot halting the operation even after MAC check fails, but continuing on to C= BC decryption, and then returning an error that doesn=92t distinguish betwe= en a MAC and a decryption (pad check) error. Yes, this would consume more C= PU cycles only to waste them *under an attack*, which is not necessarily ba= d. Your suggestion aims to hide from an attacker whether or not the authentica= tion check passed or failed, by removing the (significant) timing differenc= e in whether decryption is performed or not. I don't see what security adv= antage this provides. In many scenarios an attacker could tell whether or= not a message was accepted anyway, by observing that the receiver acted on= that message. =B7 Section 2.2, step 5. Unspecified error case of invalid padding = (link to my comment above). The draft does consider invalid padding, and takes a conservative in what y= ou send, liberal in what you accept policy. The sender is required to use= PKCS/PEM style padding, but the receiver is only told to consider the fina= l octet of the padding (which is the only octet that matters). The Step y= ou mention says: = If the final octet has a value outside that range, then all of the data used in the processing of the message is zeroized and discarded, and the AEAD decryption operation returns an indication that it failed, and the operation halts. This could be amended by saying that "If the padding string does not have t= he form described in Step 3, the message MAY be rejected". I think that the liberal-in-what-you-accept policy is the best option here,= but I could be convinced otherwise. The citations for padding schemes me= ntioned earlier are silent on this issue. David Best, - Tolga From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of Russ Housley Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-= specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: 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=92s use case. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on 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 t= he 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 af= ter I get confirmation. Thanks, David _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg --_000_747787E65E3FBD4E93F0EB2F14DB556B0F538AF7xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Tolga,

Thanks for the comments, more inline:

From: Tolga Acar <t.acar@att.net>
Date: Sunday, November 18, 2012 1:4= 4 PM
To: 'Russ Housley' <housley@vigilsec.com>, 'Mike Jones' <= Michael.Jones@microsoft.com<= /a>>
Cc: 'IRTF CFRG' <cfrg@irtf.org>, "jose@ietf.org" <jose@ietf= .org>
Subject: Re: [Cfrg] Authenticated E= ncryption with AES-CBC and HMAC-SHA, version 01

Quick feedback on the draft

 

=B7       &= nbsp; Page 5, item 3, paddin= g string PS. Please \cite PKCS#5 so it is clear this is not new, but a reus= e of an existing padding scheme.

It makes sense to add a citation, but in Section 4 (Rationale), where = PEM and PKCS padding are already mentioned.   The right citation seems= to be to add these non-normative references:

   Privacy Enhancement for Internet Electronic Mail: Pa= rt III: Algorithms, Modes, and Identifiers  - RFC 1423
   PKCS #7: Cryptographic Message Syntax v1.5 =96 RFC 231= 5
   Cryptographic Message Syntax (CMS) - RFC 5652

=B7       &= nbsp; Section 2.2, step 3. W= hen MAC verification fails, the draft recommends halting the operation befo= re CBC decryption. We have seen timing and error-code based attacks against TLS=92 MAC-then-Encrypt scheme. I rea= lize that the draft is prescribing E-t-M. Nonetheless, considering a potent= ial flaw in HMAC-SHA2 series (I don=92t know of any, but =85), I=92d sugges= t not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an er= ror that doesn=92t distinguish between a MAC and a decryption (pad check) e= rror. Yes, this would consume more CPU cycles only to waste them *under = an attack*, which is not necessarily bad.

Your suggestion aims to hide from an attacker whether or not the authe= ntication check passed or failed, by removing the (significant) timing diff= erence in whether decryption is performed or not.  I don't see what se= curity advantage this provides.   In many scenarios an attacker could tell whether or not a message was accepte= d anyway, by observing that the receiver acted on that message.  

=B7       &= nbsp; Section 2.2, step 5. U= nspecified error case of invalid padding (link to my comment above).

The draft does consider invalid padding, and takes a conservative in w= hat you send, liberal in what you accept policy.   The sender is requi= red to use PKCS/PEM style padding, but the receiver is only told to conside= r the final octet of the padding (which is the only octet that matters).   The Step you mention says:

                    =                      = ;                     &nb= sp;            If the final octet has
       a value outside that range, then all of the= data used in the
       processing of the message is zeroized and d= iscarded, and the AEAD
       decryption operation returns an indication = that it failed, and
       the operation halts.

This could be amended by saying that "If the padding string does = not have the form described in Step 3, the message MAY be rejected".

I think that the liberal-in-what-you-accept policy is the best option = here, but I could be convinced otherwise.   The citations for padding = schemes mentioned earlier are silent on this issue.  

David

 

Best,

-&n= bsp;         Tolga

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01

 

Have you looked at the algorithm in RFC 6476?  = While the discussion is CMS-specific, the algorithm could be used with anot= her syntax.

 

Russ

 

 

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:<= /o:p>



As background, if there was a vers= ion of this spec that did not assume that the parameters would be concatena= ted 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=92s use case.

 

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGr= ew (mcgrew)
Sent: Monday, Nove= mber 12, 2012 10:21 AM
To: cfrg@irtf.org;=  jose@ietf.org
Subject: [Cfrg] Au= thenticated 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 https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hma= c-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been proposed for use in the= JOSE WG <http://dat= atracker.ietf.org/wg/jose/> , where its adoption would allow the working group to omit "raw" unauthentic= ated encryption, e.g. AES-CBC, and only include authenticated encryption. &= nbsp; Thus I am asking for your help in making 

 

John Foley generated test cases that corres= pond 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 ge= t confirmation.  

 

Thanks,

 

David

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/m= ailman/listinfo/cfrg

 

 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F538AF7xmbrcdx04ciscoc_-- From James.H.Manger@team.telstra.com Tue Nov 20 17:32:37 2012 Return-Path: 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 AB7E821F873A for ; Tue, 20 Nov 2012 17:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 l8RN4qcjA3v6 for ; Tue, 20 Nov 2012 17:32:36 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04221F872E for ; Tue, 20 Nov 2012 17:32:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,290,1352034000"; d="scan'208,217";a="102349744" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 21 Nov 2012 12:32:31 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="94034603" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdni.tcif.telstra.com.au with ESMTP; 21 Nov 2012 12:32:31 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 21 Nov 2012 12:32:30 +1100 From: "Manger, James H" To: "David McGrew (mcgrew)" , 'IRTF CFRG' , Tolga Acar Date: Wed, 21 Nov 2012 12:32:22 +1100 Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNx2ETlyAzLxb67Eq9P0wOuMXhUZfzWrow Message-ID: <255B9BB34FB7D647A506DC292726F6E115009143A4@WSMSG3153V.srv.dir.telstra.com> References: <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> <747787E65E3FBD4E93F0EB2F14DB556B0F538AF7@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F538AF7@xmb-rcd-x04.cisco.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_255B9BB34FB7D647A506DC292726F6E115009143A4WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [Cfrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 01:32:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115009143A4WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIHR3byByaXNrczoNCg0KMS4gICAgICAgVGhlIENCQyBwYWRkaW5nIGlzIHByb2Nl c3NlZCBiZWZvcmUgdGhlIE1BQyBpcyB2ZXJpZmllZA0KDQoyLiAgICAgICBUaGUgcGxhaW50ZXh0 IGlzIHVzZWQgYmVmb3JlIHRoZSBNQUMgaXMgdmVyaWZpZWQNCg0KVGhlIGRyYWZ0IGNvdWxkIG1h a2UgdGhlIENCQyBwYWRkaW5nIHByb2Nlc3NpbmcgZXZlbiBzYWZlciBieSBiZWluZyBldmVuIG1v cmUgbGVuaWVudDogb25seSBjb25zaWRlciB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgNCBiaXRzIG9m IHRoZSBsYXN0IGJ5dGUgKGllIG1vZHVsbyB0aGUgYmxvY2sgbGVuZ3RoKS4gVGhhdCBpcyBndWFy YW50ZWVkIHRvIGJlIGluIFswLDE1XSBzbyBpdCBhbHdheXMgZ2l2ZXMgYSB2YWxpZCBwYWRkaW5n IGxlbmd0aCAoMCBtZWFucyAxNiBieXRlcyBvZiBwYWRkaW5nKS4gU3VjaCBwYWRkaW5nIHByb2Nl c3NpbmcgY2FuIG5ldmVyIGZhaWwgc28gaXQgY2FuIG5ldmVyIGFjdCBhcyBhIHBhZGRpbmcgb3Jh Y2xlIGV2ZW4gaWYgaXQgaXMgYWNjaWRlbnRhbGx5IHBlcmZvcm1lZCBiZWZvcmUgdGhlIHByb3Bl ciBNQUMgaW50ZWdyaXR5IGNoZWNrLg0KDQpNaW5kIHlvdSwgSSB3b3VsZCBleHBlY3QgbWFueSBp bXBsZW1lbnRhdGlvbnMgdG8gdXNlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBmb3IgdGhlIHBh ZGRpbmcgdGhhdCB3aWxsIG5vdCBiZSBjaGFuZ2VkIHRvIGJlIGxlbmllbnQuIEhlbmNlIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzaG91bGQgc2F5IHRoYXQgaXQgaXMgY3J1Y2lhbCB0aGF0 IHRoZSBNQUMgaXMgdmVyaWZpZWQgYmVmb3JlIHRoZSBDQkMgcGFkZGluZyBpcyBwcm9jZXNzZWQu DQoNCg0KSWYgeW91IG9wZXJhdGUgaW4gYSBzdHJlYW1pbmcgbW9kZSAoaWUgeW91IGRvbuKAmXQg d2FudCB0byBidWZmZXIgdGhlIHdob2xlIGNpcGhlcnRleHQgYmVmb3JlIG91dHB1dHRpbmcgYW55 dGhpbmcpIHRoZW4gY29ycnVwdGVkIHBsYWludGV4dCBjYW4gYmUgcHJvZHVjZWQsIGFuZCBhIE1B QyBmYWlsdXJlIHdpbGwgb25seSBiZSByZXBvcnRlZCBsYXRlciAob3IgbmV2ZXIsIGlmIHRoZSBl bmQgb2YgdGhlIGNpcGhlcnRleHQgaXMgbmV2ZXIgcmVjZWl2ZWQpLiBkcmFmdC1tY2dyZXctYWVh ZC1hZXMtY2JjLWhtYWMtc2hhMi0wMSDigJxwcmV2ZW50c+KAnSB0aGlzIGJ5IHBlcmZvcm1pbmcg dGhlIE1BQyB2ZXJpZmljYXRpb24gKHN0ZXAgMykgYmVmb3JlIHRoZSBkZWNyeXB0aW9uIChzdGVw IDQpLCBidXQgdGhhdCBvcmRlcmluZyB3aWxsIGJlIGlnbm9yZWQgYnkgQVBJcyB0aGF0IHN1cHBv cnQgc3RyZWFtaW5nLg0KDQpJbiBKYXZhLCBmb3IgaW5zdGFuY2UsIHRoZSBDaXBoZXIgY2xhc3Mg aGFzIGFuIHVwZGF0ZShCeXRlQnVmZmVyIGlucHV0LCBCeXRlQnVmZmVyIG91dHB1dCkgbWV0aG9k cyB0aGF0IGNhbiBiZSBjYWxsZWQgYW55IG51bWJlciBvZiB0aW1lcyAob3V0cHV0dGluZyBwbGFp bnRleHQpIGJlZm9yZSBjYWxsaW5nIGRvRmluYWwoLi4uKSwgYXQgd2hpY2ggcG9pbnQgYW4gZXhj ZXB0aW9uIGlzIHRocm93biBpZiB0aGUgaW50ZWdyaXR5IGNoZWNrIGZhaWxzLiBBcyBhbiBleGFt cGxlLCB0aGUgQm91bmN5Q2FzdGxlIGltcGxlbWVudGF0aW9uIG9mIEFFUy9HQ00vTm9QYWRkaW5n IGRlY3J5cHRpb24gcmV0dXJucyBwbGFpbnRleHQgZnJvbSB0aGUgdXBkYXRlKC4uLikgY2FsbHM7 IGl0IGRvZXMgbm90IGJ1ZmZlciB0aGUgcGxhaW50ZXh0IHVudGlsIHRoZSBpbnRlZ3JpdHkgY2hl Y2sgaW4gdGhlIGRvRmluYWwoLi4uKSBjYWxsLg0KDQpUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbiBoaW50cyBhdCB0aGlzIGlzc3VlIGJ5IHRhbGtpbmcgYWJvdXQgYSDigJxzaW5n bGUgYXRvbWljIG9wZXJhdGlvbuKAnToNCiAgIFRoZXJlIGFyZSBzZWN1cml0eSBiZW5lZml0cyB0 byBwcm92aWRpbmcgYm90aCBjb25maWRlbnRpYWxpdHkgYW5kDQogICBhdXRoZW50aWNhdGlvbiBp biBhIHNpbmdsZSBhdG9taWMgb3BlcmF0aW9uLCBhcyBkb25lIGluIHRoaXMgbm90ZS4NCiAgIFRo aXMgdGlnaHQgYmluZGluZyBwcmV2ZW50cyBzdWJ0bGUgYXR0YWNrcyBzdWNoIGFzIHRoZSBwYWRk aW5nIG9yYWNsZQ0KICAgYXR0YWNrLg0KUGVyaGFwcyBhZGQgdGhhdCDigJx3aGlsZSBhIHN0cmVh bWluZyBpbXBsZW1lbnRhdGlvbiBvZiBkZWNyeXB0aW9uIGNhbiBjYWxjdWxhdGUgc29tZSBwbGFp bnRleHQgYmVmb3JlIGFsbCB0aGUgY2lwaGVydGV4dCBoYXMgYmVlbiBwcm9jZXNzZWQsIHRoZSBh dXRoZW50aWNpdHkgaXMgbm90IGVuc3VyZWQgdW50aWwgYWxsIHRoZSBjaXBoZXJ0ZXh0IGhhcyBi ZWVuIHByb2Nlc3NlZOKAnS4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KDQrCtyAgICAgICAg IFNlY3Rpb24gMi4yLCBzdGVwIDMuIFdoZW4gTUFDIHZlcmlmaWNhdGlvbiBmYWlscywgdGhlIGRy YWZ0IHJlY29tbWVuZHMgaGFsdGluZyB0aGUgb3BlcmF0aW9uIGJlZm9yZSBDQkMgZGVjcnlwdGlv bi4gV2UgaGF2ZSBzZWVuIHRpbWluZyBhbmQgZXJyb3ItY29kZSBiYXNlZCBhdHRhY2tzIGFnYWlu c3QgVExT4oCZIE1BQy10aGVuLUVuY3J5cHQgc2NoZW1lLiBJIHJlYWxpemUgdGhhdCB0aGUgZHJh ZnQgaXMgcHJlc2NyaWJpbmcgRS10LU0uIE5vbmV0aGVsZXNzLCBjb25zaWRlcmluZyBhIHBvdGVu dGlhbCBmbGF3IGluIEhNQUMtU0hBMiBzZXJpZXMgKEkgZG9u4oCZdCBrbm93IG9mIGFueSwgYnV0 IOKApiksIEnigJlkIHN1Z2dlc3Qgbm90IGhhbHRpbmcgdGhlIG9wZXJhdGlvbiBldmVuIGFmdGVy IE1BQyBjaGVjayBmYWlscywgYnV0IGNvbnRpbnVpbmcgb24gdG8gQ0JDIGRlY3J5cHRpb24sIGFu ZCB0aGVuIHJldHVybmluZyBhbiBlcnJvciB0aGF0IGRvZXNu4oCZdCBkaXN0aW5ndWlzaCBiZXR3 ZWVuIGEgTUFDIGFuZCBhIGRlY3J5cHRpb24gKHBhZCBjaGVjaykgZXJyb3IuIFllcywgdGhpcyB3 b3VsZCBjb25zdW1lIG1vcmUgQ1BVIGN5Y2xlcyBvbmx5IHRvIHdhc3RlIHRoZW0gKnVuZGVyIGFu IGF0dGFjayosIHdoaWNoIGlzIG5vdCBuZWNlc3NhcmlseSBiYWQuDQoNCllvdXIgc3VnZ2VzdGlv biBhaW1zIHRvIGhpZGUgZnJvbSBhbiBhdHRhY2tlciB3aGV0aGVyIG9yIG5vdCB0aGUgYXV0aGVu dGljYXRpb24gY2hlY2sgcGFzc2VkIG9yIGZhaWxlZCwgYnkgcmVtb3ZpbmcgdGhlIChzaWduaWZp Y2FudCkgdGltaW5nIGRpZmZlcmVuY2UgaW4gd2hldGhlciBkZWNyeXB0aW9uIGlzIHBlcmZvcm1l ZCBvciBub3QuICBJIGRvbid0IHNlZSB3aGF0IHNlY3VyaXR5IGFkdmFudGFnZSB0aGlzIHByb3Zp ZGVzLiAgIEluIG1hbnkgc2NlbmFyaW9zIGFuIGF0dGFja2VyIGNvdWxkIHRlbGwgd2hldGhlciBv ciBub3QgYSBtZXNzYWdlIHdhcyBhY2NlcHRlZCBhbnl3YXksIGJ5IG9ic2VydmluZyB0aGF0IHRo ZSByZWNlaXZlciBhY3RlZCBvbiB0aGF0IG1lc3NhZ2UuDQoNCg0KwrcgICAgICAgICBTZWN0aW9u IDIuMiwgc3RlcCA1LiBVbnNwZWNpZmllZCBlcnJvciBjYXNlIG9mIGludmFsaWQgcGFkZGluZyAo bGluayB0byBteSBjb21tZW50IGFib3ZlKS4NCg0KVGhlIGRyYWZ0IGRvZXMgY29uc2lkZXIgaW52 YWxpZCBwYWRkaW5nLCBhbmQgdGFrZXMgYSBjb25zZXJ2YXRpdmUgaW4gd2hhdCB5b3Ugc2VuZCwg bGliZXJhbCBpbiB3aGF0IHlvdSBhY2NlcHQgcG9saWN5LiAgIFRoZSBzZW5kZXIgaXMgcmVxdWly ZWQgdG8gdXNlIFBLQ1MvUEVNIHN0eWxlIHBhZGRpbmcsIGJ1dCB0aGUgcmVjZWl2ZXIgaXMgb25s eSB0b2xkIHRvIGNvbnNpZGVyIHRoZSBmaW5hbCBvY3RldCBvZiB0aGUgcGFkZGluZyAod2hpY2gg aXMgdGhlIG9ubHkgb2N0ZXQgdGhhdCBtYXR0ZXJzKS4gICBUaGUgU3RlcCB5b3UgbWVudGlvbiBz YXlzOg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBJZiB0aGUgZmluYWwgb2N0ZXQgaGFzDQogICAgICAg YSB2YWx1ZSBvdXRzaWRlIHRoYXQgcmFuZ2UsIHRoZW4gYWxsIG9mIHRoZSBkYXRhIHVzZWQgaW4g dGhlDQogICAgICAgcHJvY2Vzc2luZyBvZiB0aGUgbWVzc2FnZSBpcyB6ZXJvaXplZCBhbmQgZGlz Y2FyZGVkLCBhbmQgdGhlIEFFQUQNCiAgICAgICBkZWNyeXB0aW9uIG9wZXJhdGlvbiByZXR1cm5z IGFuIGluZGljYXRpb24gdGhhdCBpdCBmYWlsZWQsIGFuZA0KICAgICAgIHRoZSBvcGVyYXRpb24g aGFsdHMuDQoNClRoaXMgY291bGQgYmUgYW1lbmRlZCBieSBzYXlpbmcgdGhhdCAiSWYgdGhlIHBh ZGRpbmcgc3RyaW5nIGRvZXMgbm90IGhhdmUgdGhlIGZvcm0gZGVzY3JpYmVkIGluIFN0ZXAgMywg dGhlIG1lc3NhZ2UgTUFZIGJlIHJlamVjdGVkIi4NCg0KSSB0aGluayB0aGF0IHRoZSBsaWJlcmFs LWluLXdoYXQteW91LWFjY2VwdCBwb2xpY3kgaXMgdGhlIGJlc3Qgb3B0aW9uIGhlcmUsIGJ1dCBJ IGNvdWxkIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuICAgVGhlIGNpdGF0aW9ucyBmb3IgcGFkZGlu ZyBzY2hlbWVzIG1lbnRpb25lZCBlYXJsaWVyIGFyZSBzaWxlbnQgb24gdGhpcyBpc3N1ZS4NCg0K RGF2aWQNCg== --_000_255B9BB34FB7D647A506DC292726F6E115009143A4WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0K CW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZl cnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNTIzODc1Mjk7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzcwODIyMzA0 IDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2 NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2MDk1ODMw MDQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1NTQ5 NjQzNjggLTU3NDQ4NzA4MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6MTkwMDMxNDE4MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTExNTczNTQwNTIgLTI0ODYzOTg4NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBs aW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxlPSd3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2Un PjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlRoZXJlIGFyZSB0d28gcmlza3M6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzUnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRo ZSBDQkMgcGFkZGluZyBpcyBwcm9jZXNzZWQgYmVmb3JlIHRoZSBNQUMgaXMgdmVyaWZpZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNSc+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4y LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHBsYWludGV4dCBpcyB1c2VkIGJlZm9yZSB0aGUgTUFD IGlzIHZlcmlmaWVkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZHJhZnQgY291bGQgbWFrZSB0aGUg Q0JDIHBhZGRpbmcgcHJvY2Vzc2luZyBldmVuIHNhZmVyIGJ5IGJlaW5nIGV2ZW4gbW9yZSBsZW5p ZW50OiBvbmx5IGNvbnNpZGVyIHRoZSBsZWFzdCBzaWduaWZpY2FudCA0IGJpdHMgb2YgdGhlIGxh c3QgYnl0ZSAoaWUgbW9kdWxvIHRoZSBibG9jayBsZW5ndGgpLiBUaGF0IGlzIGd1YXJhbnRlZWQg dG8gYmUgaW4gWzAsMTVdIHNvIGl0IGFsd2F5cyBnaXZlcyBhIHZhbGlkIHBhZGRpbmcgbGVuZ3Ro ICgwIG1lYW5zIDE2IGJ5dGVzIG9mIHBhZGRpbmcpLiBTdWNoIHBhZGRpbmcgcHJvY2Vzc2luZyBj YW4gbmV2ZXIgZmFpbCBzbyBpdCBjYW4gbmV2ZXIgYWN0IGFzIGEgcGFkZGluZyBvcmFjbGUgZXZl biBpZiBpdCBpcyBhY2NpZGVudGFsbHkgcGVyZm9ybWVkIGJlZm9yZSB0aGUgcHJvcGVyIE1BQyBp bnRlZ3JpdHkgY2hlY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NaW5kIHlvdSwgSSB3b3VsZCBleHBl Y3QgbWFueSBpbXBsZW1lbnRhdGlvbnMgdG8gdXNlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBm b3IgdGhlIHBhZGRpbmcgdGhhdCB3aWxsIG5vdCBiZSBjaGFuZ2VkIHRvIGJlIGxlbmllbnQuIEhl bmNlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzaG91bGQgc2F5IHRoYXQgaXQgaXMgY3J1 Y2lhbCB0aGF0IHRoZSBNQUMgaXMgdmVyaWZpZWQgYmVmb3JlIHRoZSBDQkMgcGFkZGluZyBpcyBw cm9jZXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgeW91IG9wZXJhdGUg aW4gYSBzdHJlYW1pbmcgbW9kZSAoaWUgeW91IGRvbuKAmXQgd2FudCB0byBidWZmZXIgdGhlIHdo b2xlIGNpcGhlcnRleHQgYmVmb3JlIG91dHB1dHRpbmcgYW55dGhpbmcpIHRoZW4gY29ycnVwdGVk IHBsYWludGV4dCBjYW4gYmUgcHJvZHVjZWQsIGFuZCBhIE1BQyBmYWlsdXJlIHdpbGwgb25seSBi ZSByZXBvcnRlZCBsYXRlciAob3IgbmV2ZXIsIGlmIHRoZSBlbmQgb2YgdGhlIGNpcGhlcnRleHQg aXMgbmV2ZXIgcmVjZWl2ZWQpLiBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMi0w MSDigJxwcmV2ZW50c+KAnSB0aGlzIGJ5IHBlcmZvcm1pbmcgdGhlIE1BQyB2ZXJpZmljYXRpb24g KHN0ZXAgMykgYmVmb3JlIHRoZSBkZWNyeXB0aW9uIChzdGVwIDQpLCBidXQgdGhhdCBvcmRlcmlu ZyB3aWxsIGJlIGlnbm9yZWQgYnkgQVBJcyB0aGF0IHN1cHBvcnQgc3RyZWFtaW5nLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SW4gSmF2YSwgZm9yIGluc3RhbmNlLCB0aGUgQ2lwaGVyIGNsYXNzIGhhcyBh biB1cGRhdGUoQnl0ZUJ1ZmZlciBpbnB1dCwgQnl0ZUJ1ZmZlciBvdXRwdXQpIG1ldGhvZHMgdGhh dCBjYW4gYmUgY2FsbGVkIGFueSBudW1iZXIgb2YgdGltZXMgKG91dHB1dHRpbmcgcGxhaW50ZXh0 KSBiZWZvcmUgY2FsbGluZyBkb0ZpbmFsKC4uLiksIGF0IHdoaWNoIHBvaW50IGFuIGV4Y2VwdGlv biBpcyB0aHJvd24gaWYgdGhlIGludGVncml0eSBjaGVjayBmYWlscy4gQXMgYW4gZXhhbXBsZSwg dGhlIEJvdW5jeUNhc3RsZSBpbXBsZW1lbnRhdGlvbiBvZiBBRVMvR0NNL05vUGFkZGluZyBkZWNy eXB0aW9uIHJldHVybnMgcGxhaW50ZXh0IGZyb20gdGhlIHVwZGF0ZSguLi4pIGNhbGxzOyBpdCBk b2VzIG5vdCBidWZmZXIgdGhlIHBsYWludGV4dCB1bnRpbCB0aGUgaW50ZWdyaXR5IGNoZWNrIGlu IHRoZSBkb0ZpbmFsKC4uLikgY2FsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGhpbnRzIGF0IHRoaXMgaXNzdWUgYnkgdGFsa2luZyBhYm91 dCBhIOKAnHNpbmdsZSBhdG9taWMgb3BlcmF0aW9u4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPsKgwqAgVGhlcmUg YXJlIHNlY3VyaXR5IGJlbmVmaXRzIHRvIHByb3ZpZGluZyBib3RoIGNvbmZpZGVudGlhbGl0eSBh bmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOmJsYWNrJz7CoMKgIGF1dGhlbnRpY2F0aW9uIGluIGEgc2luZ2xlIGF0b21pYyBvcGVy YXRpb24sIGFzIGRvbmUgaW4gdGhpcyBub3RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPsKgwqAgVGhpcyB0aWdodCBi aW5kaW5nIHByZXZlbnRzIHN1YnRsZSBhdHRhY2tzIHN1Y2ggYXMgdGhlIHBhZGRpbmcgb3JhY2xl PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ncGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+wqDCoCBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBlcmhhcHMgYWRkIHRoYXQg4oCcd2hpbGUg YSBzdHJlYW1pbmcgaW1wbGVtZW50YXRpb24gb2YgZGVjcnlwdGlvbiBjYW4gY2FsY3VsYXRlIHNv bWUgcGxhaW50ZXh0IGJlZm9yZSBhbGwgdGhlIGNpcGhlcnRleHQgaGFzIGJlZW4gcHJvY2Vzc2Vk LCB0aGUgYXV0aGVudGljaXR5IGlzIG5vdCBlbnN1cmVkIHVudGlsIGFsbCB0aGUgY2lwaGVydGV4 dCBoYXMgYmVlbiBwcm9jZXNzZWTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxi bG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1y aWdodDowY20nIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5TZWN0aW9uIDIuMiwgc3RlcCAzLiBXaGVuIE1BQyB2ZXJpZmljYXRpb24gZmFpbHMsIHRo ZSBkcmFmdCByZWNvbW1lbmRzIGhhbHRpbmcgdGhlIG9wZXJhdGlvbiBiZWZvcmUgQ0JDIGRlY3J5 cHRpb24uIFdlIGhhdmUgc2VlbiB0aW1pbmcgYW5kIGVycm9yLWNvZGUgYmFzZWQgYXR0YWNrcyBh Z2FpbnN0IFRMU+KAmSBNQUMtdGhlbi1FbmNyeXB0IHNjaGVtZS4gSSByZWFsaXplIHRoYXQgdGhl IGRyYWZ0IGlzIHByZXNjcmliaW5nIEUtdC1NLiBOb25ldGhlbGVzcywgY29uc2lkZXJpbmcgYSBw b3RlbnRpYWwgZmxhdyBpbiBITUFDLVNIQTIgc2VyaWVzIChJIGRvbuKAmXQga25vdyBvZiBhbnks IGJ1dCDigKYpLCBJ4oCZZCBzdWdnZXN0IG5vdCBoYWx0aW5nIHRoZSBvcGVyYXRpb24gZXZlbiBh ZnRlciBNQUMgY2hlY2sgZmFpbHMsIGJ1dCBjb250aW51aW5nIG9uIHRvIENCQyBkZWNyeXB0aW9u LCBhbmQgdGhlbiByZXR1cm5pbmcgYW4gZXJyb3IgdGhhdCBkb2VzbuKAmXQgZGlzdGluZ3Vpc2gg YmV0d2VlbiBhIE1BQyBhbmQgYSBkZWNyeXB0aW9uIChwYWQgY2hlY2spIGVycm9yLiBZZXMsIHRo aXMgd291bGQgY29uc3VtZSBtb3JlIENQVSBjeWNsZXMgb25seSB0byB3YXN0ZSB0aGVtICo8Yj51 bmRlciBhbiBhdHRhY2s8L2I+Kiwgd2hpY2ggaXMgbm90IG5lY2Vzc2FyaWx5IGJhZC48L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPllvdXIgc3VnZ2VzdGlvbiBhaW1z IHRvIGhpZGUgZnJvbSBhbiBhdHRhY2tlciB3aGV0aGVyIG9yIG5vdCB0aGUgYXV0aGVudGljYXRp b24gY2hlY2sgcGFzc2VkIG9yIGZhaWxlZCwgYnkgcmVtb3ZpbmcgdGhlIChzaWduaWZpY2FudCkg dGltaW5nIGRpZmZlcmVuY2UgaW4gd2hldGhlciBkZWNyeXB0aW9uIGlzIHBlcmZvcm1lZCBvciBu b3QuICZuYnNwO0kgZG9uJ3Qgc2VlIHdoYXQgc2VjdXJpdHkgYWR2YW50YWdlIHRoaXMgcHJvdmlk ZXMuICZuYnNwOyBJbiBtYW55IHNjZW5hcmlvcyBhbiBhdHRhY2tlciBjb3VsZCB0ZWxsIHdoZXRo ZXIgb3Igbm90IGEgbWVzc2FnZSB3YXMgYWNjZXB0ZWQgYW55d2F5LCBieSBvYnNlcnZpbmcgdGhh dCB0aGUgcmVjZWl2ZXIgYWN0ZWQgb24gdGhhdCBtZXNzYWdlLiAmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20nIGlkPSJNQUNf T1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEg bGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1m YW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7C tzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TZWN0aW9uIDIuMiwg c3RlcCA1LiBVbnNwZWNpZmllZCBlcnJvciBjYXNlIG9mIGludmFsaWQgcGFkZGluZyAobGluayB0 byBteSBjb21tZW50IGFib3ZlKS48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPlRoZSBkcmFmdCBkb2VzIGNvbnNpZGVyIGludmFsaWQgcGFkZGluZywgYW5kIHRha2Vz IGEgY29uc2VydmF0aXZlIGluIHdoYXQgeW91IHNlbmQsIGxpYmVyYWwgaW4gd2hhdCB5b3UgYWNj ZXB0IHBvbGljeS4gJm5ic3A7IFRoZSBzZW5kZXIgaXMgcmVxdWlyZWQgdG8gdXNlIFBLQ1MvUEVN IHN0eWxlIHBhZGRpbmcsIGJ1dCB0aGUgcmVjZWl2ZXIgaXMgb25seSB0b2xkIHRvIGNvbnNpZGVy IHRoZSBmaW5hbCBvY3RldCBvZiB0aGUgcGFkZGluZyAod2hpY2ggaXMgdGhlIG9ubHkgb2N0ZXQg dGhhdCBtYXR0ZXJzKS4gJm5ic3A7IFRoZSBTdGVwIHlvdSBtZW50aW9uIHNheXM6PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtJZiB0aGUgZmluYWwgb2N0ZXQgaGFzPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2EgdmFsdWUgb3V0c2lkZSB0aGF0IHJhbmdlLCB0aGVuIGFs bCBvZiB0aGUgZGF0YSB1c2VkIGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtwcm9jZXNzaW5nIG9mIHRoZSBtZXNzYWdlIGlzIHplcm9pemVkIGFuZCBkaXNj YXJkZWQsIGFuZCB0aGUgQUVBRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtkZWNyeXB0aW9uIG9wZXJhdGlvbiByZXR1cm5zIGFuIGluZGljYXRpb24gdGhhdCBpdCBm YWlsZWQsIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUg b3BlcmF0aW9uIGhhbHRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+VGhpcyBjb3VsZCBiZSBhbWVuZGVkIGJ5IHNheWluZyB0aGF0ICZxdW90O0lmIHRoZSBwYWRk aW5nIHN0cmluZyBkb2VzIG5vdCBoYXZlIHRoZSBmb3JtIGRlc2NyaWJlZCBpbiBTdGVwIDMsIHRo ZSBtZXNzYWdlIE1BWSBiZSByZWplY3RlZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkkgdGhpbmsgdGhhdCB0aGUgbGliZXJhbC1pbi13aGF0LXlvdS1hY2NlcHQg cG9saWN5IGlzIHRoZSBiZXN0IG9wdGlvbiBoZXJlLCBidXQgSSBjb3VsZCBiZSBjb252aW5jZWQg b3RoZXJ3aXNlLiAmbmJzcDsgVGhlIGNpdGF0aW9ucyBmb3IgcGFkZGluZyBzY2hlbWVzIG1lbnRp b25lZCBlYXJsaWVyIGFyZSBzaWxlbnQgb24gdGhpcyBpc3N1ZS4gJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5EYXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E115009143A4WSMSG3153Vsrv_-- From benl@google.com Wed Nov 21 07:47:20 2012 Return-Path: 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 ; 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 ; 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 ; Wed, 21 Nov 2012 07:47:19 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id 12so3408922wgr.19 for ; 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: References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> Date: Wed, 21 Nov 2012 15:47:18 +0000 Message-ID: From: Ben Laurie To: Michael Jones 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:47:20 -0000 On 12 November 2012 20:25, Michael Jones wrot= e: > > OK, I admit that the way I phrased my request may not be exactly in line > with the way the =93AEAD=94 terminology is used. I can correct that. Tha= t=92s > syntax. I was using =93AEAD=94 as a shorthand for the working group=92s = decision > to use only authenticated encryption algorithms =96 not to mean the parti= cular > combined representation of those parameters apparently specified in the A= EAD > draft. I will correct the terminology usage in the next revision of the > JOSE specifications. > > > The semantic point remains that it=92s cleaner and more flexible to have = the > Key, the Plaintext, IV, and =93additional authenticated data=94 parameter= s all > be separate inputs and the Ciphertext and =93authentication tag=94 all be > separate outputs. In JOSE=92s 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=92s inher= ent > to its representation, and it doesn=92t match the one you=92ve 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 representatio= n > to be able to use the combinations already present in the JOSE > representations and then reassembly at decryption time. That=92s just mo= re > work for implementers, and it=92s not semantically necessary work. > > > Are you open to specifying versions of your algorithms that don=92t requi= re a > particular combination method for the parameters, but instead leave the > combination up to the use case? I=92m fine with you also specifying a > specific combination method as an optional feature of the specification. > But it shouldn=92t be part of the algorithm definition, just like it isn= =92t 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 > Date: Monday, November 12, 2012 1:55 PM > To: Cisco Employee , "cfrg@irtf.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 th= at > 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 wou= ld > be a better match for JOSE=92s 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 1= 9 > 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 say= s > > > "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, versi= on > 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 > > The diff between the current and the previous version is available at > > This draft has been proposed for use in the JOSE WG > , where its adoption would allow t= he > working group to omit "raw" unauthenticated encryption, e.g. AES-CBC, and > only include authenticated encryption. Thus I am asking for your help i= n > 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 >