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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 CF0D4C3A589 for ; Thu, 15 Aug 2019 17:59:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A333D2083B for ; Thu, 15 Aug 2019 17:59:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="s+PbkYI6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730372AbfHOR7f (ORCPT ); Thu, 15 Aug 2019 13:59:35 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:39510 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731108AbfHOR7f (ORCPT ); Thu, 15 Aug 2019 13:59:35 -0400 Received: by mail-wr1-f67.google.com with SMTP id t16so2974845wra.6 for ; Thu, 15 Aug 2019 10:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fDiKGk9sGd71gzB1JxmvmDU6+YxWpqZzFJYbeb3g5Oc=; b=s+PbkYI63wwqg2bZSGV+5aCPEIRQdmwZ6g0owPrEyE1RefJJ79JWsHHZ+8xF5aufB9 CT1xKQkXFHIeBDO7jO9PEHXNPS34Z/Irm3bGuuBfWcQkmr18XhRYv6XicDfswx6A90Yi LU+IQGF6SfF4kFURVmasNni8o5o3AibM3C+jMFzJ6ALff5N3YIJQE21janxNeEWE9/Ii WIpt8nswQe2VLtFXT/DwklNd4i+9fYtohOIEQxPzBrmHoth1JxkHWYXKixu2qsJ6mLa6 0o8istn6X646ZaS5eUZBlFcdilMiod6scvyXx87cjL4jq1damUM145EeO+iVzUg2LkP+ ymgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fDiKGk9sGd71gzB1JxmvmDU6+YxWpqZzFJYbeb3g5Oc=; b=F+Jms5A5ZTdxQGmLZxuNm+3AeMP8jn1ybRP0LMVdh308XwsKgL2/DnQcQlhlgeiKrQ 2radu1+DcUQd5LLWuVW+ktjluMVFwriNRxySTObJZixyf5twDVaIDL8XTOHDspr9Se2L cJgrFDSrfTLuAsU9XZ6MliLrv4gToHSjpsJ58fOFMb5CgwL8pB9jyYMnLy1ddvZtKla7 UDmcpUgWPTIL+BBjkmoPe4MaNHnrSagsOrFvB2iXxjvi3DDfNsGNX8E9Wb6FiPjlqq/E 7WeK4ew8nDuqJY4579zfuiOgG9RBT/BV4sqlTvf/hTV1LrQkvvtM+Z9P7qjbReYaireA untA== X-Gm-Message-State: APjAAAVumbXwGCxrxXJ00M5YSP/zuYlAiRQasILDUq1f8UfTysoJs6MH XroQkJQwRU/G82hGdNi3c0RxaOqyKSzYgx39VGEjOw== X-Google-Smtp-Source: APXvYqzZXQJtLZz35otOaBEz0CFyoFQKMPLr3kKlvp4Bb0CNFG6zHi3siAAk337L0RQzmGYzvAhUKBi6JyPlOUBWQ04= X-Received: by 2002:adf:eb52:: with SMTP id u18mr6426644wrn.174.1565891972765; Thu, 15 Aug 2019 10:59:32 -0700 (PDT) MIME-Version: 1.0 References: <20190814163746.3525-1-ard.biesheuvel@linaro.org> <20190814163746.3525-2-ard.biesheuvel@linaro.org> <20190815023734.GB23782@gondor.apana.org.au> <20190815051320.GA24982@gondor.apana.org.au> <20190815113548.GA27723@gondor.apana.org.au> In-Reply-To: From: Ard Biesheuvel Date: Thu, 15 Aug 2019 20:59:21 +0300 Message-ID: Subject: Re: [PATCH v11 1/4] crypto: essiv - create wrapper template for ESSIV generation To: Herbert Xu Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Eric Biggers , device-mapper development , linux-fscrypt@vger.kernel.org, Gilad Ben-Yossef , Milan Broz Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Archived-At: List-Archive: List-Post: On Thu, 15 Aug 2019 at 20:46, Ard Biesheuvel wrote: > > On Thu, 15 Aug 2019 at 14:35, Herbert Xu wrote: > > > > On Thu, Aug 15, 2019 at 08:15:29AM +0300, Ard Biesheuvel wrote: > > > > > > So what about checking that the cipher key size matches the shash > > > digest size, or that the cipher block size matches the skcipher IV > > > size? This all moves to the TFM init function? > > > > I don't think you need to check those things. If the shash produces > > an incorrect key size the setkey will just fail naturally. As to > > the block size matching the IV size, in the kernel it's not actually > > possible to get an underlying cipher with different block size > > than the cbc mode that you used to derive it. > > > > dm-crypt permits any skcipher to be used with ESSIV, so the template > does not enforce CBC to be used. > > > The size checks that we have in general are to stop people from > > making crazy combinations such as lrw(des3_ede), it's not there > > to test the correctness of a given implementation. That is, > > we assume that whoever provides "aes" will give it the correct > > geometry for it. > > > > Sure we haven't made it explicit (which we should at some point) > > but as it stands, it can only occur if we have a bug or someone > > loads a malicious kernel module in which case none of this matters. > > > > OK. > > > > Are there any existing templates that use this approach? > > > > I'm not sure of templates doing this but this is similar to fallbacks. > > In fact we don't check any gemoetry on the fallbacks at all. > > > > OK, so one other thing: how should I populate the cra_name template > field if someone instantiates essiv(cbc(aes),sha256-ce)? We won't know > until TFM init time what cra_name allocating the sha256-ce shash > actually produces, so the only way to populate those names is to use > the bare string supplied by the caller, which could be bogus. > > To me, it seems like retaining the spawn for the shash is more > idiomatic, and avoids strange issues like the one above. Dropping the > spawn for the encapsulated cipher (which is tightly coupled to the > skcipher/aead being encapsulated) does seem feasible, so I'll go with > that. Actually, I should be able to lookup the alg without using it to create a spawn. Let me try that instead.