[Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 31 March 2020 18:30 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 287233A095D for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 11:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-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 4e_juvLCbjIr for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 11:30:14 -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 099AE3A2574 for <cfrg@ietf.org>; Tue, 31 Mar 2020 11:30:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id BC1316213F for <cfrg@ietf.org>; Tue, 31 Mar 2020 14:30:12 -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 myiDWiOcMR8m for <cfrg@ietf.org>; Tue, 31 Mar 2020 14:30:08 -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 9AEF162134 for <cfrg@ietf.org>; Tue, 31 Mar 2020 14:30:08 -0400 (EDT)
To: cfrg@ietf.org
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com>
Date: Tue, 31 Mar 2020 14:30:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/B9XueXT-M2y2xFYg2hVF8581osg>
Subject: [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 18:30:15 -0000

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.