Re: [Cfrg] Encrypt in place guidance

Russ Housley <housley@vigilsec.com> Tue, 31 March 2020 19:05 UTC

Return-Path: <housley@vigilsec.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 8676A3A26F5 for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BbHf_gCxdAHE for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:05:22 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4BE3A2802 for <cfrg@ietf.org>; Tue, 31 Mar 2020 12:03:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 197F6300A01 for <cfrg@ietf.org>; Tue, 31 Mar 2020 15:03:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yWf1vUzKL6Tw for <cfrg@ietf.org>; Tue, 31 Mar 2020 15:03:51 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 22CB4300AEF; Tue, 31 Mar 2020 15:03:51 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com>
Date: Tue, 31 Mar 2020 15:03:52 -0400
Cc: cfrg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEF91723-C5C1-4EA5-ADCE-D439D4EF3BDF@vigilsec.com>
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/REsmdRlc9iZzSNHdzkt7DaJdx6w>
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: Tue, 31 Mar 2020 19:05:27 -0000

Counter mode can be used to encrypt any number of bits without expansion as long as you have a convention for the place to start using the key stream,  In your case, you will not need more than one block, so the convention is which counter value to encrypt to produce the key stream.

Russ


> On Mar 31, 2020, at 2:30 PM, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
> 
> The problem is in the Unmanned Aircraft broadcast messages (see DRIP work).
> 
> In the System Message defined in ASTM F3411-19 there are 8 bytes of sensitive Operator Information that I want to encrypt.  I can get a shared secret via the PK mechanism in ECIES.
> 
> The challenge is in encrypting, then decrypting these 8 bytes.
> 
> There is no room for expansion in the message.  All we have are these 8 bytes.
> 
> There is nothing unique in each System Message to use an an IV. There are 7 bytes of mission information and 1 byte of flags that are constant for a given mission (but may be the same in a later mission).
> 
> There are 8 reserved bytes, but I feel they left out 4 bytes of important Operator Information (thus making 12 bytes to encrypt). So no grabbing those reserved bytes.
> 
> Since this information is of limited value for some period after the completion of the mission, I was considering just using AES-ECB.
> 
> Opps.   I need 16 bytes for the output of AES-ECB.  Or at least that is my reading of the ECB mode.
> 
> So I am seeking guidance here on what cipher to use in this particular situation.
> 
> Thank you.