From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 32EFD60A9F for ; Wed, 18 Nov 2020 09:28:09 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 220A618A07 for ; Wed, 18 Nov 2020 09:27:39 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id A3766189FD for ; Wed, 18 Nov 2020 09:27:38 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 6A3D8438F0 for ; Wed, 18 Nov 2020 09:27:38 +0100 (CET) Date: Wed, 18 Nov 2020 09:27:31 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dietmar Maurer , Proxmox Backup Server development discussion , Thomas Lamprecht References: <20201117175725.3634238-1-f.gruenbichler@proxmox.com> <1774426658.212.1605677252807@webmail.proxmox.com> <645547754.213.1605678469368@webmail.proxmox.com> <6447caa6-7079-4515-af39-4322fdd8a69f@proxmox.com> In-Reply-To: <6447caa6-7079-4515-af39-4322fdd8a69f@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1605687788.575q13vngv.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup 0/7] add, persist and check key fingerprint X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 08:28:09 -0000 On November 18, 2020 7:47 am, Thomas Lamprecht wrote: > On 18.11.20 06:47, Dietmar Maurer wrote: >>> On 11/18/2020 6:27 AM Dietmar Maurer wrote: >>> >>> =20 >>> Do we really need/want a 256bit long fingerprint? >>> >>> I thought 64bit (or maybe 32bit) would be large enough? >>> If not, why does it have to be that large? >>=20 >> some quick math: >>=20 >> max keys a user generate in his live: 1024 (2=C2=B9=E2=81=B0) >>=20 >> so the likelihood of a 32bit fingerprint clash is=20 >>=20 >> W =3D 1/2^=C2=B2=C2=B2 (1/4Millions) >>=20 >> which is, unlikely, but possible. >>=20 >> But with 64bit it is extremely unlikely (1/2=E2=81=B5=E2=81=B4). >=20 > From a pure user experience I think it could be better to present 8 byte = of fingerprint > information - as the nerves/stress ratio is probably not to good at times= where this is > required. >=20 > 8 byte: "90:A1:CA:44:BE:0B:D4:1C" >=20 > vs. >=20 > 32 byte: "90:A1:CA:44:BE:0B:D4:1C:F7:D9:F5:2F:7C:92:DB:69:B2:2A:AF:6A:1C:= 7A:DB:0C:03:93:3E:EA:95:EC:26:92" >=20 > I mean, after all, this is rather informal and even if there would be a u= nlikely > collision it does not actually compromises security in any way I can thin= k of. I'd be fine with that, although I think we should probably mention=20 somewhere why we think it's fine to use a truncated hash here: - the actual verification happens via the signature of the manifest - we are talking about your own keys, not keys of other parties that you=20 need to verify via a fingerprint (which is an entirely different=20 problem) - the fingerprint is just used as an automatically/mathematically=20 generated 'name' of the key should we switch it altogether, or just truncate it on display? IMHO for=20 Qemu I'd like to keep the full digest/fingerprint, since there a=20 skipped collision means corrupt backups, not running into the next=20 error and bailing out.. =