Re: [COSE] Authentication tag
Samuel Erdtman <samuel@erdtman.se> Mon, 20 March 2017 19:58 UTC
Return-Path: <samuel@erdtman.se>
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 0DEB5131677 for <cose@ietfa.amsl.com>; Mon, 20 Mar 2017 12:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsJ17Owzahf0 for <cose@ietfa.amsl.com>; Mon, 20 Mar 2017 12:58:26 -0700 (PDT)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2203313166B for <cose@ietf.org>; Mon, 20 Mar 2017 12:58:12 -0700 (PDT)
Received: by mail-ot0-x230.google.com with SMTP id x37so139674916ota.2 for <cose@ietf.org>; Mon, 20 Mar 2017 12:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTRVhOm97NkcZoPi/oPcvkJSoSMnshFcKlcJ8gKQVPY=; b=ibqpPn4dqrDIhO4mWmGWyeARC74ZOzM77qKYtPUGxCV+NPOEAuCjuAUR2iY2LadMbn HtSbTg6WfP+4PKsj1lpTPB9wVAdon+FHTAC7StKFOm1dLyFZkc5dOnr1Y0guOWW/mIO/ fziAyUge5ltMtIFo9W+cRmGQ1Ml9BcntLijilmi3cpm+TD+Vgcj98Q9UMjzqH5vIH1ZI UmsGWJd+uVkKPpY2+5dH5tBl/rMGBa1Fjxu77KmejMxsSCsKZbmR0cE8caQSIzEF9Ri8 Dp50wieBCqAw3XB/saLRSvGnOab5THKXaxRrIIVRn2fct/Xt0Gmq3EAcnz1oJ6PwSomw jeNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nTRVhOm97NkcZoPi/oPcvkJSoSMnshFcKlcJ8gKQVPY=; b=RneRRPjD4zBS20lgk6IH1ZvOPNZpbAmx0RSy0VD6Nj+2fKrR/kPOUIY/h/fE5t5qh+ FfJbob0jvOXi82AoodZHdDL5ZmQ7j6wFpq1Fa/GcENSdaPaSql2/vD36r/HBHlrxIAgt a0vzZCPOweBRAlBR0nbj6IwV3B+UcYweEohS3CH+y8pdYBsPce53ZlKNPVus1CV/xWgw gc2IRZvor1mSpP3/S7Tyr3EajjYq55fb/UV5BowRYAdy7bjOthPWaqCDM48ZA5P0eIxT wc6K04B4MENKjXq/Mu9Gag5bbqh9V1pj5IEJlAJgO69AWMDZR1z73bkTb9nkpQmHJ9/O cmaQ==
X-Gm-Message-State: AFeK/H0FuOynyL6hwDtUpVeSyYTbaRh1UWkS+VMD6+USuglco+DDQZQVvacgyJt62Kqr9d+SccBTV8atdadExQ==
X-Received: by 10.157.27.164 with SMTP id z33mr17404025otd.164.1490039891458; Mon, 20 Mar 2017 12:58:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.125.40 with HTTP; Mon, 20 Mar 2017 12:58:10 -0700 (PDT)
In-Reply-To: <CAF2hCbZB_QtDHWexdzWWzhe4iWfF38JMBJf6CLwnPtL_KuESCA@mail.gmail.com>
References: <CAF2hCbYALonNaZ6BrmEhYosCrNsJqLmHs3YMupjOCeRxav2X9A@mail.gmail.com> <00f701d29f43$c278fd60$476af820$@augustcellars.com> <CAF2hCbbsEm7YNpPmQj_e2b-zfKyZ9B9E1BjLUPyZjbd44jtcNw@mail.gmail.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> <CAF2hCbZB_QtDHWexdzWWzhe4iWfF38JMBJf6CLwnPtL_KuESCA@mail.gmail.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Mon, 20 Mar 2017 20:58:10 +0100
Message-ID: <CAF2hCbboTj+v9GgVxeP+r2aRjwDT3qhyjTuVHBO-f2MeK-Zqbw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141a8346e8fdb054b2ef2e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/InoEnTeFOLSQTjnIzgKn7mDCh4E>
Subject: Re: [COSE] Authentication tag
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.22
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, 20 Mar 2017 19:58:33 -0000
*implementers On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <samuel@erdtman.se> wrote: > Thanks again! > > I think this will add some clarity for tormentors. > > //Samuel > > On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <ietf@augustcellars.com> > wrote: > >> There are two different schools of thought about where to put the >> authentication tag. RFC 5116 was designed so that it is part of the >> standard set of parameters rather than separate. Thus, for GCM, it is >> included as part of the cipher text. For SIV mode it is the IV and there >> is no extra authentication tag. >> >> >> >> Other encodings have made the fields be separate, JOSE and CMS keep the >> tag and the cipher text as separate items and, for some systems, you then >> get the opposite world of needed to combined them when doing decryption >> operation. The decision of where and how authentication tags are placed >> is always going to be an encoding decision and not part of the encryption >> algorithm. >> >> >> >> The decision was made to combine them for COSE because it saved an >> additional field, and thus one or more bytes are removed from the >> encoding. This followed the guidance of trying for very short encodings. >> >> >> >> I have filed an issue to remember this at the next revision. >> >> >> >> Jim >> >> >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:samuel@erdtman.se] >> *Sent:* Saturday, March 18, 2017 1:08 PM >> *To:* Jim Schaad <ietf@augustcellars.com>; ilariliusvaara@welho.com >> *Cc:* cose <cose@ietf.org> >> *Subject:* Re: Authentication tag >> >> >> >> Thanks Jim and Ilari for the quick replies. >> >> So if I understand it correctly RFC 5116 defines AE and AEAD with the >> requirement to bundle the tag with the ciphertext, so it would not be >> allowed to put the tag in the COSE headers. >> >> Section 10 Content Encryption Algorithms, gives a hint of where to find >> the tag, 'normally' appended. Forgive me my ignorance, but does GCM have a >> more normative requirement on the location of the tag in a ciphertext? >> >> If GCM does not mandate the location of the tag in the ciphertext and we >> cannot put it in a header attribute then I would like more explicit >> language about where to find/put the tag. >> >> Once again thanks for the quick and enlightening reply. >> >> Cheers >> >> //Samuel >> >> >> >> >> >> On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> >> wrote: >> >> From Section 10: >> >> >> >> COSE restricts the set of legal content encryption algorithms to those >> that support authentication both of the content and additional data. The >> encryption process will generate some type of authentication value, but >> that value may be either explicit or implicit in terms of the algorithm >> definition. For simplicity sake, the authentication code will normally >> be defined as being appended to the cipher text stream. The encryption >> functions are: >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:samuel@erdtman.se] >> *Sent:* Friday, March 17, 2017 9:50 AM >> *To:* cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com> >> *Subject:* Authentication tag >> >> >> >> Hi >> >> I´m working on a JavaScript implementation of the COSE msg specification, >> currently working on the GCM encryption. >> >> In the nodejs crypto environment the authentication tag is set separately >> i.e. a specific setAuthTag call. I looked into openssl and could see that >> that was the case there too. >> >> In the examples provided with the COSE specification I could find out >> that the auth tag is appends to the end of the ciphertext. >> >> I tried to find this described in the COSE specification but could not >> find it. It might be described in some refereed specification but it was >> not obvious to me at least. >> >> If it is not to late I would suggest that authentication tag is lifted >> out from the ciphertext and into the unprotected header similar to IV. Or >> that it is explicitly described that the authentication tag should be >> appended to the ciphertext. >> >> Cheers >> >> Samuel Erdtman >> >> >> >> >> > >
- [COSE] Authentication tag Samuel Erdtman
- Re: [COSE] Authentication tag Ilari Liusvaara
- Re: [COSE] Authentication tag Jim Schaad
- Re: [COSE] Authentication tag Samuel Erdtman
- Re: [COSE] Authentication tag Ilari Liusvaara
- Re: [COSE] Authentication tag Jim Schaad
- Re: [COSE] Authentication tag Samuel Erdtman
- Re: [COSE] Authentication tag Samuel Erdtman
- Re: [COSE] Authentication tag Justin Richer
- Re: [COSE] Authentication tag Renzo Navas