Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 31 March 2020 19:08 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 C54303A0DAC for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-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 uNWXNxax5vbl for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:08:22 -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 7E9D33A26F4 for <cfrg@ietf.org>; Tue, 31 Mar 2020 12:08:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 76D186213F; Tue, 31 Mar 2020 15:08:21 -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 ahNRhtk1ZxQu; Tue, 31 Mar 2020 15:08:17 -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 3340462134; Tue, 31 Mar 2020 15:08:17 -0400 (EDT)
To: Russ Housley <housley@vigilsec.com>
Cc: cfrg@ietf.org
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <DEF91723-C5C1-4EA5-ADCE-D439D4EF3BDF@vigilsec.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <0f228d52-7f05-8c39-a71a-150e0e3b6c4c@htt-consult.com>
Date: Tue, 31 Mar 2020 15:08:15 -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: <DEF91723-C5C1-4EA5-ADCE-D439D4EF3BDF@vigilsec.com>
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/FuWo1olPAHhkHdE-m3sPTMldSuI>
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:08:24 -0000


On 3/31/20 3:03 PM, Russ Housley wrote:
> 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.

In a private thread, this was pointed out to me.  The operator does 
register the mission and this is how the ECIES keys are exchanged. Not 
much to add an operator timestamp and thus the counter start value.

Actually such a timestamp should already be in the USS 'state' for the 
mission.

This leaves:  CTR or CFB.

>
> 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.