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).
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?
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.
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).
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.
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"
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).
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 :)
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.
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 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?
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
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.
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.
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.
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...
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.
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.
"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."
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.
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.
Don't mean to be pedantic, but shouldn't it be "they'll be notified *they* are *your* crush"?
i assume at this point in life that any site doing something as silly as this has ulterior motives for the site's existence.
const isMatch = React.useMemo(() => hash === crushHash, [crushHash]);
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.
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.
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.
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'.