Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 01 April 2020 01:01 UTC

Return-Path: <rgm-sec@htt-consult.com>
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 7D3763A0ED3 for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 18:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 5YV_EMqtGFWC for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 18:01:24 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24D73A0ED1 for <cfrg@ietf.org>; Tue, 31 Mar 2020 18:01:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 496406213F; Tue, 31 Mar 2020 21:01:22 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j2d2oQJJNrLE; Tue, 31 Mar 2020 21:01:14 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8FDBE62133; Tue, 31 Mar 2020 21:01:11 -0400 (EDT)
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Dan Brown <danibrown@blackberry.com>, "cfrg@ietf.org" <cfrg@ietf.org>
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <a16dcbe63aa745e482a3f435aa8e0470@blackberry.com> <f5e4c7a3-e039-ec7d-59b7-0c581d9022e6@htt-consult.com> <9ACD4ECA-CFBF-40DC-8CB8-BB7DAEFBB42D@ll.mit.edu> <d4383234-d452-dad8-52dc-dd35dbecbb8a@htt-consult.com> <95BC6180-32C1-4943-B8BC-FF40E1F6EB10@akamai.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <20b42f55-3f64-0275-c5d6-9e5f2878f874@htt-consult.com>
Date: Tue, 31 Mar 2020 21:01:09 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <95BC6180-32C1-4943-B8BC-FF40E1F6EB10@akamai.com>
Content-Type: multipart/alternative; boundary="------------079CA0A5083B1447E4B1812C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mRff2vOgZhYAdaWj9_tzXO1FZYw>
Subject: Re: [Cfrg] Encrypt in place guidance
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 01:01:28 -0000


On 3/31/20 7:56 PM, Salz, Rich wrote:
>
>   * **I will write the draft using Speck for 64 bit block.  That will
>     get the draft out and open up for discussion.
>
> Simon and speck are controversial, and almost nobody believed that 
> they weren’t deliberately crippled.  It hasn’t been proven.  But there 
> were enough concerns that ISO rejected them.  See 
> https://rwc.iacr.org/2019/slides/RWC87slides.pdf
>
> I mention all this because I am sure using Speck will be 
> controversial, and you need to be sure that you are willing to take on 
> that battle.
>

I will look at those slides, as the information I found on the ISO 
standard was 2018.

So far I am using it as a placeholder, as nothing else seems to be 
available.  Put it in a ID, and hopefully alternatives will come forward.

And we all know that placeholders all get replaced before any code gets 
locked in.

Right?

For this limited use, crippled is probably not an issue.

An observer has to be in place to 'see' the broadcast messages. Once 
they hit the USS, they are decrypted and the UTM contains the cleartext 
data forwarded by the USS.  NSA will have authorization into the US 
UTM.  The others, they have to have equipment there to see the 
messages.  And they probably will be into many of those UTM anyway...

If Speck is totally broken and any observer can quickly decrypt the 
content, then this is a non-starter.

Hopefully this will be an opertunity for some good work.