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 E550D62201 for ; Mon, 23 Nov 2020 09:17:32 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D85AC24C74 for ; Mon, 23 Nov 2020 09:17:02 +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 6325524C6A for ; Mon, 23 Nov 2020 09:17:02 +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 2BB7F43E9C for ; Mon, 23 Nov 2020 09:17:02 +0100 (CET) Date: Mon, 23 Nov 2020 09:16:43 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dietmar Maurer , Proxmox Backup Server development discussion References: <20201120163845.1225080-1-f.gruenbichler@proxmox.com> <20201120163845.1225080-10-f.gruenbichler@proxmox.com> <766783011.72.1606115268068@webmail.proxmox.com> In-Reply-To: <766783011.72.1606115268068@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1606118041.ki3x6lhgym.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.025 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 09/13] paperkey: add short key ID to subject 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: Mon, 23 Nov 2020 08:17:32 -0000 On November 23, 2020 8:07 am, Dietmar Maurer wrote: >=20 >> + Ok(mut key_config) =3D> { >> + // add display version of fingerprint to subject and st= rip from key data >> + let subject =3D match (subject, key_config.fingerprint.= take()) { >> + (Some(mut subject), Some(fingerprint)) =3D> { >> + subject.push_str(&format!(" ({})", fingerprint)= ); >> + Some(subject) >> + }, >> + (None, Some(fingerprint)) =3D> Some(format!("Finger= print: {}", fingerprint)), >> + (subject, _) =3D> subject, >> + }; >> + >=20 > I still don't get why we need a 32byte fingerprint - this is the same len= gth as the key itself! the key (on disk) is 8 + 8 + 8 + 32 (key derivation) + 64 (encrypted key=20 data) + 8 + 8 (timestamps), totalling 136 bytes. serialized it's a bit=20 more, although there the fingerprint skews the numbers more heavily=20 (because I opted for a readable serialization, not one optimized for=20 size). even in-memory, the key is not 32-byte long, but 32+32+however=20 long the PKey struct from openssl is. I want to have the "full" fingerprint because we persist this in places=20 where we can't (easily) update it, so it's more future-proof to keep the=20 full value there. it also makes it possible to use the full value for=20 the actual comparison done on manifest load/check (where we not only=20 have to think about collisions for a single user, but potentially=20 hundreds/thousands if they share a datastore!). > I want to avoid having keys with different content (strip fingerprint), b= ecause this only > confuse people. I originally wanted to keep the full fingerprint in, but conceded to=20 your space arguments here and only included the short version.. I also=20 don't really buy the confusion, since unless the user has manually=20 looked inside the key file they don't even know that or how the=20 fingerprint is stored there - in the user-facing parts we only ever show=20 the short key ID. furthermore we already paperkey the pretty-printed=20 version so if the user restores that the checksum of the keyfile is=20 different anyhow. =