Re: [TLS] Deprecating SSLv3
mrex@sap.com (Martin Rex) Tue, 25 November 2014 13:04 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83C1A0358 for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 05:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 JkT19YRwEfQN for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 05:04:19 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066351A0263 for <tls@ietf.org>; Tue, 25 Nov 2014 05:04:19 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 10C063A18F; Tue, 25 Nov 2014 14:04:16 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D178742158; Tue, 25 Nov 2014 14:04:16 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C715F1B00A; Tue, 25 Nov 2014 14:04:16 +0100 (CET)
In-Reply-To: <2955685.UojdYEpn75@pintsize.usersys.redhat.com>
To: Hubert Kario <hkario@redhat.com>
Date: Tue, 25 Nov 2014 14:04:16 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141125130416.C715F1B00A@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uiYIQmN9IEnCLajMbdqGpICRVUQ
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/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: Tue, 25 Nov 2014 13:04:21 -0000
Hubert Kario wrote: >Martin Rex wrote: >> >> It's a plaintext recovery of 1 byte per 256 requests on average > > no, you need 256 for 100% chance of recovery, statistically speaking you need > 128 requests for a 50% chance of recovery - 50% *is* average, especially if > we're talking about recovering multiple bytes. The 128 on average would apply only to things like an exhaustive key search, where you do not encounter duplicates, and the worst case would be the last possibility after 256 tries. For the poodle attack, you have a random distribution, caused by the IVs so you will regularly get duplicate wrong guesses during the first 128 tries, and worst case will be much more than 256 tries. The math might be what is described here: http://en.wikipedia.org/wiki/Coupon_collector%27s_problem Any math/probability takers? -Martin
- [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Matt Caswell
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Stephen Checkoway
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Alfredo Pironti
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Ronald del Rosario
- Re: [TLS] Deprecating SSLv3 Alfredo Pironti
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Kurt Roeckx
- Re: [TLS] Deprecating SSLv3 Salz, Rich
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Kurt Roeckx
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating SSLv3 Watson Ladd
- Re: [TLS] Deprecating SSLv3 Nico Williams
- Re: [TLS] Deprecating SSLv3 Yoav Nir
- Re: [TLS] Deprecating SSLv3 Bill Frantz
- Re: [TLS] Deprecating SSLv3 Nico Williams
- Re: [TLS] Deprecating SSLv3 Henrick Hellström
- Re: [TLS] Deprecating SSLv3 Yuhong Bao
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex