IETF Logo Mail Archive

Re: [Cfrg] pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call)

"Salz, Rich" <rsalz@akamai.com> Sat, 22 March 2014 18:31 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF521A09C1 for <cfrg@ietfa.amsl.com>; Sat, 22 Mar 2014 11:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 QabwmAzJNvZZ for <cfrg@ietfa.amsl.com>; Sat, 22 Mar 2014 11:31:01 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB661A09BD for <cfrg@irtf.org>; Sat, 22 Mar 2014 11:31:00 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 29DB74745E; Sat, 22 Mar 2014 18:31:00 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1CC654745C; Sat, 22 Mar 2014 18:31:00 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 18DE22027; Sat, 22 Mar 2014 18:31:00 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 22 Mar 2014 14:30:59 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "saag@ietf.org" <saag@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Sat, 22 Mar 2014 14:30:58 -0400
Thread-Topic: pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call)
Thread-Index: AQHPRdiIOWzUzYSJ3Uax4nMLHIMeoprtNdIAgAA25uA=
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FCF2504B@USMBX1.msg.corp.akamai.com>
References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <CF522EF0.19491%kenny.paterson@rhul.ac.uk> <532D99CA.10405@cs.tcd.ie> <CF535271.19584%kenny.paterson@rhul.ac.uk>
In-Reply-To: <CF535271.19584%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BUl206KaXR8n04j0LLtICE5WZy8
Cc: "Virginie.GALINDO@gemalto.com" <Virginie.GALINDO@gemalto.com>
Subject: Re: [Cfrg] pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2014 18:31:02 -0000

> I agree, this is important. But putting the already broken schemes in a new standard does not seem helpful in that regard.

It's a  new API.  It's not a standardization of something that already exists, it's a brand new whole-cloth invention of something that did not exist before.  And yet, we're going to allow developers to create broken data.  "Does not seem helpful" is really understatement.

Perhaps they can create read-only bindings for these insecure structures?

Perhaps, as a gedanken experiment, I can propose a generalization of the symmetric encryption algorithm rot-13, which has a huge historical legacy via Usenet? The security considerations are pretty simple: "do not choose number of rounds (n) and shift size (s) such that n*s is zero mod 26."  That would seem to meet all the requirements of the current draft.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

v2.23.0 | Report a Bug | By Email