[pbs-devel] [PATCH proxmox-backup 09/13] paperkey: add short key ID to subject

[Fabian Grünbichler]

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!
>> 
>> the key (on disk) is 8 + 8 + 8 + 32 (key derivation) + 64 (encrypted key 
>> data) + 8 + 8 (timestamps), totalling 136 bytes. serialized it's a bit 
>> more, although there the fingerprint skews the numbers more heavily 
>> (because I opted for a readable serialization, not one optimized for 
>> size). even in-memory, the key is not 32-byte long, but 32+32+however 
>> long the PKey struct from openssl is.
> 
> For the record, the fingerprint is computed using 32 secret bytes (not more). 
> 
> Note: FINGERPRINT_INPUT is const
> 
> +    pub fn fingerprint(&self) -> Fingerprint {
> +        Fingerprint {
> +            bytes: self.compute_digest(&FINGERPRINT_INPUT)
> +        }
> +    }
> +
> 
>     pub fn compute_digest(&self, data: &[u8]) -> [u8; 32] {
>         let mut hasher = openssl::sha::Sha256::new();
>         hasher.update(data); // this is const
>         hasher.update(&self.id_key); // this is 32 bytes
>         hasher.finish()
>     }
> 
> 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 
and in-memory, both for the FULL key). yes, the PART of the key that is 
used to calculated digests (and the fingerprint) is only 32 bytes. my 
argument is that for both on-disk and in-memory, adding a full 32 bytes 
fingerprint does not 'double' the size, as you imply, since the 
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 
"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 
  magnitude anyway)

while storing the full one has advantages:
- fingerprint has same level of security as chunk digest (if that breaks 
  everything is broken anyway!), allowing us to base non-informational 
  features on it as well (such as Qemu key tracking for bitmap 
  invalidation)
- we can change how to display it in the future and still have the full 
  value to derive the display value from