[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.
- [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Henry B Hotz
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Russ Housley
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Dan Brown
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Henry B Hotz
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Jeffrey Walton
- Re: [Cfrg] Encrypt in place guidance Stephen Farrell
- Re: [Cfrg] Encrypt in place guidance Salz, Rich
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Björn Haase
- Re: [Cfrg] Encrypt in place guidance Leo Perrin
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Leo Perrin
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Dan Brown
- Re: [Cfrg] Encrypt in place guidance Salz, Rich
- Re: [Cfrg] Encrypt in place guidance Jeffrey Walton
- Re: [Cfrg] Encrypt in place guidance Leo Perrin
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Michael StJohns
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Michael StJohns
- Re: [Cfrg] Encrypt in place guidance Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz
- Re: [Cfrg] Encrypt in place guidance Sergey Agievich
- Re: [Cfrg] Encrypt in place guidance Robert Moskowitz