New answers tagged zero-knowledge-proofs
2
The short answer is: the algorithm that is trying to distinguish real from ideal interaction already knows the "correct" inputs. So it can easily distinguish in this case.
More precisely, let's take the security definition from Hazay-Lindell (p21):
$$
\{ S_2(1^n, y, f(x,y) \}_{x,y,n} \overset{c}\equiv
\{ \textsf{view}_2^\pi(x,y,n) \}_{x,y,n}
$$
The ...
2
As in the linked question, what you are missing is that the simulated view for a given input pair must be indistinguishable from the simulated view for the same input pair.
So if $A$'s input $s$ is $0$, then the real view of $B$ will be $0$ with probability $1$. On the other hand, if your simulator just chooses a uniform bit, the simulated view of $B$ will ...
3
The first part of the question is answered in the comments. Regarding the second part, yes, indeed, you are right! It's a typo in the Pinocchio paper, Section 2.3. Protocol 1., you also linked. The problem is that the left hand side of the verification equation enumaretes the I/O related coefficients twice in the left wire polynomial, V, therefore $g^{v_0}.g^...
1
I don't know the term "safety". But when it's written 'the process is more secure'. It means that the probability for an adversary that doesn't know the secret (here how to go through the door) decreases "exponentially".
For example, to solve 4 challenges the adversary has to choose the side door $4$ times, so it has the probability $\frac{1}{2^4}$ to win ...
1
In this setting, can we regard the verifier as an honest verifier, since he always replies with a random message (rather than a message depends on previous messages)?
No. In a public coin protocol the honest verifier will always send random coins as their messages.
A malicious verifier is under no obligation to do so.
They can choose whichever message makes ...
0
You could use a password-authenticated key agreement protocols, e.g. EKE.
Basically, those aim exactly at your scenario with the goal of establishing a proper key to communicate securely. If you use that key to established a secure channel(e.g. with AES-GCM), and then verify both parties have the same key, you can ensure they both used the same password. ...
0
A simple solution can involve Nestor: a trusted third party. Both Alice and Bob send the secret to Nestor and he will verify if they both have the same secret.
In real life this solution is not optimal (what if Nestor is Bob's partner? How can Bob verify that Nestor is not on Alice side?) but can be acomplished if both party trust Nestor enough to stay ...
-1
You can use Password-Based Key Derivation Function (PBKDF2). However, not even this can save you for weak secrets.
Although a bit outdated, you can view some recommended parameters here
-2
You have the answer. It's hashing. Even if S is weak, it's not possible to determine S from the hash value if the algorithm used is secure enough.
Alice can send a SHA-256 hash of S to Bob. If Bob knows S, he can confirm it and Alice has convinced him. Else, we know it's just someone pretending to be Bob.
1
You can use an AND statement to do this.
To prove that x is between a and b , you can prove that (x-a) > 0 AND (b-x) > 0
2
I've read a little about this area years ago. The naive example of an accumulator is simply multiplying primes together into the accumulator, which can then be checked for their presence simply by division. This obviously results in persistent growth of the accumulator.
I looked for an accumulator that addressed the endless growth issue, but I was never ...
Top 50 recent answers are included
