Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1935702pxb; Wed, 2 Feb 2022 16:25:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8PucbZYOxiv45uZfJURE5r2hzMvhicskLb5GnXkDK622E/ShwJmfT0x5yzMprT1UEdT5H X-Received: by 2002:a05:6402:2754:: with SMTP id z20mr32696778edd.235.1643847911576; Wed, 02 Feb 2022 16:25:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643847911; cv=none; d=google.com; s=arc-20160816; b=iRj4qbYTLtvwfnR+/k2G6NOnc39xyUGMZNDuAEOh3Kn/uCGTgP9yI5UzEiRANFZcKW lBG2ccOcAdgzLT9LIBgji1aO1dKlTSqPERt4gguxvA4LIx1EJo7w5jOt/9F/sUP+lUL3 rclysVYyx7NvmNl/KjF8Swiri6ILZrDXuPXemASFaqZO3ifXnNNkGcPt1w80aJzO5IQO QOr6amnvhWiAqw8n6/fG7cfZf7E/5mMxnj8sbjc5KgpR9osTijEI1zluVusN7cwHAT7i hyhPDpTJAraUeWuV8NBsES7UX0kLbxHIvXc5ttaGDhvkk3KsFQbYkpUWuEsaNwMpNC/T hu0g== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=wrELo6UOpBF4ypmDq9o4PpfV46e6kRXXrXaJ9g1wRK4=; b=l193/iy5IRYOBNWB0EzCmoyEHSV7yfNQhPtXSjbMyUzYqgX4kxXLJX1sAMBR2Uwcs4 g3gDIxNHKAmjL2K9bszDx7mn5/NUU8oZCec2Xlsa++5ziR02DJmqo758BtI8OJG/s+Gw MAipaRk3FkWZnW1HT2iFU4pH7DK1JZV1E0kjlnAsBBoR72qiT9srdKYA7GJE6zJdTdfM yirE2Ee0Yj6JMSqLu4AdfbBCA4t5XC2RqzSqV8JiBR4JSNi9vIg31OH9NTtw6QbRmu4Y gT5vmhfprJIN51sIf1jXsyIkaTHRgnE1LZPhBVHv1gNH9E+DZ+Aqp6z7KGFxBgIg/BKb nHFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nc13si50769ejc.529.2022.02.02.16.24.36; Wed, 02 Feb 2022 16:25:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233357AbiBBWiI (ORCPT + 99 others); Wed, 2 Feb 2022 17:38:08 -0500 Received: from vmicros1.altlinux.org ([194.107.17.57]:53386 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232825AbiBBWiI (ORCPT ); Wed, 2 Feb 2022 17:38:08 -0500 Received: from imap.altlinux.org (imap.altlinux.org [194.107.17.38]) by vmicros1.altlinux.org (Postfix) with ESMTP id EAAFB72C8FA; Thu, 3 Feb 2022 01:38:06 +0300 (MSK) Received: from altlinux.org (sole.flsd.net [185.75.180.6]) by imap.altlinux.org (Postfix) with ESMTPSA id CA0FC4A46F0; Thu, 3 Feb 2022 01:38:06 +0300 (MSK) Date: Thu, 3 Feb 2022 01:38:06 +0300 From: Vitaly Chikunov To: keyrings@vger.kernel.org, Jarkko Sakkinen , David Howells , linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, Eric Biggers Cc: Stefan Berger Subject: Re: [RFC PATCH] KEYS: Double max_size to make keyctl pkey_verify work Message-ID: <20220202223806.bcfsjtr472kl3jj3@altlinux.org> References: <20220202065906.2598366-1-vt@altlinux.org> <5bb23626-afe1-9e05-566b-8830882904f6@linux.ibm.com> <20220202212437.mlj4cta4voqiqfpf@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220202212437.mlj4cta4voqiqfpf@altlinux.org> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Feb 03, 2022 at 12:24:37AM +0300, Vitaly Chikunov wrote: > Stefan, > > On Wed, Feb 02, 2022 at 07:55:43AM -0500, Stefan Berger wrote: > > On 2/2/22 01:59, Vitaly Chikunov wrote: > > > Rarely used `keyctl pkey_verify' can verify raw signatures, but was > > > failing, because ECDSA/EC-RDSA signature sizes are twice key sizes which > > > does not pass in/out sizes check in keyctl_pkey_params_get_2. > > > This in turn because these values cannot be distinguished by a single > > > `max_size' callback return value. > > > Also, `keyctl pkey_query` displays incorrect `max_sig_size' about these > > > algorithms. > > > > > > Signed-off-by: Vitaly Chikunov > > > > How do you use pkey_query? > > > > $ keyctl padd asymmetric testkey %keyring:test < cert.der > > 385037223 > > It should be (for RSA key): > > keyctl pkey_query 385037223 0 enc=pkcs1 hash=sha256 > > `0` is placeholder for a password. > > For example, I generated keys with your eckey-testing/generate.sh, and > pkey_query after this patch is applied: > > # keyctl padd asymmetric "" @u < ecdsa-ca/ca.crt.der > 66509339 > # keyctl pkey_query 66509339 0 enc=x962 hash=sha256 > key_size=256 > max_data_size=64 > max_sig_size=64 > max_enc_size=32 > max_dec_size=32 I just thought, we can also set these to 0 if encrypt/decrypt is not enabled. Currently, there is no way to detect that encrypt is not possible, except by extending that if (strcmp...), but if we going to have it, why not correct other info too? Thanks, > encrypt=y > decrypt=n > sign=n > verify=y > > W/o patch max_data_size= and max_sig_size= will be 32. > > Thanks, > > > $ keyctl pkey_query 385037223 '' > > Password passing is not yet supported > > $ keyctl pkey_query 385037223 > > Format: > > ? keyctl --version > > ? keyctl add > > [...] > > > > $ keyctl unlink 385037223 > > 1 links removed > >