How did you select this vendor?
We interviewed the developers and decided to give it a try. After 2 successful 2 week sprints we decided to extend our collaboration. That is how we select all our vendors. It is easy and less costly than lengthy selection processes.
Describe the project and the services they provided in detail.
DID Flow The following will describe the process of both Public and Private Claim generation and verification. Private claims involve ZKP to obfuscate the content of claim fields from third parties (verifiers). Detailed description of ZKP Protocol
Security considerations: The Schnorr identification protocol has been proven to satisfy the following properties, assuming that the verifier is honest and the discrete logarithm problem is intractable (Stinson, 2006).
- Completeness - a prover who knows the discrete logarithm is always able to pass the verification challenge.
- Soundness - an adversary who does not know the discrete logarithm has only a negligible probability (i.e., 2^(-t)) to pass the verification challenge.
- Honest verifier zero-knowledge - a prover leaks no more than one bit of information to the honest verifier: whether the prover knows the discrete logarithm.
The Fiat-Shamir transformation is a standard technique to transform a three-pass interactive Zero-Knowledge Proof protocol (in which the verifier chooses a random challenge) to a non-interactive one, assuming that there exists a secure cryptographic hash function.
Since the hash function is publicly defined, the prover is able to compute the challenge by itself, hence making the protocol noninteractive. In this case, the hash function (more precisely, the random oracle in the security proof) implements an honest verifier, because it assigns a uniformly random challenge c to each commitment (g^v or G x [v]) sent by the prover.
This is exactly what an honest verifier would do. It is important to note that in Schnorr's identification scheme and its non-interactive variant, a secure random number generator is REQUIRED. In particular, bad randomness in v may reveal the secret discrete logarithm.
Basic Flow of the Protocol Let g be a generator of a cyclic group of prime-order q. L e t f b e t h e f i e l d v a l u e o f t h e c l a i m . The goal is to convert the field value to a keypair, whereby the obfuscated field value represents the private key (secret), and the public key can be shared with the verifier. To generate a keypair, Alice would take the field value f and concatenate with a random integer (salting). Salted value will be then hashed to a random integer a between 1 and q. The keypair is computed as follows: PKA = g = a mod q, SKA a PK can be published to the world.
To prove the verifier that the secret associated with the public key is known, the following n o n - i n t e r a c t i v e protocol is performed: A l i c e g e n e r a t e s a r a n d o m k i n t h e r a n g e 1 , … , q T h e v a l u e h = g m o d q i s c a l c u l a t e d . k T h e c h a l l e n g e c i s d e f i n e d a s f o l l o w s : c = H A S H ( g | | o t h e r P u b l i c D a t a ) k Value s = ac + k mod q, along with PK and is sent to the verifier.
What was the team composition?
EWF Team members * Software architect * CTO 482 solutions team members * 2 senior full stack engineers