Practical Distributed Secret Management System

Abstract
The paper describes a practical distributed secret management system for multiple use cases.

A secret management system designed to securely store and manage passwords/secrets for
various online accounts and services. It typically stores secrets in an encrypted database, and
allows users to generate complex and unique passwords for each account, making it easier to
maintain strong passwords without having to remember them all.

Secret management systems are very popular but inconvenient that users must trust a single
vendor. We suggest a distributed secret management system which utilized multiple
cryptography schemes and optimized for being used in practice.

Introduce

Related Works

Security Assumptions

The System Architecture

The Protocol

A. Key Generation
Feldman's Verifiable Secret Sharing (VSS) protocol is a cryptographic protocol used to securely
share a secret among a group of participants, while ensuring that the secret remains secret and
that each participant can verify that they have received a correct share.

Key Generation works as follows:

- Setup: Vendors agree on the number of participants n, threshold t, specific Elliptic curve of
cardinality N, generator G.

- Each Vendor Vi generates a random polynomial of degree t-1, such that f(0) is equal to his
secret.
2 𝑡−1
𝑓𝑖(𝑥) = 𝑠𝑒𝑐𝑟𝑒𝑡𝑖 + 𝑎𝑖1 * 𝑥 + 𝑎𝑖2 * 𝑥 +... + 𝑎𝑖(𝑡−1)𝑥 𝑚𝑜𝑑 𝑁

Vi then creates commitment & decommitment,

Commit = hash(random byte r || G*secreti || G*ai1 || … || G*ai (t-1))
Decommit is a list [random byte r, G*secreti, G*ai1, … , G*ai (t-1)]
And broadcast Commit, Ei (public key for an additively homomorphic encryption scheme, for
example Pallier cryptosystem).
- Each Vendor Vi sends a share to Vendor Vj , and broadcasts Decommit so that Vj can verify
their share.

- Each Vendor Vi adds the private shares received during the Feldman VSS protocol, 𝑢𝑉𝑖 = ∑ 𝑢𝑖

(note that the public key G*uVi is public). The public key EcdsaPub and other peers’ public keys
can be derived from the Decommit.
- Each Vendor uses RSA modulus associated with Ei to prove that he knows uVi using Schnorr
protocol.

B. Key Shuffle and Key Resharing

Use Case: Keep the current EcdsaPub and shared secret when updating the number of
Vendors / threshold / renew shares / share recovery if some vendors lose their share.

Note: at least t old Vendors join the protocol to reconstruct the shared secret - The Old Vendors
set. The set of New Vendors can contain multiple participants from the old set or not.

Denote:
- n, n’: number of participants
- t, t’: threshold
- ks, ks’: abscissa coordinate, used for evaluating polynomials. ks = {ki}, ks’ = {k’i}

Key Resharing works as follows:

𝑘𝑗
- Each old Vendor Vi computes 𝑤𝑉𝑖 = 𝑢𝑉𝑖 ∏ 𝑘𝑗−𝑘𝑖
𝑗≠𝑖
Vi generates a random polynomial of degree t’-1, such that f(0) is equal to his wVi:
2 𝑡'−1
𝑓𝑖(𝑥) = 𝑤𝑉𝑖 + 𝑎𝑖1 * 𝑥 + 𝑎𝑖2 * 𝑥 +... + 𝑎𝑖(𝑡−1)𝑥 𝑚𝑜𝑑 𝑁
Vi then creates commitment & decommitment,
Commit = hash(random byte r || G*wVi || G*ai1 || … || G*ai (t’-1))
Decommit is a list [random byte r, G*wVi, G*ai1, … , G*ai (t’-1)]

Each old Vendor then broadcasts to new Vendors the current EcdsaPub and Commit. New
vendors must verify if all received EcdsaPub are the same.
- Each new Vendor broadcasts Ei to the new set (Ei is the public key for an additively
homomorphic encryption scheme, for example Pallier cryptosystem).
- Each old Vendor Vi sends a share to the new Vendor Vj , and broadcasts Decommit so that Vj
can verify their share.
- Each new Vendor Vi adds the private shares received during the Feldman VSS protocol,

𝑢𝑉𝑖 = ∑ 𝑢𝑖 (note that the public key G*uVi is public). The public key EcdsaPub and other peers’

public keys can be derived from the Decommit.. They must verify that the derived EcdsaPub is
equal to the EcdsaPub received above.

C. Secret Storing
Suppose a client Alice wants to store her secret message using a distributed secret
management system (DSM).
Alice then first gets the public key EcdsaPub of the DSM system and encrypts the message as
follows:

MPCencrypt(message, EcdsaPub):
r = Random number
R = G*r
Ar = EcdsaPub*r
key = KDF(Ar)
ciphertext = SymmetricEncrypt(message, key)
return R, ciphertext

To decrypt the ciphertext, one must construct R * shared_secret to recover Ar.

𝐴𝑟 = 𝐸𝑐𝑑𝑠𝑎𝑃𝑢𝑏 * 𝑟 = (𝐺 * 𝑠ℎ𝑎𝑟𝑒𝑑_𝑠𝑒𝑐𝑟𝑒𝑡) * 𝑟 = 𝑅 * 𝑠ℎ𝑎𝑟𝑒𝑑_𝑠𝑒𝑐𝑟𝑒𝑡

Alice then now stores her encrypted secret on the DSM system by broadcasting the pair (R,
ciphertext) to all the Vendors.

D. Secret Reconstruction
Alice can construct her secret message by retrieving (R*uVi, ciphertext) from at least t Vendors.
The response here is R multiply with the Vendor’s secret uVi, so if Alice collects enough {R*uVi},
she can compute R * shared_secret by using lagrange interpolation.

𝑅 * 𝑠ℎ𝑎𝑟𝑒𝑑_𝑠𝑒𝑐𝑟𝑒𝑡 = ∑ 𝑅 * 𝑙𝑖(0)
𝑖
Once Alice has R * shared_secret, she can decrypt the ciphertext as follows:
// Ra = R*shared_secret
MPCdecrypt(ciphertext, Ra):
 key = KDF(Ra)
message = SymmetricDecrypt(ciphertext, key)
return message

The security issues raise here, if someone retrieves enough (R*uVi, ciphertext) on behalf of
Alice, he can compute the decryption key and know her secret.
We need to add an authentication step to identify who is interacting with the Vendor (like
OAuth,...).
What if the Vendor itself is malicious, the malicious Vendor can impersonate clients by storing
their valid tokens and then interact with other Vendors.

The problem can be solved by using an authentication OAuth-zk scheme.

First Alice logins her social account (like Google, Reddit,...), then receives an OAuth token. Alice
now provides {Public key, m, r} extracted from the token, and proves the Vendor that she knows
s corresponding to the {Public key, m, r} -> Schnorr protocol

E. Cheat Detection

References
- Rosario Gennaro and Steven Goldfeder: Fast Multiparty Threshold ECDSA with Fast Trustless Setup -
https://eprint.iacr.org/2019/114.pdf