Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4977492ybf; Wed, 4 Mar 2020 14:45:01 -0800 (PST) X-Google-Smtp-Source: ADFU+vsc4eeS6kw9aUjvktsXWln4B0MeWb7vRVaCOUlJcFUogwnU62B2NoZeT/oRt8FU2WDZut/N X-Received: by 2002:a05:6808:315:: with SMTP id i21mr3269487oie.139.1583361901746; Wed, 04 Mar 2020 14:45:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583361901; cv=none; d=google.com; s=arc-20160816; b=v+boiyJS/bIloBX4b5/P25AHZiEB02n2nXprjVXe/WkFrn7gXG3RwAUwX4blosgzD7 AxXZAylPrBAMtVaZpaA/wTEE2ovpK/tJcyqii2OxZbQIkij0nWbpHUPRHBdfTHjpin0A WukDtmaxG/tCAZRvHCOexlJ6hboftoae46+VpVtD/Wb0uW4c/3Rh2gJu9m7lrTzWbKAe VpttdOlKAk5IrfHyWIqSAmv+KKDu/o1O8+WeqMI245DUcq5+2bQ1viNERxwdUuGfgh1X +rimGm1kKYUA8FeNe0fcrLwfc98DQ6pH8Y2Z5bBmIjGH5RHtrQCwQ43bKy1di4OIa9TJ VE8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=tau8OLgCOBymNb7yyg6qtVAze5Sgl84vYGkoDP3WMkA=; b=EZJ85p25XzsIOWnh9itiun2AJTOUkAwBk0KEit/h92+Hr4U7pA0HKcvNbGagHmN1ZC DFTrr+CyXYFLn0pPuNsioRoCRIs89+U0jzMS5fXtE1koO6eaHONNM6QFmsSlFNwd2nS6 PeJLvmCXfOkvsbSTWSSJ6EOgTzq/rOUBH+SzV9Ttr8AfGZi7SwGgfWDWiQmdXG//tSlC t+JQJj3ArqD3froOGY6Y7owffppkKh2JpPkzgvgIDmWTrVw/60+DGXq/1lkUJctunOUy 1wBn14gLFI6Af5LFys4Uf2KWNbXmYOBlttGOUOq4PsQPegMgKc5BzHJwACS39FmKnMUR CunA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Kmkqd2WG; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l5si2056366otn.35.2020.03.04.14.44.42; Wed, 04 Mar 2020 14:45:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Kmkqd2WG; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387931AbgCDWoj (ORCPT + 99 others); Wed, 4 Mar 2020 17:44:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:49318 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388400AbgCDWoj (ORCPT ); Wed, 4 Mar 2020 17:44:39 -0500 Received: from sol.hsd1.ca.comcast.net (c-107-3-166-239.hsd1.ca.comcast.net [107.3.166.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B230320870; Wed, 4 Mar 2020 22:44:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583361877; bh=guigaYqeraIW/KayIP4VoOTQFQRQPlX7LdTXIVH60aE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kmkqd2WGrV47Tl4gA5Py5Ekkg47qDew7I+b7VxYdOQpIWz+z2Hx3q8Taf9W6mLtJO aduwFAxuQQqGBYpntgdUrhRgWsPKAaS9ZooAQ5r9xtOrG+txk2wxXdQE03DlbLPXpv w6eKjEsiuE8qYw4tvrlaIYaWz1HJZKw/ZIIL1dxk= From: Eric Biggers To: linux-crypto@vger.kernel.org Cc: Gilad Ben-Yossef , Stephan Mueller Subject: [PATCH 3/3] crypto: aead - improve documentation for scatterlist layout Date: Wed, 4 Mar 2020 14:44:05 -0800 Message-Id: <20200304224405.152829-4-ebiggers@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200304224405.152829-1-ebiggers@kernel.org> References: <20200304224405.152829-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org From: Eric Biggers Properly document the scatterlist layout for AEAD ciphers. Reported-by: Gilad Ben-Yossef Cc: Stephan Mueller Signed-off-by: Eric Biggers --- include/crypto/aead.h | 48 ++++++++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 21 deletions(-) diff --git a/include/crypto/aead.h b/include/crypto/aead.h index 1b3ebe8593c0..62c68550aab6 100644 --- a/include/crypto/aead.h +++ b/include/crypto/aead.h @@ -43,27 +43,33 @@ * * Memory Structure: * - * To support the needs of the most prominent user of AEAD ciphers, namely - * IPSEC, the AEAD ciphers have a special memory layout the caller must adhere - * to. - * - * The scatter list pointing to the input data must contain: - * - * * for RFC4106 ciphers, the concatenation of - * associated authentication data || IV || plaintext or ciphertext. Note, the - * same IV (buffer) is also set with the aead_request_set_crypt call. Note, - * the API call of aead_request_set_ad must provide the length of the AAD and - * the IV. The API call of aead_request_set_crypt only points to the size of - * the input plaintext or ciphertext. - * - * * for "normal" AEAD ciphers, the concatenation of - * associated authentication data || plaintext or ciphertext. - * - * It is important to note that if multiple scatter gather list entries form - * the input data mentioned above, the first entry must not point to a NULL - * buffer. If there is any potential where the AAD buffer can be NULL, the - * calling code must contain a precaution to ensure that this does not result - * in the first scatter gather list entry pointing to a NULL buffer. + * The source scatterlist must contain the concatenation of + * associated data || plaintext or ciphertext. + * + * The destination scatterlist has the same layout, except that the plaintext + * (resp. ciphertext) will grow (resp. shrink) by the authentication tag size + * during encryption (resp. decryption). + * + * In-place encryption/decryption is enabled by using the same scatterlist + * pointer for both the source and destination. + * + * Even in the out-of-place case, space must be reserved in the destination for + * the associated data, even though it won't be written to. This makes the + * in-place and out-of-place cases more consistent. It is permissible for the + * "destination" associated data to alias the "source" associated data. + * + * As with the other scatterlist crypto APIs, zero-length scatterlist elements + * are not allowed in the used part of the scatterlist. Thus, if there is no + * associated data, the first element must point to the plaintext/ciphertext. + * + * To meet the needs of IPsec, a special quirk applies to rfc4106, rfc4309, + * rfc4543, and rfc7539esp ciphers. For these ciphers, the final 'ivsize' bytes + * of the associated data buffer must contain a second copy of the IV. This is + * in addition to the copy passed to aead_request_set_crypt(). These two IV + * copies must not differ; different implementations of the same algorithm may + * behave differently in that case. Note that the algorithm might not actually + * treat the IV as associated data; nevertheless the length passed to + * aead_request_set_ad() must include it. */ struct crypto_aead; -- 2.25.1