Re: [Cfrg] Encrypt in place guidance

Michael StJohns <msj@nthpermutation.com> Wed, 01 April 2020 16:33 UTC

Return-Path: <msj@nthpermutation.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 E98043A12A0 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 09:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 l7TW-clFOaUB for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 09:33:13 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC763A129A for <cfrg@irtf.org>; Wed, 1 Apr 2020 09:33:13 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id u4so489456qkj.13 for <cfrg@irtf.org>; Wed, 01 Apr 2020 09:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Snb9XMTFfdJkRQItxPRRiSEVX03vy1n2n+/MvW5Vwz4=; b=cQAhX5vGd+GXJLXTIzG5Op6BiIw5PZW1NPDtMDNyt1wlf9RgVWoFN24hGrBzOTUq7w srUr0px3VXlElXMjKtVzp128rAhVVckuG88hixeyDoqCFKXZJIezhlMsYXd76nrcYxNG /t9B6kpnojTOoOSiMNiTl9BRP54tJFxsDEYj2S5fNYYksrk7376goDeNRpiC7uMu8kPg AK4XgHu3ys+RtYhViEDXc5CS/w54P2/lOdKo6K/vj9DTI4pAUyBt8HHWMef3/Ar1CvGO XEXSTLiM1vOpB3y1gaTJNmymXGoyt9307AxckgqKzNk3/s0LftCpCmLUdxX3uucgFAdD Mjpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Snb9XMTFfdJkRQItxPRRiSEVX03vy1n2n+/MvW5Vwz4=; b=tpCxq5BXgUmEmleHUexf5lZ9uLP7tyMEdiPYZU8kVkLXQP0Vly2H3NI3svue7fatR9 pufS8hx5XabDK/QfOH2NUZTxg03Preloxcyt6ccCm00O7TDFVA+U5Ht4Xa0yTXKFhISE 8ZXpfrCAaz1QJy6F9wIph1mE7aoqNdyGA1BjvTJ/BWliiuWnVz/jF6Wb+RKXpG4LDhHi jZM2SFeY3z97QA9N9hiuYV4U9j7SY7a9vATWG5hb+fFimMivENCYA0vaf5iyNMIRqVNV B2gO+IQ2wncJTJ7ZgF45G0bjP0rlaK/kruDA95iCB7p2FIUDJwWqFfpB52lkSpeQHVVn uNOg==
X-Gm-Message-State: ANhLgQ21KDt61aPXVjsysqcOCRmbtnnJsxsSDiTqbbk+YZvYBsMUi0Dc iCxeprEaXiBuKLfsOtVHaw7TtDOMDvg=
X-Google-Smtp-Source: ADFU+vuDeai19eOHTx+D5DZhFunpLjBxoOVQ3YatPK25EJ+xxRddEd0wIGfRpypDkh0lJf+3R/OdRw==
X-Received: by 2002:a05:620a:148c:: with SMTP id w12mr9716148qkj.124.1585758791780; Wed, 01 Apr 2020 09:33:11 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id 82sm1717222qkd.62.2020.04.01.09.33.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2020 09:33:10 -0700 (PDT)
To: Robert Moskowitz <rgm-sec@htt-consult.com>, cfrg@irtf.org
References: <B3BE1040-E53E-4F4B-B221-6FCF8CA26C60@ll.mit.edu> <39806a9f-206b-797d-e2b8-0a55bea2b1cb@htt-consult.com> <6f41ddbd-d2ec-1ecc-deca-9230f11fa421@nthpermutation.com> <b4129c1c-2a2b-9483-dfa1-f86d72c10680@htt-consult.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <3593bcc4-8a28-e9f7-cac2-025f0985fa47@nthpermutation.com>
Date: Wed, 1 Apr 2020 12:33:09 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <b4129c1c-2a2b-9483-dfa1-f86d72c10680@htt-consult.com>
Content-Type: multipart/alternative; boundary="------------668AAF9A93F78E84DAA9F251"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mTUyeNS9Lp2m7r19dj7j48GrSEc>
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: Wed, 01 Apr 2020 16:33:17 -0000

NIST SP800-38A -  Section 6.3.   CFB can work on any number of bits up 
to the block size.  CFB8 does a byte at a time and uses a block cipher 
operation for each byte.

Mike



