[TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
Michael D'Errico <mike-list@pobox.com> Thu, 14 November 2013 04:15 UTC
Return-Path: <mike-list@pobox.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A927821E80C6 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkIScdThBPBy for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:15:22 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB521E8085 for <tls@ietf.org>; Wed, 13 Nov 2013 20:15:22 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 35EBFDE27; Wed, 13 Nov 2013 23:15:20 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GdAYsnjND/hM GsxDi6lfLJj1eFU=; b=FyXU1lHyEubhwS8Mp/Jendcc0PSBt6snLF7Z37bBCub5 6aKCdAKxYSFgndBWONdUGi8Lo3YUcM8bxj9Df9t0BVuK6p6WchJz5LDoWpjeUUvx cd+ziAY7IBjnCjaE9+mWnyrzBfvIiTcTrUCQy4d/rPgAlrUqo0Egfm0R3OY+KHc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hYGsjR /cDuEL0YdrGkEcsj236TD33pHdx/CENstvAbAVCo9a0n6TaDdxwaMBi0PcVf4p7g 6Owh/tt4SfLO/d/Szupu4Ydz/zsNzYZf301NuWpuY4bI6NYdk2/4g+gmANwnBm9z c57QuIsO+BQP50VngYbNy0LEfOaHiFOe1RnYE=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2CDA9DE26; Wed, 13 Nov 2013 23:15:20 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 544E7DE23; Wed, 13 Nov 2013 23:15:17 -0500 (EST)
Message-ID: <52844E54.8000606@pobox.com>
Date: Wed, 13 Nov 2013 20:15:16 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan>
In-Reply-To: <1384400970.2092.7.camel@aspire.lan>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 5E60EAA0-4CE3-11E3-97A7-F66B0E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 14 Nov 2013 04:15:27 -0000
Nikos Mavrogiannopoulos wrote: > On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote: >> You proposal adds the padding at the beginning only. Since the >> problem exhibited by RC4 is inherent to any XOR-encryption with >> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an >> extension use random fraction, random content, authenticated padding >> on both sides of the plaintext, with a combined minimum padding length of >> at least 16 bytes, in order to mitigate statistical attacks on >> any bias that may be found in the pseudo-random-pad. > > The above draft does: > 1. prevent padding oracle attacks > 2. hide the length of the plaintext > > What you propose there is having the plaintext appear and finish in an > unpredictable position. That's an interesting approach, not handled by > the draft above. > > In simple terms you're asking for more bells and whistles :) If I recall correctly from DJB's paper, the problem with RC4 is bias in the first 256 or so bytes of the key stream. Would it be possible to "fix" RC4 using this extension? Simply insert a random amount (at least 256 bytes) of pseudo-random padding at the beginning of the first record sent using an RC4 cipher suite? Mike
- [TLS] Requesting feedback on TACK draft Trevor Perrin
- Re: [TLS] Requesting feedback on TACK draft Peter Gutmann
- Re: [TLS] Requesting feedback on TACK draft Lewis, Nick
- [TLS] padding bug (was: Re: Requesting feedback o… Peter Saint-Andre
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Eric Rescorla
- Re: [TLS] padding bug (was: Re: Requesting feedba… Alfredo Pironti
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Yaron Sheffer
- Re: [TLS] padding bug (was: Re: Requesting feedba… Paterson, Kenny
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Adam Langley
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Nico Williams
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug (was: Re: Requesting feedba… Bodo Moeller
- Re: [TLS] padding bug (was: Re: Requesting feedba… Paterson, Kenny
- Re: [TLS] padding bug Brian Smith
- Re: [TLS] padding bug Martin Rex
- [TLS] Encrypt-then-MAC again (was Re: padding bug) Michael D'Errico
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Michael D'Errico
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ben Laurie
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Bryan C. Geraghty
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- [TLS] Would this fix RC4 again? (was Re: Encrypt-… Michael D'Errico
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Watson Ladd
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Paterson, Kenny
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Nikos Mavrogiannopoulos
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Jacob Appelbaum
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Alex Elsayed
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- [TLS] draft-mavrogiannopoulos-new-tls-padding-00 Martin Rex
- Re: [TLS] draft-mavrogiannopoulos-new-tls-padding… Nikos Mavrogiannopoulos