Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2880823pxb; Thu, 3 Feb 2022 17:18:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkMO4IMF9wYsYrdL7yCPXXq5VcWWxectSq3P2RfobAb2ZxyWDcCNN9TR839qMWN5+HtXMD X-Received: by 2002:a17:907:2d0d:: with SMTP id gs13mr471336ejc.161.1643937492946; Thu, 03 Feb 2022 17:18:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643937492; cv=none; d=google.com; s=arc-20160816; b=Mgrh36PTZnRUPFkJkyoIbjGQrXANV+wMsqrbgzTF5Iser6pgKA0Nn/xU94zQ2OC5rI UDohfdMc8dLW32iKq5jCWz+fSZpkRIFof3L6oh3vgu6jG0mB3lLxClvQ1iro7evavbE/ 8G8I5cGqgOTl95prqjRBQCeZapJnOXXyTXds+OVrM5HTv/9BlaGJAzNfuyG899iyGi3L ouISiSo1Q326O4s9UTRhX2FHQgH/h+LHXvl/wzXFudV0w2vG8QLoZ8mV3tXkn2XRhGfP /2i2Xt6AgGO/Wxu9DcQHeI3TyJDmHOos50OG+dm5zowZ/wklf3eWLmw+7TcW14/fBaK5 o0BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=UEW5qdexga0BMBxV6tALb0iSs2cti1jehdUOsK8BHUk=; b=AGSsLXuRKe+MH8jiolGkJy8FzKWFd46wEPPFlG4blC82Oho+6yOdcOAmHIXV/Gy3Gu VM082Db+VZREv3v8pWbOi4UuWGgwwsdpxr6rIUaub3LeJot7kHWXTg4y6KJ7nEC4Xp+j g/YoGGdw/S361/MlFx+UucC+uU+KZAc2+HYKf/S82SgiAxiDI2Ss8a7Sz6fBXioU7YGn Xla7MZEbzULmtE4kJgIJOvewLQwd6dJurmQ2a0o+0uLxvY2FVXvyZaBJ1kP0mLA3U+8H Tq2b3/aNIQAbQccDJIwP/4s5j7NcDcTvsY9IUrmLkgRTSFpEakhF3VWpkboNjEMaqfMC +6Xw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b="CZKl5P/w"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk13si254179ejc.978.2022.02.03.17.17.49; Thu, 03 Feb 2022 17:18:12 -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; dkim=pass header.i=@ibm.com header.s=pp1 header.b="CZKl5P/w"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244277AbiBCDPd (ORCPT + 99 others); Wed, 2 Feb 2022 22:15:33 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:8238 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236168AbiBCDPc (ORCPT ); Wed, 2 Feb 2022 22:15:32 -0500 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 212NBHVE002741; Thu, 3 Feb 2022 03:15:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=UEW5qdexga0BMBxV6tALb0iSs2cti1jehdUOsK8BHUk=; b=CZKl5P/wNbvVpabHpHTBoAKSwQhU2alqhOAhwhx3VP950KPkS5ODa/dzqQ/hpOc1vtEt /eJ0SCUUodhkji32J610Q8HZ4AyoS0dWsTs82avFJOpv4T5QTINJPifwTYJCetAP4mW/ yQgM4xg3yt/AcBptp9m8nWgwixGwpj/IDPT/weIqE3CuFb56LTokK+l1XEmid40JVPOo fD8GrN5ewabt+Jtn/CMGXRmlLSuludhqdWafvxA1TOqZ0qlG8m6EeWP4HM9TaQ2iWcx/ 8w9+hcuk44houdSRuFcR1f3uM229drfRRSlAvCcDQfbiY3u+82MDBeUzTr7EXy95CUFP WA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3dywrr9nq7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 03:15:27 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 2133FR1I002281; Thu, 3 Feb 2022 03:15:27 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0b-001b2d01.pphosted.com with ESMTP id 3dywrr9npx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 03:15:27 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2133CTxU011042; Thu, 3 Feb 2022 03:15:26 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma03dal.us.ibm.com with ESMTP id 3dy0sxg8m3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 03:15:26 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2133FPMD37028272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Feb 2022 03:15:25 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3D1F8136068; Thu, 3 Feb 2022 03:15:25 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C66C6136069; Thu, 3 Feb 2022 03:15:24 +0000 (GMT) Received: from [9.47.158.152] (unknown [9.47.158.152]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 3 Feb 2022 03:15:24 +0000 (GMT) Message-ID: <7c9d973f-847e-e8bc-95fb-6c98a98a02e6@linux.ibm.com> Date: Wed, 2 Feb 2022 22:15:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [RFC PATCH] KEYS: Double max_size to make keyctl pkey_verify work Content-Language: en-US To: Vitaly Chikunov , keyrings@vger.kernel.org, Jarkko Sakkinen , David Howells Cc: linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org, Eric Biggers References: <20220202065906.2598366-1-vt@altlinux.org> From: Stefan Berger In-Reply-To: <20220202065906.2598366-1-vt@altlinux.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: cHMRdbgrwzIQyuoLYea7KytJG9MXHcKr X-Proofpoint-GUID: 3aVh1MEXsKOUAwUkzUOAmiqbVJGwinOj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-02_11,2022-02-01_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 clxscore=1015 impostorscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202030014 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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 > --- > crypto/asymmetric_keys/public_key.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c > index 4fefb219bfdc..3ffbab07ed2a 100644 > --- a/crypto/asymmetric_keys/public_key.c > +++ b/crypto/asymmetric_keys/public_key.c > @@ -143,8 +143,19 @@ static int software_key_query(const struct kernel_pkey_params *params, > > len = crypto_akcipher_maxsize(tfm); > info->key_size = len * 8; > - info->max_data_size = len; > - info->max_sig_size = len; > + if (strcmp(alg_name, "ecrdsa") == 0 || > + strncmp(alg_name, "ecdsa-", 6) == 0) { > + /* > + * For these algos sig size is twice key size. > + * keyctl uses max_sig_size as minimum input size, and > + * max_data_size as minimum output size for a signature. > + */ > + info->max_data_size = len * 2; > + info->max_sig_size = len * 2; I don't know about the data size but following my tests this is not enough for ECDSA signature size. In ECDSA case the r and s components of the signature are encode in asn.1, not 'raw'. So there are 2 bytes at the beginning for sequence identifier , 2 bytes asn.1 for the r component, 1 additional 0-byte to make the r component always a positive number, then the r component, then 2 bytes asn.1 for the s component, 1 addition 0-byte to make the s component a positive number, then the s component. Phew. info->max_sig_size = 2 + (2 + 1 + len) * 2; so for NIST P384 it's: 2 + (2+1+48) * 2 = 104 Then it works for me as well. > + } else { > + info->max_data_size = len; > + info->max_sig_size = len; > + } > info->max_enc_size = len; > info->max_dec_size = len; > info->supported_ops = (KEYCTL_SUPPORTS_ENCRYPT |