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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CCDE4C433F5 for ; Thu, 13 Jan 2022 23:28:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B737A8319A; Fri, 14 Jan 2022 00:28:46 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="lCma5n3t"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A26D3831F0; Fri, 14 Jan 2022 00:28:44 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by phobos.denx.de (Postfix) with ESMTP id F420281429 for ; Fri, 14 Jan 2022 00:28:41 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=dphadke@linux.microsoft.com Received: from [192.168.86.154] (unknown [50.47.106.53]) by linux.microsoft.com (Postfix) with ESMTPSA id 3B53520B8001; Thu, 13 Jan 2022 15:28:40 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3B53520B8001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1642116520; bh=26iTa2l8fXxVypxZfdQp/Qi6m/snF5+YpaghBcZOYa4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lCma5n3t3EuCWPoAqWB9oc5cOi7u2luYnjKRNcLt68CxytC+hzwM1sPhlbajKFwXz D10KMesS1ALsgqEyVeuj0saukLoAhXO1SWbPgxYCdZA73V7Kpm8fW7pElU1I2DnhZ4 EvSV1sIYkKbNrcpHgoObhIgxiWyrmMwGYv0d/xlg= Message-ID: Date: Thu, 13 Jan 2022 15:28:40 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 0/3] mkimage: allow to specify signing algorithm Content-Language: en-US To: Jan Kiszka , U-Boot Mailing List , Simon Glass Cc: Ivan Mikhaylov References: <276812c9-80e6-c430-c1cf-c19566accc02@siemens.com> From: Dhananjay Phadke In-Reply-To: <276812c9-80e6-c430-c1cf-c19566accc02@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 1/13/2022 4:38 AM, Jan Kiszka wrote: > On 25.11.21 20:03, Jan Kiszka wrote: >> Another step to decouple the FIT image specification from the actual >> signing: With these changes, the signature nodes can leave out an algo >> property, mkimage will initialize that as well while signing. This way, >> in-tree FIT source files can be prepared for gaining signatures without >> defining the key type or size upfront, forcing users to patch the code >> to change that. [resend to the list] While encryption algo (rsa2048 vs rsa4096, etc) shouldn't need to be explicitly specified as you noted below, how does it help to add it to (already exhaustive) mkimage args? Parsing OID / length from keyfile would be real change. While rotating keys is common, how often algo is changed? >> >> Patch 1 is preparatory for this, patch 2 a drive-by cleanup. >> >> A better solution would actually be if the algorithm was derived from >> the provided key. But the underlying crypto layer seems to be rather >> unprepared for that. Thanks, DHananjay