Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp584342pxu; Fri, 4 Dec 2020 10:14:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJy47jjV3L3nILdP14+6QVVQONwc188zrzprHiDBX7EzrANb+Cw1t9HOwmVqeWpyzoJOOsib X-Received: by 2002:a50:ac86:: with SMTP id x6mr8912517edc.197.1607105698569; Fri, 04 Dec 2020 10:14:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607105698; cv=none; d=google.com; s=arc-20160816; b=n4cxhBVVULsc3/jbnrAzSmd8pT+rtyb1Eu7ygIS6CIgBaiXeLBSUhp4Lk9if8yVnvw 8GnRzGS1DvhiURCAg0q1skBnjD6kdeCcL52Qx1xDKZEKV1UMJGoOt9H/iiEShNDLSwj/ AdTB5yB82aTdY3bzCqFNXkIhxTatPY+77ULfM0bp6VrjL9BBoqnByvb1spi4M2ytJ36Y MMJ/aUT9LZ+tZGKno8rJIFdJaDQAxhFr1sTfAQnlyfGkcBM+JF3+nF6zbT4A5ibzcZpL lGLHjYIraUfg53skcxmlR2sAkK77eVBUrpTQzw+2FQJUd2kSDr7FJ4wi59922+rxgbXQ bQoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=PIInQxUNF1k5+f591uYijcggM5bDTQyEZ1zjeRSTNiw=; b=h/M8v0kPMSNPz6QCORC1AxAtQMr49VNLwqANFjcXi7q+Hc+T/K37f5w6a50jgDGl5N Z4O9JSqgxMl5aHjGpE+58r5dEzAxYCViJaWmbqBiiIAIzphs8xLcCOECrrsZAsQra2Zo GcpPRL0H2tifXRuOqM5wZYKr6ZOX2G6D4xr76Rr3Y9sGedbMX1mvnnt8Qm22ip4TqqYf 8F582H6e5bgVh1f+fVXx6nTz+xDmhHvLSQpm/o6TLzmBmYEqnhwMF5XoQ6cCwcmyQKzh OfYVNSer2Z6AMvAA8Llewq3RtT6PLCoWfsf0rII/JmmF9gwjdkZvpt8fFX8kixCIDHNa crVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si1314932edr.468.2020.12.04.10.14.28; Fri, 04 Dec 2020 10:14:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728703AbgLDSO2 (ORCPT + 99 others); Fri, 4 Dec 2020 13:14:28 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:47966 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726775AbgLDSO1 (ORCPT ); Fri, 4 Dec 2020 13:14:27 -0500 Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B4IDIuo007813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Dec 2020 13:13:18 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id DA510420136; Fri, 4 Dec 2020 13:13:17 -0500 (EST) Date: Fri, 4 Dec 2020 13:13:17 -0500 From: "Theodore Y. Ts'o" To: David Howells Cc: Chuck Lever , Bruce Fields , CIFS , Linux NFS Mailing List , Herbert Xu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Trond Myklebust , linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org Subject: Re: Why the auxiliary cipher in gss_krb5_crypto.c? Message-ID: <20201204181317.GD577125@mit.edu> References: <2F96670A-58DC-43A6-A20E-696803F0BFBA@oracle.com> <160518586534.2277919.14475638653680231924.stgit@warthog.procyon.org.uk> <118876.1607093975@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <118876.1607093975@warthog.procyon.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Dec 04, 2020 at 02:59:35PM +0000, David Howells wrote: > Hi Chuck, Bruce, > > Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the > gss_krb5_aes_encrypt() code looks like the attached. > > From what I can tell, in AES mode, the difference between the main cipher and > the auxiliary cipher is that the latter is "cbc(aes)" whereas the former is > "cts(cbc(aes))" - but they have the same key. > > Reading up on CTS, I'm guessing the reason it's like this is that CTS is the > same as the non-CTS, except for the last two blocks, but the non-CTS one is > more efficient. The reason to use CTS is if you don't want to expand the size of the cipher text to the cipher block size. e.g., if you have a 53 byte plaintext, and you can't afford to let the ciphertext be 56 bytes, the cryptographic engineer will reach for CTS instead of CBC. So that probably explains the explanation to use CTS (and it's required by the spec in any case). As far as why CBC is being used instead of CTS, the only reason I can think of is the one you posted. Perhaps there was some hardware or software configureation where cbc(aes) was hardware accelerated, and cts(cbc(aes)) would not be? In any case, using cbc(aes) for all but the last two blocks, and using cts(cbc(aes)) for the last two blocks, is identical to using cts(cbc(aes)) for the whole encryption. So the only reason to do this in the more complex way would be because for performance reasons. - Ted