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 E8BC86229F for ; Mon, 23 Nov 2020 10:45:00 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DE90226E31 for ; Mon, 23 Nov 2020 10:45:00 +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 5C1A026E26 for ; Mon, 23 Nov 2020 10:45:00 +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 1B57E43E9D for ; Mon, 23 Nov 2020 10:45:00 +0100 (CET) Date: Mon, 23 Nov 2020 10:44:53 +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> <1606118041.ki3x6lhgym.astroid@nora.none> <278118200.83.1606121751476@webmail.proxmox.com> In-Reply-To: <278118200.83.1606121751476@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1606122896.y0e8ygbcq2.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.024 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 09:45:01 -0000 On November 23, 2020 9:55 am, Dietmar Maurer wrote: >> > I still don't get why we need a 32byte fingerprint - this is the same = length as the key itself! >>=20 >> 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. >=20 > For the record, the fingerprint is computed using 32 secret bytes (not mo= re).=20 >=20 > Note: FINGERPRINT_INPUT is const >=20 > + pub fn fingerprint(&self) -> Fingerprint { > + Fingerprint { > + bytes: self.compute_digest(&FINGERPRINT_INPUT) > + } > + } > + >=20 > pub fn compute_digest(&self, data: &[u8]) -> [u8; 32] { > let mut hasher =3D openssl::sha::Sha256::new(); > hasher.update(data); // this is const > hasher.update(&self.id_key); // this is 32 bytes > hasher.finish() > } >=20 > So the fingerprint has exactly the same size as the secret key. > I really do not understand your arguments... I specifically wrote what my numbers refer to (structures kept on-disk=20 and in-memory, both for the FULL key). yes, the PART of the key that is=20 used to calculated digests (and the fingerprint) is only 32 bytes. my=20 argument is that for both on-disk and in-memory, adding a full 32 bytes=20 fingerprint does not 'double' the size, as you imply, since the=20 fingerprint is for the full key and not just the derived ID key part. if everybody besides me thinks that storing the truncated 8 byte=20 "fingerprint" is a good idea, then I can send a v3 that does that. IMHO we don't have much to gain by storing it truncated: - key files are a bit smaller (they are client-side only anyway) - manifests are a bit smaller (they are in a different order of=20 magnitude anyway) while storing the full one has advantages: - fingerprint has same level of security as chunk digest (if that breaks=20 everything is broken anyway!), allowing us to base non-informational=20 features on it as well (such as Qemu key tracking for bitmap=20 invalidation) - we can change how to display it in the future and still have the full=20 value to derive the display value from =