Confess your love with zero-knowledge
zkcrush.xyz
zkcrush.xyz
Oops - you just exposed a timing attack side channel
Mere hashing doesn't do that. For the crush example (This site), your crush could show everyone the link and their name. For that matter, someone could enter the names of everyone you knew in turn, until you were outed.
That said, yeah this hashing example is not zero knowledge because, among other things, the hash is not hiding.
Which makes sense: If the evidence (that you have a mathematical proof) could be convincingly shared with absolutely everyone, it wouldn't be zero-knowledge any longer. The whole point of zero-knowledge proof is that the evidence is only useful for the recipient(s).
But in addition to the definition given in sibling comment, here's another necessary condition of a zero-knowledge proof: it must be possible to forge transcripts (i.e., one party writing both sides of the interaction) of a zk proof even without possessing the secret.
I think for this to work, the piece of paper with the cutout must be much larger than the full waldo photo. The actual cutout would always be in the center of this mask paper. Then the waldo photo can be moved around behind this mask.
Previously, the proof relied on the alignment between the picture and mask being constant, but this is no longer the case. Now wherever Waldo actually is, every mask fits since you can just freely move around the picture.
A true ZK comparison[1] would just return a true or false without exposing any other information such as the hash of the item.
I'm sure the hash was good enough for your purpose, however!
[1] https://en.wikipedia.org/wiki/Socialist_millionaire_problem
I think the idea is that unlike pundits predicting the future, you don't want your particularly clever friend speculating out loud ten minutes into the suspense movie what they think is going on because they either guess the ending, or their guess makes you figure out the ending, and then it's 70 minutes of sitting there reading all of the other foreshadowing and not getting to enjoy any of it.
Isn't your example pundits predicting the future? So why are hashes useful to those pundits in your example?
I never had a thing for good spellers.
Instead we can alter it and fix this problems: Bob will find out his crush’s public key, encrypt "you are my crush" message to it and post it with his own signature to public bulletin (blockchain can be good shelling point). When crush decrypts message they will see proper string, while everyone else will see gibberish.
- to solve problems with key distribution we can use "identity based encryption". it requires trusted third party (e.g. school administrators) but it solves problem for key generation of participants. With identity encryption bob can encrypt message to some canonical identity such as school email. Owner of that email can prove it’s identity to the third party and receive corresponding private key.
I can absolutely guarantee that the school generation would not naturally gravitate to the blockchain as a source for social interaction, since it's not (yet) running social media. I'm assuming TikTok (if it's common to post your own videos and not just consume?) or Snapchat (or whatever came next, that's probably old enough to be uncool by now I guess?)
EDIT: I just saw the suggestion that school administrators be identity providers for a crush-admission website. OK, now I'm _sure_ this must be satire. Well played.
Previous variant does not need any blockchain because you can just embed encrypted message to the web page similarly to the original hash variant (really it's the same as sending private message to your crush) but MPC variant probably needs blockhain because that's a perfect way to publicly precommit to something.
Note: there is still the possibility that you can precommit to "x is my crush" without x being your real crash to lure out if you are crush of x.
P.S. I think that's a good illustration of a service that can't be done without crypto and have similar properties.
My initial thought was that it could be a reference to the Japanese verb meaning "to look"[0], such as mite ita ("was looking") but represented in vowelless chatspeak[1]. More logical, though, would be the verb meaning "to notice"[2], but the imperative would be kizuite kudasai ("please notice!")[2], and that doesn't match "MTT" at all.
[0] http://www.japaneseverbconjugator.com/VerbDetails.asp?txtVer...
[1] https://old.reddit.com/r/LearnJapanese/comments/bupbs9/about...
[2] http://www.japaneseverbconjugator.com/VerbDetails.asp?txtVer...
It's in the section titled "Ternary Responses", and covers the use case of a participant wanting to express "Maybe" as an opinion.
Oh, actually, I might have worked it out. It could be that "More Than Two" is designed to be somehow the reverse of "Less Than Three", which represents a heart.
Depending how you slice it, I either do or don't get to know if the result set is empty. In the latter case, there's a variation of this crush registration system where I don't get to know if Sally has a crush on me, but I do find out if anyone has a crush on me. Of course if the answer is empty set, I don't know if I'm unloved or only loved by people that don't use the app. Which could be pretty heavy.
Suppose I share a link, and you suspect I am trying to steal your partner. You could easily check whether my crush is your partner.
Having no real/strict security requirements and being lazy to go server-side scripting, I simply hashed the password. Noted the hash. Saved the file into a folder like "/${hash}/Proper Name.pdf". Hashed the hash again and embedded it into client-side JS. Wrote a JS function that took the input, hashed it twice, and if second hash of the entered password matches that, download the file "/${first hash}/Proper Name.pdf".
It worked like a charm, but please note that this is prone to attacks so if anyone reading this thinks it's a good idea to implement actual security, DO NOT. It is not. Fun to play with though.
If Bob publishes his link, and I want to know who his crush is, I can simply try all our classmates' names and quickly find out that it's Alice.
Those games only make at least a bit of sense when everybody enters their crush and only when matching both get notified.
Also brute-forceable, but at least it's quadratic (if you suspect nothing about crushes, which is unrealistic in itself).
I remember those reallllly early games like MASH or even early "compatibility" apps. Very coy.
"Find out if your crush fancies you, just choose them from your contacts:"
...
"Message 'hey there, I like you' sent"
Repeat that long process until there is just one couple left, whose first-born you then propose to. Having lived long and healthily enough to complete this game, you must have some very desirable genes and/or wealth, and you'll be good friends with basically all this person's ancestors, so there's a strong chance they'll say yes, despite the age difference.
I’m not sure if zero-knowledge proofs exist for love outside of action - repeated acts of commitment over time (to reduces the confidence that someone doesn’t love you).
I don't see a clear way of mapping the concept of a zero knowledge proof to the crush problem.
But the best I can come up with is:
1) No one learns that Alice (claims to) have a crush on Bob
2) Unless Bob also claims to have a crush on Alice, in which case.
3) Only Bob learns that Alice has a crush on him.
4) If Bob learns that Alice has a crush on him, Alice learns that Bob has a crush on her.
5) All the above guarantees are symmetric if you swap Bob and Alice.
Maybe the second half of the class could be about designing a more secure system. Or use this dilemma to explain public-private key encryption.
Even then, among heterosexuals they will suffer from the same problem as basically every software platform for romance among straight people: the massive asymmetry in interest between men and women. Men would copy and paste virtually every woman they know into the system as a "crush," so they can find which if any of their female acquaintances might be interested, and then they would decide who to pursue.
Smart men would, who know their place in the world. Any of them are good enough for you, really. Take the one that you like the most out of the ones who like you. Is this a problem? If it weren't asymmetric, it would be hopeless. Instead, most men get the choice between one or more interested women, and most women get a response from one or more of the men they were interested in.
It's better if one side isn't as picky as the other. The other options are that only a couple of people match up at all, or everyone getting a response from everyone i.e. no signal at all.
edit: I mean, isn't that Bumble?
Granted I've never dated as a gay man or as a lesbian, but from what I've observed it seems to me a much smoother and more mutual process than straight dating. I've even heard from bi men about how much easier and less stressful it is to date men than women. AFAICT when both parties are on a level playing field, and there's not a massive asymmetry in power, interest, and investment, there's a lot less grief overall.
> edit: I mean, isn't that Bumble?
Bumble is a valiant attempt to fix this issue but it seems to mostly be a failure. An average man may occasionally get a message (which will usually just say "hi"), but the asymmetry in interest is still there, and it's still mostly men's responsibility to do the real initiating.
That's most of the demographic for this product. The number of over-25 people, not in a committed relationship, who still haven't figured out how to ask people out, is pretty small.
This tool doesn't do what I'd want, but a tool that did would be kinda neat :)
a zero knowledge proof would do something like prove a valid attestation of love, but reveal nothing about who (other than maybe membership in some large enough set).
const isMatch = React.useMemo(() => hash === crushHash, [crushHash]);
Blake2b + Hybrid PoW chain with LOW TRANSACTION FEES and 4 TX/S THROUGHPUT now CONFIRMING COMMITTED RELATIONSHIPS with blockchain technology! Your relationship isn't valid until there are AT LEAST 36 CONFIRMATIONS on $LOVE chain!!1
Also now supporting ON-CHAIN unique NFTs for couples for low fees!!
Sep 23, 2014
https://bitcoinmagazine.com/press-releases/couple-get-marrie...
To a point, however, you've also described a Bloom filter reasonably well. That is it would show whether their hash is not in the set.
Related is the humorous paper "Solving the Dating Problem with the SENPAI Protocol" [1], though the solution in that paper does not rely on a third party.
Don't mean to be pedantic, but shouldn't it be "they'll be notified *they* are *your* crush"?
> they'll be notified "you are their crush"
It could be done better with public/private key cryptography, but then your audience has to be able to deal with that.
Oh well, it's on my backlog down in the "I'll never actually get there" section.
You give one black and one red to each person (Alice and Bob), and keep the last red.
The scheme is the following:
Alice will puts her two cards ON TOP of the remaining red card: to say yes, she puts her black card on top of her red card, to say no she does the opposite (red on top of black).
Bob will put his pair of cards BELOW the remaining red card, and to say yes he puts his black card at the bottom, with his red card in between, and to say no he does the opposite.
Then you cut the deck enough times to obfuscate who've done what, and you know that they've both day yes if you have the two blacks cards next to each other (or both at each ends of the deck). If anyone (or both of them) said no, you'd have black cards separated by one red card.
i assume at this point in life that any site doing something as silly as this has ulterior motives for the site's existence.
Seems like someone hasn't read the famous "Falsehoods Programmers Believe about Names"[0]
[0] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
The relationship between person and name is one-to-many
> 11. People’s names are all mapped in Unicode code points.
You can implement custom characters, i.e. https://en.wikipedia.org/wiki/Private_Use_Areas or have a process for exceptions
> 12. People’s names are case sensitive. 13. People’s names are case insensitive.
You can store this as an attribute
> 14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those.
This can be other fields if you're trying to structure the data, or you can simply store the entire name as a contiguous field.
> 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
Don't string compare names as a test for equality.
The obvious response to this is: that's too hard (/impossible to do). But that's just the reality of the situation. These issues are not necessarily possible to solve. #21 in particular makes this application very broken even with very plain vanilla western names.
Thanks for the submission!
I have a terrible habit of looking at the source of web-based puzzles to discover the solutions and wanted to make something where that was impossible.
My solution was to use the given answers as the key to decode a small blob of data. Multiple correct answers (different spellings) were handled by simply encoding the blob multiple times and trying them all.
Everything happens client side but at no time does the client store any information about the answers unless the user proves they know them by typing them in.
[0] https://sheep.horse/2020/4/tv_opening_sequences_quiz.html
The cave parable always confused me. This blog-post made it click. I think the 'secret passage in the cave' is just a very bad stand-in for knowledge. Perhaps a maze would be better. But the parable also focuses to much on 'creating false transcripts' without explaining why being able to fake it makes it 'zero knowledge'.
Or texting your crush directly?
I suppose it's a useful commitment mechanism for proving you aren't telling everyone they're your only crush, but that seems a bit of a niche use case.
2. The potential crushee can do the check without notifying you they're doing so. They might be too embarrassed/intimidated to actually tell you they're interested in whether you have a crush.
"The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information."
Your quote heavily misspells "bullshit marketing" ;)
For marketing reasons, people try give things fancy names, even if those names are misused and are completely wrong. This is exactly what happened with all those "zero-knowledge encrypted cloud storages" and so on.
Clearly there are two big clusters of meaning for “zero-knowledge” and they seem distinct enough to not overlap. Seems fine to me.
My problem is that they started doing this my using "zero knowledge" as a term from cryptography. The trend had started in early 2010s or so, as cryptocurrencies and all things crypto became popular, people realized they could use that vibe for profit.
So cloud storage providers in particular had realized "zero knowledge" sounds cool and fancy and started using it in their marketing despite stealthily assigning it entirely different meaning from where they took it from (well, some had their cryptographic designs all backwards recognizably even to my uneducated brain - false promises when most customers don't have sufficient knowledge and awareness, business as usual). They were critiqued for it, and they just shrugged it off because who gives a fuck about some angry nerds insisting on some correct word usage. And so this shit caught on, and yes, now we have two meanings.
I suppose I got to let it go, but I feel upset about the outcome.
Zero knowledge means you can prove you know something without disclosing any additional information about it, at all - that's why it's called "zero". And here, a hash of crush name is exposed, so it's not.
Check this out for a much better explanation: https://crypto.stackexchange.com/questions/70877/is-a-hash-a...
This is physically impossible and definitely not what ZK means.
But why impossible? Take this example: https://en.wikipedia.org/wiki/Zero-knowledge_proof#Discrete_... - all parties exchange are essentially random numbers (which doesn't count as "additional information"), yet they establish the fact that Peggy knows x. There's that footnote about how r must be truly random, of course, but as long as everything's done right there is no additional information there whatsoever, only random noise.
Side note: one thing I certainly don't understand are NI-ZK - while I think I have some rough understanding of how interactive ZK proofs work - well, I mean, I've read Quisquater et al.'s "How to explain zero-knowledge protocols to your children" - but I'm pretty clueless how they manage to make such things non-interactive.
I suppose the fact that it's Peggy and Victor who are running that protocol is simply irrelevant. They're talking about that value of x after all, and nothing related to that topic is revealed beyond the proof of the fact that Peggy knows it. If she'd appear in person, wherever she wears a red shirt or a white one would be might be considered "information" but it would be completely out of scope.