From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.gruenbichler@proxmox.com> 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 D81CB62214 for <pbs-devel@lists.proxmox.com>; Mon, 23 Nov 2020 09:48:26 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C8F9A25656 for <pbs-devel@lists.proxmox.com>; Mon, 23 Nov 2020 09:47:56 +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 5D26D2567F for <pbs-devel@lists.proxmox.com>; Mon, 23 Nov 2020 09:47:56 +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 2500B43E6E for <pbs-devel@lists.proxmox.com>; Mon, 23 Nov 2020 09:47:56 +0100 (CET) Date: Mon, 23 Nov 2020 09:47:49 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= <f.gruenbichler@proxmox.com> To: Dietmar Maurer <dietmar@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> References: <20201120163845.1225080-1-f.gruenbichler@proxmox.com> <20201120163845.1225080-10-f.gruenbichler@proxmox.com> <766783011.72.1606115268068@webmail.proxmox.com> <1606118041.ki3x6lhgym.astroid@nora.none> <1007194309.79.1606120260423@webmail.proxmox.com> In-Reply-To: <1007194309.79.1606120260423@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1606121065.6p62pfssso.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 <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Mon, 23 Nov 2020 08:48:26 -0000 On November 23, 2020 9:30 am, Dietmar Maurer wrote: >> 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. >=20 > Don't get that. You delete the fingerprint, so if a user restores that ke= y > he don't have a fingerprint to compare? the short key ID is put into the subject now to make human matching of=20 paperkey printouts and manifest/snapshot lists easier. if the user restores the paperkey into a keyfile, anytime that keyfile=20 is used it will re-generate the fingerprint on the fly. if the keyfile=20 is modified (e.g. on passphrase/KDF change), the generated fingerprint=20 will also be persisted again. we don't have a 'restore paperkey' command=20 (yet), but if we ever do, that could of course also regenerate the full=20 fingerprint and persist it on writing out the keyfile. =