Re: [Cfrg] Halon's Razor -> Re: NSA sabotaging crypto standards

Paul Lambert <paul@marvell.com> Fri, 07 February 2014 20:16 UTC

Return-Path: <paul@marvell.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 8A2141ACCDF for <cfrg@ietfa.amsl.com>; Fri, 7 Feb 2014 12:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.883
X-Spam-Level:
X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
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 GFx9RAuk01Hz for <cfrg@ietfa.amsl.com>; Fri, 7 Feb 2014 12:16:36 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 728761AC7F0 for <cfrg@irtf.org>; Fri, 7 Feb 2014 12:16:36 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s17KGX5c009328; Fri, 7 Feb 2014 12:16:33 -0800
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1ht9vbvux0-8 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 07 Feb 2014 12:16:33 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Fri, 7 Feb 2014 12:16:29 -0800
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Fri, 07 Feb 2014 12:16:22 -0800
Thread-Topic: [Cfrg] Halon's Razor -> Re: NSA sabotaging crypto standards
Thread-Index: Ac8kQXx+bTLmYra0Rx6vGi35YeDJrg==
Message-ID: <CF1A7A48.2EE96%paul@marvell.com>
References: <CF1A73B4.2EE4C%paul@marvell.com>
In-Reply-To: <CF1A73B4.2EE4C%paul@marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-07_07:2014-02-07, 2014-02-07, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402070114
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Halon's Razor -> Re: NSA sabotaging crypto standards
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: Fri, 07 Feb 2014 20:16:37 -0000


Premature click-itis on prior post - sorry, please ignore …….

Changing the subject line since we are moving beyond the NSA conspiracy
theories.  The increased interest in security is a great benefit  but
much of our problems I fear are of our own creation:

    "Never attribute to malice that which is adequately explained by
Stupidity”    :-(

Improvements come not from accusations of past work, but a work plan to
look at new activities and better criteria.

Concrete suggestions:
 - identification and documentation of vulnerabilities and possible
“mistakes" 
 - identification and documentation of selection criteria
    - very interesting for ECC
      e.g. Benefits or issues of a = -3, p = pseudo mersenne,
      impact of zero value points and DPA
 - protocol review and refresh of guidelines and/or protocols
   - e.g. IPsec has a guideline I know needs changing …
 - re-examination of privacy in protocol designs
   - addresses, names and long term identifiers are the norm
     now … changes are possible


>>
>>I believe you are oversimplifying things. Indeed Rogaway suggested
>>encrypt-then-MAC, but other cryptographers were suggesting
>>MAC-then-Encrypt (authenticate what is meant not what is sent). There
>>was also no attack known for MAC-then-encrypt.
>
>Show me one cryptographer who recommended MAC-then-Encrypt.
>Also, absence of known attacks is not the same as absence of attacks.
>Encrypt-then-MAC was the conservative choice.

SIV is MAC then encrypt in it¹s own unusual manner.  Conservative from the
view of simplicity of proof does not invalidate other criteria. For
example, Rivest¹s Tweakable Cipher¹s offers potential for breaking away
from conservative conventional block cipher wisdom. There are pseudo
homomorphic applications where it’s more appropriate to MAC-then-encrypt.
There continues to be a gulf between ‘applied crypto’ and 'academic
crypto’.  Adamant mandates of abstract guidelines will not build consensus
or good products.  Progress can be made by more rapid academic analysis of
‘real protocols’, and more rapid translation of academic work into useable
designs.



Paul