Re: [COSE] COSE Support for AES-CTR and AES-CBC

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 07 November 2022 12:28 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFCC14CE30 for <cose@ietfa.amsl.com>; Mon, 7 Nov 2022 04:28:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hmm3Ld90px3 for <cose@ietfa.amsl.com>; Mon, 7 Nov 2022 04:28:53 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA0EC14F742 for <cose@ietf.org>; Mon, 7 Nov 2022 04:28:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6D73767E7A for <cose@ietf.org>; Mon, 7 Nov 2022 14:28:50 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id M0Yf_MzCC0Ca for <cose@ietf.org>; Mon, 7 Nov 2022 14:28:50 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 40C2E28A for <cose@ietf.org>; Mon, 7 Nov 2022 14:28:49 +0200 (EET)
Date: Mon, 07 Nov 2022 14:28:49 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "cose@ietf.org" <cose@ietf.org>
Message-ID: <Y2j6AR45StScK2sh@LK-Perkele-VII2.locald>
References: <CO1PR00MB13086039D60B9997AE5F5928F54E9@CO1PR00MB1308.namprd00.prod.outlook.com> <SA1PR00MB1310AB40F32B3B2E9FC36D31F5239@SA1PR00MB1310.namprd00.prod.outlook.com> <ADE35F26-5BF8-4205-A8B5-36C1F55E8207@vigilsec.com> <32d84d35531543469a4a196a7b137cb1@amazon.com> <39D0918E-F757-4205-9D27-882E4587F95A@vigilsec.com> <CAPmVn1N7brE5SsgTU9n3ubCY3NExZfrgobkubRx7671LbU5Tcg@mail.gmail.com> <CAPmVn1OJgeVGkjBnjh-1zQcvptWDqSnE4YiAd7wM7-Eh-0xg=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPmVn1OJgeVGkjBnjh-1zQcvptWDqSnE4YiAd7wM7-Eh-0xg=A@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/5t_xOyza0hqCSh0FZck9jpqgHQM>
Subject: Re: [COSE] COSE Support for AES-CTR and AES-CBC
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 12:28:54 -0000

On Mon, Nov 07, 2022 at 11:33:09AM +0000, Brendan Moran wrote:
> Sorry, I had the wrong email address for Scott.
> 
> I’m trying to understand some of the concerns that have been raised. I
> understand that AES-GCM is not exposed to the concerns that Sophie and has
> raised?
> 
> If we used AES-GCM with out of order reception and on-the-fly decryption,
> would that mitigate the risks?

Probably crazy idea:

Define new algorithms A128GCM-DT, A192GCM-DT, A256GCM-DT, and
ChaCha20/Poly1305-DT (DT => Detached tag) that are otherwise the same as
A128GCM, A192GCM, A256GCM and ChaCha20/Poly1305, except that instead of
concatenating the tag to ciphertext, the tag is carried on new "tag"
(bstr) parameter in the unprotected bucket.


Used with COSE detached ciphertext, that allows placing any expansion
into external structure (which one presumably have anyway due to
signatures) and almost[*] random-access decryption after prevalidation
pass (MAC is over ciphertext, so no need to decrypt in prevalidation).



[*] For AES-GCM, any multiple of 16 bytes starting from offset multiple
of 16. For Chacha20-Poly1305, any multiple of 64 bytes starting from
offset multiple of 64.




-Ilari