IETF Logo Mail Archive

Re: [TLS] About TLS 1.2 AEAD ciphers definition

Adam Langley <agl@imperialviolet.org> Thu, 27 May 2010 17:11 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4143A6B55 for <tls@core3.amsl.com>; Thu, 27 May 2010 10:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.83
X-Spam-Level:
X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LekjoIo3su15 for <tls@core3.amsl.com>; Thu, 27 May 2010 10:11:40 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 216323A6B89 for <tls@ietf.org>; Thu, 27 May 2010 10:11:39 -0700 (PDT)
Received: by vws14 with SMTP id 14so171149vws.31 for <tls@ietf.org>; Thu, 27 May 2010 10:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=dyBijrqXBWtKqh+Sw6uxqlPM2G/XZIUevPdiBsRNF98=; b=PsnVHG5OuHtFF0pvuW/DnTDs4gkIWxppymmXqh57TfsoeeuLVUZ6+2z6LqYftQ064G AhMSdK4wN608wh9x43gFG7EMkABoi1zH242FHZld+0bYhoZQvhow4aVQDosaytk2NrFf 6kqUbprfxlL7bKzLQk8kV+MjaOelI22lY9JHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RLxpH53kw6SmrJxHvssRDnOary0gpRZts4qf/iKulCTstw6m3HjM8lHJHG76WdF1ti 8OnEGAdVBFCyI6w46ROYzb/5ufpkyWdpO87a54zuxp5qopW4NrCOUQ2/A+lGCUgc8HR4 M3KCqAfGwu7YRy4xIuOnM8XFgP0ZW23XGYxt8=
MIME-Version: 1.0
Received: by 10.220.62.204 with SMTP id y12mr7717487vch.206.1274980286468; Thu, 27 May 2010 10:11:26 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.220.123.16 with HTTP; Thu, 27 May 2010 10:11:26 -0700 (PDT)
In-Reply-To: <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi>
References: <4BFE8FC5.4070509@iki.fi> <AANLkTilTmkQh6RzCX50L35Jt2IkQq8mzylIkQbnDY7gS@mail.gmail.com> <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi>
Date: Thu, 27 May 2010 13:11:26 -0400
X-Google-Sender-Auth: gYHPEiU4DY9Qd2XcswCFMzejmoU
Message-ID: <AANLkTink409Nw256N_804EJEIO3LOh4Ozj9P1WgpjmIB@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: Juho Vähä-Herttua <juhovh@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] About TLS 1.2 AEAD ciphers definition
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 17:11:41 -0000

On Thu, May 27, 2010 at 12:42 PM, Juho Vähä-Herttua <juhovh@iki.fi> wrote:

> Also, if the TLSCompressed.length and TLSCiphertext.length are equal, how is it possible that the AEAD ciphers provide authentication? Shouldn't it at least add the Auth Tag to the message after encryption? Adding authentication without increasing the data length at all sounds a bit difficult. I'm actually more confused after this answer than I was before it.

Sorry, I meant that the ciphertext length is equal to the plaintext
length. You're correct that, in TLS speak, TLSCiphertext.length also
includes the MAC. But the MAC is a known length.

> The only currently defined AEAD ciphers seem to be AES_128_GCM and AES_256_GCM defined by RFC 5288. I'm a bit surprised that AES encryption doesn't introduce padding though, it might be just me misunderstanding the GCM process but I thought it still needs to pad the input data to match the block size, doesn't it?

GCM doesn't require padding since the encryption is a counter mode.


AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

v2.23.0 | Report a Bug | By Email