Re: [Cfrg] Encrypt in place guidance

[Robert Moskowitz <[e-mail]>]

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 <[e-mail]> 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.