Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 31 March 2020 19:04 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 D69A33A273C for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:04:51 -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 eUtmz37lM0eY for <cfrg@ietfa.amsl.com>; Tue, 31 Mar 2020 12:04:49 -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 9B44D3A2977 for <cfrg@ietf.org>; Tue, 31 Mar 2020 12:03:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 76B8D62134; Tue, 31 Mar 2020 15:03:30 -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 cY3ZK6lcyFmu; Tue, 31 Mar 2020 15:03:27 -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 C24F86213F; Tue, 31 Mar 2020 15:03:26 -0400 (EDT)
To: Henry B Hotz <hbhotz@oxy.edu>
Cc: cfrg@ietf.org
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <A282938F-F720-4434-A014-F99C47205EE4@oxy.edu>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <e29a545f-c191-0935-f758-32d8204b59df@htt-consult.com>
Date: Tue, 31 Mar 2020 15:03:24 -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: <A282938F-F720-4434-A014-F99C47205EE4@oxy.edu>
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/aa08M0RigBRVAoocqTXY2sH_Zos>
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:04:52 -0000


On 3/31/20 2:55 PM, Henry B Hotz wrote:
> What about format preserving encryption?

Can you point me to info on this?

I am only marginally familiar with it.  Not something I have had 
occation to study.

Thanks.

>
> Personal email. hbhotz@oxy.edu
>
>> On Mar 31, 2020, at 11:30 AM, 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.
>>
>>
>> _______________________________________________
>>