On 4/1/2020 12:25 PM, Robert Moskowitz wrote:
>
>
> On 4/1/20 12:15 PM, Michael StJohns wrote:
>> Pretty much every IOT chip these days has support for at least AES 
>> 128 (and usually for ECB and  CTR and/or CCM).   Unless there is a 
>> good reason to use something else, assuming you have a good IV 
>> source, use AES-CTR - it can be used for any number of bytes without 
>> expansion.  If you don't have a great IV source, use something like 
>> AES-CFB8.
>
> Michael,
>
> I went looking for CFB8 and was only getting CFB.  Can you please 
> provide a pointer to it?
>
> Thanks.
>
> Bob
>
>
>>    Avoid domain specific algorithms that may or may not have had 
>> security analyses done that are appropriate to your domain.
>>
>> You should have some some sort of message authentication/integrity 
>> protection and that's a physics problem that needs to be solved by 
>> allocating some additional bytes.  Generally at least 4 for an 
>> integrity tag.   If you have that space, move to AES-CCM as your mode.
>>
>> IMO, Speck may be a better choice later on as it gains more public 
>> experience and more implementations but you may want to think twice 
>> about including it in a specification at this time.
>>
>> Later, Mike
>>
>>
>> On 4/1/2020 10:58 AM, Robert Moskowitz wrote:
>>>
>>>
>>> On 4/1/20 10:06 AM, Blumenthal, Uri - 0553 - MITLL wrote:
>>>> Robert,
>>>>
>>>> You're in luck, because Speck offers 96-bit block-size (with key size 96 or 144 bits). ;-)
>>>
>>> I did see that and felt it was a strong point for Speck.
>>>
>>>> This (variable block size) was one of the advantages of Speck over, e.g., AES. So the ISO first trimmed it down to the AES capabilities, and then decided "oh well, we already have AES".
>>>
>>> I saw that in the IACR slides:
>>>
>>> Gee look at all these great advantages it has.
>>>
>>> But the other guys don't, so let's strip them out.
>>>
>>> Oh, gee, no advantage here, so let's just drop it.
>>>
>>> Got to love that logic.  Of course if it is really a broken cipher, 
>>> then it is broken.
>>>
>>> There is really crypto justification for AEAD.  But this comes at a 
>>> serious cost that sometimes cannot be met.
>>>
>>> Having options like what Speck provides has value.  Not great, but a 
>>> real value.
>>>
>>> Yes, there are all sorts of replay attacks.  There are some use-case 
>>> related mitigations.  In this case, so the operator is lieing about 
>>> where they are.  So what, they can do that anyway and have all the 
>>> crypto right.
>>>
>>> This is why, on a system level, we are proposing how an authorized 
>>> entity can directly and securely message the operator's control 
>>> system with such things as:  "Land now or be shot out of the air and 
>>> THEN we will come to get you." Much more timely than trying to send 
>>> an officer to the supposed Geo position of the operator first.
>>>
>>> :)
>>>
>>>> On 4/1/20, 09:38, "Cfrg on behalf of Leo Perrin"<cfrg-bounces@irtf.org on behalf of leo.perrin@inria.fr>  wrote:
>>>>
>>>>      
>>>>      > So I am looking for both a 64 bit and 96 bit block cipher.  I figured
>>>>      > out that if there is no 96 bit, I can do this by first encrypting the
>>>>      > 1st 64 bits and then the last 64 bits.  The middle 32bits are double
>>>>      > encrypted, but I not seeing that as a problem. But then I am not a
>>>>      > cryptographer, only a crypto-plumber.
>>>>      
>>>>      I would advise you *not* to do this: this effectively creates a 96-bit block cipher with at least one significant flaw.
>>>>      
>>>>      Suppose that your plaintext is (A,B,C), where each word is 32-bit long, and that you use a block cipher E_k operating on 64 bits. Then you would first obtain (W,X) = E_k(A,B), and then (Y,Z) = E_k(X,C), so that the encryption of (A,B,C) is (W,Y,Z). The problem with this approach is that W does not depend on C. A similar behaviour exists for decryption (C does not depend on W). As a consequence, this 96-bit block cipher does not provide full diffusion!
>>>>      
>>>>      It is better to use a dedicated 96-bit block cipher. There are not many of them but they exist:
>>>>      - BKSQ, from the AES designers (essentially a 96-bit AES);
>>>>      - SEA,
>>>>      - EPCBC.
>>>>      The references for these are in our survey.
>>>>      
>>>>      If you really need to turn a 64-bit block cipher into a 96-bit one, then you would need to do at least 3 iterations of the 64-bit cipher instead of 2 as you suggested:
>>>>      
>>>>      (A, B, C) ---(E_k, Id)---> (W, X, C)
>>>>      (W, X, C) ---(Id, E_k)---> (W, Y, Z)
>>>>      (W, Y, Z) ---(E_k, Id)---> (T, U, Z)
>>>>      
>>>>      Still: from a security stand-point, I would much prefer a dedicated 96-bit cipher if I were in your position.
>>>>      
>>>>      Cheers,
>>>>      
>>>>      /Léo
>>>>      
>>>>      _______________________________________________
>>>>      Cfrg mailing list
>>>>      Cfrg@irtf.org
>>>>      https://www.irtf.org/mailman/listinfo/cfrg
>>>>      
>>>>
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> Cfrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>