Re: [Cfrg] Cryptographic meta-principles

Steven Bellovin <smb@cs.columbia.edu> Wed, 23 May 2012 16:00 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDCF21F8734 for <cfrg@ietfa.amsl.com>; Wed, 23 May 2012 09:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 M2VKcx+cULyf for <cfrg@ietfa.amsl.com>; Wed, 23 May 2012 09:00:34 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5104F21F8694 for <cfrg@irtf.org>; Wed, 23 May 2012 09:00:34 -0700 (PDT)
Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q4NG0Qr5017332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 May 2012 12:00:26 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov>
Date: Wed, 23 May 2012 12:00:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D096C42B-E7DB-4A34-8649-933EBDA83CE3@cs.columbia.edu>
References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C1D@MSIS-GH1-UEA06.corp.nsa.gov>
To: "Igoe, Kevin M." <kmigoe@nsa.gov>
X-Mailer: Apple Mail (2.1278)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Cryptographic meta-principles
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
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: Wed, 23 May 2012 16:00:36 -0000

These are excellent.  Are they published anywhere stable and citable?  I'd also incorporate some of Shamir's Ten Commandments (from http://www.ieee-security.org/Cipher/ConfReports/conf-rep-Crypto95.html) especially #4.

On May 23, 2012, at 10:30 59AM, Igoe, Kevin M. wrote:

> Some cryptographic meta-principles.  Feel free to disagree or make additions.    I think 2, 5, 7 and 8
> are the most relevant to the CFRG.   I always found #1 useful in analyzing systems.  Always
> ask “where have we moved the risk?”.
>  
> 1.       You can’t eliminate risk, you can just move it around.
> 2.       Needless complexity is the enemy of security.
> 3.       There is no such thing as a secure algorithm, only a secure system.  Even the most “secure” algorithm, if used improperly, can be  worthless.   Without the proper architecture, implementation, and management we are effectively “putting bank vault doors on cardboard boxes”.
> 4.       In the end everything  comes down to  a cost analysis: how much does it cost an adversary to attempt to exploit a
> given system and what is the adversary's expected gain from succeeding? Our goal is to select cryptographic mechanisms and parameter sizes that make the adversary’s expected return on investment negative.
> 5.       Moore’s Law continually decreases an adversary’s cost to attack a system. so we must assume that eventually all parameter sizes will need to be readjusted.
> 6.       In the limit as the parameter size/number of rounds goes to infinity, almost anything is secure.  The art is in picking mechanisms and parameter sizes that meet our needs efficiently.
> 7.       As far as possible, we should strive to provide a cryptographic environment that is both practical and stable.
> 8.       We don’t exist in a vacuum.  We need to constantly monitor the impact of current cryptographic practices on vendors and IETF working groups, try to foresee  emerging requirements, monitor the results being produced by the cryptologic research community, and co-ordinate our efforts with other standards bodies.
>  
> Strive to be simple, practical and consistent, but always be aware that in the long run change is inevitable.
>  
>  
>  
> Kevin M. Igoe        |   "Everyone is entitled to their own
> kmigoe@nsa.gov   |    opinions, but not to their own facts."
> co-chair CFRG       |       - Daniel Patrick Moynihan -
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


		--Steve Bellovin, https://www.cs.columbia.edu/~smb