From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation Date: Mon, 17 Jun 2019 19:05:51 +0200 Message-ID: References: <20190614083404.20514-1-ard.biesheuvel@linaro.org> <20190616204419.GE923@sol.localdomain> <8e58230a-cf0e-5a81-886b-6aa72a8e5265@gmail.com> <90214c3d-55ef-cc3a-3a04-f200d6f96cfd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Ard Biesheuvel , Milan Broz Cc: Herbert Xu , linux-fscrypt@vger.kernel.org, Eric Biggers , Gilad Ben-Yossef , device-mapper development , Linux Crypto Mailing List List-Id: dm-devel.ids On 17/06/2019 16:39, Ard Biesheuvel wrote: >> >> In other words, if you add some additional limit, we are breaking backward compatibility. >> (Despite the configuration is "wrong" from the security point of view.) >> > > Yes, but breaking backward compatibility only happens if you break > something that is actually being *used*. So sure, > xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is > that also true for, say, gcm(aes)-essiv:sha256 ? These should not be used. The only way when ESSIV can combine with AEAD mode is when you combine length-preserving mode with additional integrity tag, for example # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb it will produce this dm-crypt cipher spec: capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 IV is processed inside dm-crypt as IV. So if authenc() composition is problem, then yes, I am afraid these can be used in reality. But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are not supported by cryptsetup (we support only random IV in this case), so these should not be used anywhere. Milan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A688AC31E5B for ; Mon, 17 Jun 2019 17:05:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 792DA20652 for ; Mon, 17 Jun 2019 17:05:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TxjoaKSD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726248AbfFQRF4 (ORCPT ); Mon, 17 Jun 2019 13:05:56 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:43639 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726005AbfFQRFz (ORCPT ); Mon, 17 Jun 2019 13:05:55 -0400 Received: by mail-wr1-f66.google.com with SMTP id p13so10767758wru.10; Mon, 17 Jun 2019 10:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lvgi3+MQpM39FRojWazLhVvXezLQFMNFRlMRkueq/IA=; b=TxjoaKSD5m7bbK0Ih6BMmri+IaS5q+Ny+TFg8Gks5rIBqgGe2z3kV9mvy0d6exbcNP aJT2NQySaV8BAnqHAuXv4h4Nqx1H7TxFvtMqRNtOjc2RNZWInHZgqxvGjiKYOAhOvI6j Gv9uDdha/tJomPbIALK6ispRrcheUinwcrpynnjDxnFTZudsffVMK4n5pCPOXGK1adtu JDB3c29gfzY6S1K7hOj9ROoPwMTAaRKPer6hNujCe7jMnQHAPC4Vews0ca4/Plb396Iw QvkSBGqPnvQ/47zRhczZlPValAMW7y73+iZDdWivWjSSyLm+8G9pWyjU7GFfc1fSMXE8 7wTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lvgi3+MQpM39FRojWazLhVvXezLQFMNFRlMRkueq/IA=; b=jdNUIW/qr02QSYVgIfm4X0/rlCwAWg1fJEAFpo8f3xnm+dAiQOG1ZFGLAkWYejcN1v Xarj+5MmQvcikM8ttagsMNKtsVQpqlapVSHdt76Kma6lNHv9LJC7FyRzX/edGNc23q7r 2qJ1wrWDYWaFpLi/6+ThKxr1bFPeWwONVgNwsahCdtLxqfuP9zx1QAKwnbjZJQCJbL6W sSvKbDSaxiUQYFB7DdQbLoDzZA5cG0ShxGFaGTL8RX6diJ8QkmLAAga44xcjSna/uUyU LfDiMf/Aj2xBCaKTIJhKh/ZJMgYjq3drpehCctFUWBYdVwiph4QwhKgFSYSmZg1HDO1W APOQ== X-Gm-Message-State: APjAAAXEqstzq4rcOHLylC8P06vqC5hBo59D74obSRtTgqbg0eiPS+k4 7E/zQv9H91d555Ft+4NXKYfPr7HG6Y9wRA== X-Google-Smtp-Source: APXvYqzi0lLsm2064v1e5vDyLtdJ8bwCyUjazq2dKJytAV5jDeZySSDFNCf3pFZETLZqzrpwnpLjsw== X-Received: by 2002:adf:f946:: with SMTP id q6mr25621385wrr.109.1560791153693; Mon, 17 Jun 2019 10:05:53 -0700 (PDT) Received: from [192.168.2.28] (39.35.broadband4.iol.cz. [85.71.35.39]) by smtp.gmail.com with ESMTPSA id o14sm10435129wrp.77.2019.06.17.10.05.51 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 10:05:52 -0700 (PDT) Subject: Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation To: Ard Biesheuvel , Milan Broz Cc: Gilad Ben-Yossef , Eric Biggers , device-mapper development , linux-fscrypt@vger.kernel.org, Linux Crypto Mailing List , Herbert Xu References: <20190614083404.20514-1-ard.biesheuvel@linaro.org> <20190616204419.GE923@sol.localdomain> <8e58230a-cf0e-5a81-886b-6aa72a8e5265@gmail.com> <90214c3d-55ef-cc3a-3a04-f200d6f96cfd@gmail.com> From: Milan Broz Openpgp: preference=signencrypt Message-ID: Date: Mon, 17 Jun 2019 19:05:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 17/06/2019 16:39, Ard Biesheuvel wrote: >> >> In other words, if you add some additional limit, we are breaking backward compatibility. >> (Despite the configuration is "wrong" from the security point of view.) >> > > Yes, but breaking backward compatibility only happens if you break > something that is actually being *used*. So sure, > xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is > that also true for, say, gcm(aes)-essiv:sha256 ? These should not be used. The only way when ESSIV can combine with AEAD mode is when you combine length-preserving mode with additional integrity tag, for example # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb it will produce this dm-crypt cipher spec: capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 IV is processed inside dm-crypt as IV. So if authenc() composition is problem, then yes, I am afraid these can be used in reality. But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are not supported by cryptsetup (we support only random IV in this case), so these should not be used anywhere. Milan