121–130 of 217 posts
A cool technology that builds on ZK is zkTLS that can prove that you have access to some data on the internet, for example that you have an account with some service without revealing your username. So more private oauth I suppose?
Earlier quoted context omitted.
An intuitive explanation is that of proving you can find Waldo in a picture without revealing his exact location. Digital wallets can be interpreted as fancy signature schemes that operate on third-party issued commitments C instead of public keys that directly link users to their identities. A simple signature scheme is based on proof of knowledge PoK{x : pk = g^x}, which is transformed into a noninteractive variant…
for explanation i've seen for the where's waldo analogy: imagine the single page of the where's waldo puzzle, and another giant piece of paper with the shape of waldo cut out of it. by providing a picture of waldo in the cut-out, you can prove you know where he is without providing the location. a zero knowledge proof.
Earlier quoted context omitted.
Perhaps "unfathomably" was too strong, but "any undergraduate" is at least very easy to falsify.
Jokes aside, I really believe that once all is said and done our system is way simpler than BBS. How are you going to check the document expiration date in BBS? Yes I know about range proofs, I know about the quaternion norms and the four prime theorem and all that jazz. But nobody is talking about it. How are you going to bind to a hardware secure element that only uses NIST primes? Yes, there is a very clever varia…
I disagree that no one is talking about it: the solutions are there, it is a question of getting the resources to put it together. Circuit based solutions have some nice properties, but the actual security assumptions are a bit odd, and the reasons people should trust a complex circuit and verification protocol are a bit hard.
I don't however think this is really the big debate. Rather it's about ensuring SD-JWT and related non-private solutions do not get used. To the extent that this work helps show it's possible, and the tradeoffs are desirable, it's good.
Anyone have a good explanation on the intuition of non-interactive zero-knowledge proofs? For example, I thought the "paint-mixing" analogy for Diffie-Hellman key exchange ( https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange#Ge... ) really helped me handwave the math into "mixing easy, unmixing hard". https://blog.cryptographyengineering.com/2014/11/27/zero-kno... was a good intro for interactive ZK proofs but…
There's a Where's Waldo explanation that I can't find right now but helped me a lot.
Earlier quoted context omitted.
To say this has nothing to do with blockchain is like saying RADAR had nothing to do with war. Yes, people knew Maxwell's equations prior, i.e. "knew the proofs," w.r.t. ZKP but it has only really been developed much later, during the war. The whole field of zero-knowledge mathematics was, if not non-existent, but certainly marginalised, before the crypto investment has hit the scene; this is facts. Yes, Shamir et al…
The comment didn't say that ZKP had nothing to do with blockchain. The comment said that blockchains are not needed/involved for a zero knowledge proof, just like war is not needed for radar.
If people want to redefine blockchain to mean zero-knowledge, and they want to redefine zero-knowledge to mean succinct as they all seem to have done, it's not my problem.
There is no blockchain here, period.
[flagged]
Author (of the code) here. The context is the US mobile drivers licenses and the forthcoming digital identity documents in the EU. The government gives you an electronic document stored in your device, and now the problem is, why would you ever want to give a copy of your document to a third party. This code solves the problem via zero-knowledge presentations of the document. This is real stuff already integrated in…
Earlier quoted context omitted.
(1) in this case, an identity issuer provides the source of truth identity information. Examples include state DMV, your passport (you can try "Id pass" in Google wallet), etc. (2) One of the goals of this project was to layer ZK on top of current identity standards that DMVs already issue, so that gov orgs don't have to change what they currently do to support the strongest user privacy. One example format is called…
If you can achieve RCE on the chip and run arbitrary code without invalidating signatures, does the protocol still stay secure? If so, what's the point of requiring your implementation to run on a verified secure element? If not, the protocol seems only as strong as the weakest chip, as obtaining just a single private key from a single chip would let you generate arbitrary proofs.
The ZKP library does not run on the secure element. It runs on the normal CPU and produces a proof that the ECDSA signature from the SE is valid (and that the ECDSA signature from the issuer is valid, and that the credential has not expired, and ...) If you crack the ZKP library, all you are doing is producing an incorrect proof that will not verify.
- Buys or borrows a laptop / phone / whatever from somebody with an authorized private key
- Downloads an authorized private key file from a sketchy forum (maybe hacked from an unwilling target, maybe willingly shared by a free-speech advocate)
- Uses a VPN over HTTPS to visit websites in countries where age checks aren't legally mandated (and non-compliance is implicitly or explicitly encouraged for economic or ideological reasons)
Earlier quoted context omitted.
Jokes aside, I really believe that once all is said and done our system is way simpler than BBS. How are you going to check the document expiration date in BBS? Yes I know about range proofs, I know about the quaternion norms and the four prime theorem and all that jazz. But nobody is talking about it. How are you going to bind to a hardware secure element that only uses NIST primes? Yes, there is a very clever varia…
Well, we can split up the credential into multiple ones sharing a serial number to fix the array signing. To bind to NIST there are some solutions based on ZkAttest (which got fixed, I made a few mistakes in it) to show signature under ECDSA while hiding it. I disagree that no one is talking about it: the solutions are there, it is a question of getting the resources to put it together. Circuit based solutions have s…
On that we all agree.
Earlier quoted context omitted.
If you're looking for something at the level of paint cans, I think you want Matthew Green's "crayons and hats": https://blog.cryptographyengineering.com/2014/11/27/zero-kno...
That's only for interactive proofs though. Like GP I have no problem understanding those.
Usually in an IP, the prover (Bob) has to answer questions from the verifier (Alice), and Alice chooses her questions by flipping a coin. If the Bob doesn’t really know the answer, he’ll get caught cheating with high probability.
So now the trick: Bob starts generates his initial answer. Then he hashes it (“commits” in the jargon), and uses the hash as “Alice’s first coin flip”. Then he answers the question for that flip, hashes the whole thing for “Alice’s second coin flip”… etc.
Bob does this say, 100 times, and then sends the whole simulated conversation to Alice. Alice can verify that he didn’t cheat by checking the intermediate hashes.
The whole thing depends on the ability to not control the result of the hash function, so it’s vital to use a cryptographically secure one.