Re: [TLS] About TLS 1.2 AEAD ciphers definition

Martin Rex <mrex@sap.com> Thu, 27 May 2010 17:26 UTC

Return-Path: <mrex@sap.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 B56FB3A6B0B for <tls@core3.amsl.com>; Thu, 27 May 2010 10:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 Yoh8Z+pMXJna for <tls@core3.amsl.com>; Thu, 27 May 2010 10:26:54 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6ABB63A68BB for <tls@ietf.org>; Thu, 27 May 2010 10:26:54 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4RHQhfZ009626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 19:26:43 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005271726.o4RHQgJU026485@fs4113.wdf.sap.corp>
To: juhovh@iki.fi (=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?=)
Date: Thu, 27 May 2010 19:26:42 +0200 (MEST)
In-Reply-To: <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi> from "=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?=" at May 27, 10 07:42:18 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: agl@imperialviolet.org, 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
Reply-To: mrex@sap.com
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:26:57 -0000

=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= wrote:
> 
> 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?

Yes, that is likely a misunderstanding.

http://en.wikipedia.org/wiki/Counter_mode#Counter_.28CTR.29

Counter mode turns a block cipher into a generator of a (pseudo) random pad,
Essentially, the _application_data_ is encrypted by XORing it with
that (pseudo) random pad exactly like a stream cipher such as RC4 would
do it.

Only when the application data is encrypted with the block cipher function
it is necessary to pad the data up to the full block size, as with the more
traditional modes of operation for block ciphers such as CBC or ECB.

-Martin