Storing Asymmetric Public Keys Using A Key Transparency Server

Feature name:

Using a Key Transparency Server To Allow Users to Securely Share Their Asymmetric Public Keys

Introduction

I honestly really like Daniel Douglas Soyka’s suggestion to store encrypted private keys on Bitwarden servers.
(Asymmetric Cryptography Cipher Support)

Just as Bitwarden can allow users to securely store their private keys on the Bitwarden Cloud, I think we should also give the owners the option to share their public keys on a Key Transparency Server. The concept of Key Transparency was introduced by Google and avoids all the abuse and spam associated with traditional key servers

(https://keytransparency.org).

Key Transparency servers use Merkle Tree data structures to ensure public keys have not been illegally tampered with using a Merkle Audit Proof on a public key.

Using the Merkle Tree data structure also ensures that public keys have only been appended to the Merkle Tree throughout the Merkle Tree’s editing history using a Merkle Consistency Proof.

(How Log Proofs Work - Certificate Transparency)

Google’s concept of Key Transparency also uses what is called a Verifiable Random Function so people can independtly verify that the public key they see associated with a user id is an authentic public key from said user.

Since the hash outputs of Verifiable Random Function outputs are indistinguishable from random without the proooof text, this helps protect the acccount owner’s privacy when sharing their public keys. Requesters for a user’s public key will have to request the user id from a user before they can retrieve the user’s public keys.

(keytransparency/design.md at master · google/keytransparency · GitHub)

Key Transparency would allow account owners to reliably see what public keys are associated with their identity.

And it would also give retrievers public keys reliable assurance that a public key indeed came from the claimed user.

(keytransparency/design.md at master · google/keytransparency · GitHub)

Clients / Repos Affected:

  • Server
  • Web
  • CLI
  • Desktop
  • Directory Connector

Timeline to completion (estimate):

ETA: Q12/2021