I'd be curious if people on HN would want a zero knowledge survey and voting system inside Keybase, and if so, what would it look like?
The background: we talk about it sometimes as a solution to a real problem: in certain teams and workplaces, people can be afraid to give honest feedback (who dares to submit an "anonymous" survey to HR?), but Keybase may be in a unique position to let people in a group give written feedback, vote on something important, or rate an experience. Without any risk of exposing identity, short of writing something identifiable in a text field.
I'd be curious, personally, to see management get a yearly vote of [no] confidence, for example. Is that crazy?
Keep in mind we are mostly focused right now on user experience and performance improvements. But we allocate a certain amount of time to cryptographic features that just aren't possible in other software, such as this coin flip thing. We've been talking about voting and surveys, too.
OT: One of the things I find interesting is that "zero knowledge" has become a buzzword. On the one hand it is frustrating, because when cryptographers say "zero knowledge" we mean something very specific and rigorously defined (a survey protocol cannot be zero knowledge because the results of a survey do reveal something about the respondents' inputs). On the other hand, the fact that non-experts are comfortable with the idea of using an interactive protocol to securely compute functions means there is one less mental hurdle to deal with when trying to deploy these technologies.
This is absolutely very useful. Definitely within a specific team or company, but generally anywhere, especially when combined with Keybase's proven identities feature. I can imagine a "Vote with Keybase" button ubiquitous on the internet wherever they want to conduct surveys.
Further: it will remove the friction of doing anonymous surveys. I would do them way more often for various things (similar to the coin flips) if they were easy to do.
I worry this ends up being a technical solution to what is ultimately a social problem. If the problem is that people feel threatened submitted feedback at their workplace, the issue is the structure of the workplace.
I recently registered keybase.vote for a related web app idea. Rather than anonymous voting, rather, I wanted the opposite: authenticity in voting, polls, surveys, etc. A common problem in surveys is verifying that the respondents are real and from people you trust. Within small communities, you would have a large enough web of trust that you could rely on who you are following to determine who you individually pay attention to from the result set.
So my idea was simply to have the survey/poll generate a text field of all the Q/A in a JSON body, kinda like the proofs of keybase, and then have the user copy/paste it and sign it on keybase and then submit their response.
I would have the whole result set downloadable in raw format that anyone could easily verify with keybase commandline tools. But I’d also employ the web of trust created by following on keybase.
I thought I’d try it out and see if works. I like the idea of Keybase being a general way to authenticate without needing any elaborate login process or email acccount.
imho the more interesting cryptopgraphic proof would be proof of address or bounding box. I feel that if you allowed third-parties to pay you for supporting a validation of locality via cryptographic features sent in postcard, then the rails would come off what was possible with digital systems. Knowing location will be increasingly powerful imho. Our opinions count most in a local spaces, at least with city-building. And I feel that third parties would be willing to fund the main cost of postage, if it allowed them to be assured of certain geographic bounds of users.
In order to cheat that system, people would need to engage in mail fraud or buy a PO box.
Happy to discuss, chris. Sidewalk Labs is setting up camp in Toronto, and I was speaking about the above at a local event, and they were really interested in the concept. I had a call with their head of identity, but was disappointed that he couldn't say anything of substance on _why_ it was relevant to SL efforts, at least not without my signing an NDA. As a community organizer in the civic tech scene, I had no interest in that. More secrecy in the smart city / open gov sector :/ blech
Has Keybase lost it's way? I thought they were onto something cool and maybe could explore an enterprise play with private chats, filesharing and git for teams or something like that. Basically make money by selling to teams. But Keybase seems to have stagnated, existing apps are still quite buggy, not enough new developments recently. The facepalm moment for me was when they announced they were supported by the Stellar foundation. I lost all hope then and there. I get that you guys are buddies with the Stellar folk, you think Stellar is cool etc but an objective analysis leads to only one answer : don't do it you'll regret. Maybe add it as a feature (stellar integration) but don't go all in. Speaking of Stellar, still no integration after 1 year?? Focus on what you have and start making money. So, what went wrong malgorithms?
(Sorry if this sounds harsh or rude, there's no point in sugar coating the truth. Hopefully the keybase teams reads this criticism and does a little soul searching.)
In a sense keybase is one of the most important projects built right now (that I can think of).
It covers aspects (think pareto principle) of email, linkedin, slack, github, dropbox, whatsapp, online banking and probably more core use cases that I don’t have on top of my mind.
That is now, today. With a decent user experience that keeps getting better (see recent improvements @ user profiles).
=> all of that end-to-end encrypted and delivered in a way that it is accessible and usable and fun with a long-tail of users in mind.
[I have no idea what an equivalent would be right now, not even as combination of multiple separate projects. Think about that.]
Keybase's main competitor seems to be Slack. I don't use Slack but I assume that Slack can read all your messages if they want to, so privacy is the main differentiator.
All these little quality-of-life improvements on top of that can only be a good thing, IMHO.
I stopped using keybase because it just takes too long to open up the app on keybase and send message on my phone. the desktop client is great, but it's just too slow on mobile.
I use Keybase daily and really like it, but of course the more I use it the more I fear it'll go away. Are they actually making any money off it yet, or will they eventually run out and fail to switch over to paid accounts in time before the company evaporates?
I want a heads to come up. I add a couple of hacked members to the group, so there are 3 honest members, and lets say 3 coordinated dishonest members.
Everyone shares their commitment hash, and the dishonest members share their actual commitments amongst themselves. Once everyone has the commitment hashes, the 3 honest members broadcast their commitment. The three dishonest members now have everyone's commitments, but honest members only have other honest member commitments. Dishonest members compute the ultimate value - if it turns up heads, then they just share their commitments with everyone, and the final answer is heads.
If it turns up tails, then the dishonest members compute possible permutations of various dishonest members dropping out and never sending their commitments. So maybe if dishonest member 1 drops out, the resultant value from just the group of 5 would be heads. So dishonest member 2 and 3 share their commitments and dishonest member 1 goes offline.
So, this system will work when it is composed of only people you trust, but will not work when it may be composed of people you don't trust. And if you trust everyone in it, why go through this process in the first place? And if you decide that when someone drops out and doesn't share their commitment, you just have to rerun the algorithm, then you have just given a very easy way to give the dishonest people a way to spike your coin flipper, so that no one can ever get a value out of it, or the dishonest members can just keep dropping out until they encounter a round where the final value is determined to be heads.
1. All members generate a random value (high entropy).
2. All members submit a hashed value of that random value (the commitment).
3. All commitments are distributed to all members. At this point, no more commitments may be submitted.
4. All members reveal their random values to each other and validate each value against its hash.
5. All values are then used to deterministically calculate the coin flip.
A dishonest member will not receive any values used in the coin flip calculation before step 4. If a member decides to change their random value, the hashed value / commitment will be invalid.
Seriously? You work professionally in the crypto space and don't know where this is from? Or don't feel it's important to attribute such fundamental ideas to the appropriate people? If you really don't know, a quick google would have educated you. But what I fear to be more likely is that you apparently just don't give a damn.
For anybody remotely interested, look up Manuel Blum's work, e.g. "Coin flipping by telephone" presented at CRYPTO 1981. ACM Turing Award.
Or Rivest, Shamir, Adleman, "Mental Poker". Oh, those guys also got the ACM Turing Award.
I think you're unfairly punishing him for not knowing; it's a bit tough to find. I'll give you that the joke -- pinning it on his wife -- is unfunny.
None of the folks you mentioned, I believe, invented commitment schemes. Whit Diffie has a good history here: https://ee.stanford.edu/~hellman/publications/24.pdf. So these innovations would have been ~1 academic generation prior.
Of course, the GCHQ probably invented them even earlier ;)
This may not be the intended use of your application, but I organize a local bdsm group (if unfamiliar, do not Google this at work), and we appreciate the security offered very much.
We can even think of a few "fun" uses of this new feature.
Since the end of January 2019 I’ve started to notice more and more profiles with suggestive pictures of underage humans and anime characters. I almost never log into my Keybase account, but frequently check my profile to see “friend” recommendations, then I log in and follow people who I think are interesting, mostly tech influencers. But since January-February I randomly get recommendations that include one of these NSFW accounts, which is quite unsettling because other people may think my account is somehow involved with them. One day I clicked around and found that many of these accounts follow each other in a circle that composes around 20-30 profiles. Knowing that Keybase offers encryption as one of its main features, I wouldn’t be surprised if pedophiles are already using the service to share offensive content among them.
Edit: I reported 42 accounts a few weeks ago, but not knowing what these profiles were doing, I just asked them to check. The Privacy Team at Keybase started an investigation the day after. Today, none of these accounts exist anymore, I’m not sure if that was really a pedophile network or not, but I’m glad Keybase did something about it.
There's a slight variation on this that I had pondered for designing a distributed election algorithm. I'm sure the idea is not novel, but it would be nice to know what work has been done on it.
The goal is to fairly select some candidate from a set of candidates. Each candidate `Ci` generates a UUID `Ui`. The hash of their UUID `hash(Ui)` is published by each candidate. Once all hashes have been collected, each candidate reveals the verifiable original UUID to all the others.
Each candidate then concatenates these UUIDs together (after normalizing the sequence in some way - e.g. sorting), and produce a selector code: `H = hash(U1 ++ U2 ++ ... ++ Uk)`. Finally, the selected candidate is simply the one whose UUID is the closest to `H` under some distance metric.
I tinkered a bit with adapting it for situations where the candidate set could shrink during the selection process (i.e. a candidate drops out), but didn't really pursue it much.
This is generally referred to as a RANDAO in cryptoeconomics. The problem is that a candidate can decide not to reveal their preimage `Ui` and affect the outcome of the RANDAO in that way.
HMAC-SHA256 is baked into the WebCrypto API, whereas SHA3 and Blake2b are not (as far as I know). This alleviates having to load yet another library into the browser.
You can't use a straight hash in applications where the plaintext might be guessable. In the example given, you might try hashing "heads" and "tails" to see if that matches the SHA you were given. The random padding on an HMAC replaces the bit about lasagna in the example.
Why is it needless? SHA3 was designed to complement, not replace SHA2. Blake2* are preferred by some but they are not the national standard and have their own quirks.
Author here, thank you for the comment. "flip again" was added at the last minute, after a night at a bar...where some beta testers were making real-world decisions using the app.
I didn't cover some details I find fascinating but which might have been overkill outside of HackerNews. For example, some assume the "one-way"ness of a hash function makes this protocol work. But that's not enough: we can't have Alice generating 2 different secrets with the same hash, even if Barb can't reverse the hash. What we also need is _collision resistance_, so Alice doesn't get to pick and choose what to expose in the final stage.
Lately, we've made much bigger, but less blogworthy, improvements to Keybase. It's faster, team on-boarding is getting better, and we'll be launching a very improved UX in the next month or so. I rarely get to stop and write about Keybase, so this was fun.
And for anyone looking to test, I'm `chris` on keybase. You can start a chat with me and do a `/flip cards 5 chris,yourname` and we'll see who gets a better poker hand. If you can deal yourself a flush or better on your first try I'll give a prize or something? Who knows. Anyway, we're having fun with it.
It seems like a VRF might be a more natural choice than a commitment scheme for verifiable randomness, since it doesn't require any honesty assumption for participants, and Keybase already manages keys (though maybe it would be a problem if participants could change keys midway through the ceremony).
I've thought about trustless lotteries quite a bit, and haven't really came up with a solution that works without using head-to-head brackets.
>A bad actor can't change the outcome of a flip but could prevent it from resolving.
The post glosses over this but it can get pretty bad. E.g. 99 actors have revealed their seeds and then the 100th decides whether to reveal or not, based on whether they or their confederates will be the winner after that final reveal.
I see a flaw with that prng scheme. Since AES is reversible, the 128-bit blocks that make up the output cannot repeat. The output is a permutation of distinct 128-bit blocks. Early in the sequence that only matters a tiny bit, but the longer it goes, the more that tells you about possible upcoming values.
Yes! Each horizontal row in the rectangles represents a participating device. The purple/blue rectangle that comes in first represents all the bytes of the commitments coming in. Since we constrain the size of the rectangle it makes (IMO) a cool visual effect as the rows squeeze to accommodate more data.
Each little square inside it represents a byte, so we map bytes (0..255) to colors ranging from a blue to a purple.
The matching secret is also 32 bytes, and of course those come in in random order, so we line up secret rows with the matching commitments. It sure is fun to watch.
We played with some different visualizetions. We actually had one version with a 3d sphere getting covered in data, but it felt too gimmicky. This gives a good feeling of people showing up.
I got lost on the line "If the final answer is odd, the flip is TAILS." For example: Alice flips 1 for tails. Barb/Charlie/Danika flip 0. Why is the answer tails when most of the people flipped 0 for heads? Why use XOR instead of just taking the most common answer?
Perhaps an even simpler analogy is a light switch. Each person decides randomly either to flip the light switch or leave it where it is. This is basically what random XOR'ing is.
If you're one of 10 people doing this to the light switch, then as long as you choose randomly, it doesn't matter what the other 9 people do. It has a 50% chance of ending up on and a 50% chance of ending up off. Even if the other 9 people are cheating together.
Of course this has the problem that whoever goes last wins, which is why the commitment ceremony is necessary.
Seems like overkill. Just declare your guesses and use a third party to generate coin flip/dice roll. In fact this functionality is built-in in a number of chat clients.
[+] [-] malgorithms|7 years ago|reply
The background: we talk about it sometimes as a solution to a real problem: in certain teams and workplaces, people can be afraid to give honest feedback (who dares to submit an "anonymous" survey to HR?), but Keybase may be in a unique position to let people in a group give written feedback, vote on something important, or rate an experience. Without any risk of exposing identity, short of writing something identifiable in a text field.
I'd be curious, personally, to see management get a yearly vote of [no] confidence, for example. Is that crazy?
Keep in mind we are mostly focused right now on user experience and performance improvements. But we allocate a certain amount of time to cryptographic features that just aren't possible in other software, such as this coin flip thing. We've been talking about voting and surveys, too.
[+] [-] betterunix2|7 years ago|reply
[+] [-] i2shar|7 years ago|reply
[+] [-] dougk16|7 years ago|reply
You can read the basic protocol here: https://aytwit.com/about#technical_details__thoughter_gist
It would be cool to see something like that in Keybase. Feel free to steal the idea. :)
[+] [-] tosh|7 years ago|reply
Further: it will remove the friction of doing anonymous surveys. I would do them way more often for various things (similar to the coin flips) if they were easy to do.
[+] [-] opnitro|7 years ago|reply
[+] [-] chrisdone|7 years ago|reply
I recently registered keybase.vote for a related web app idea. Rather than anonymous voting, rather, I wanted the opposite: authenticity in voting, polls, surveys, etc. A common problem in surveys is verifying that the respondents are real and from people you trust. Within small communities, you would have a large enough web of trust that you could rely on who you are following to determine who you individually pay attention to from the result set.
So my idea was simply to have the survey/poll generate a text field of all the Q/A in a JSON body, kinda like the proofs of keybase, and then have the user copy/paste it and sign it on keybase and then submit their response.
I would have the whole result set downloadable in raw format that anyone could easily verify with keybase commandline tools. But I’d also employ the web of trust created by following on keybase.
I thought I’d try it out and see if works. I like the idea of Keybase being a general way to authenticate without needing any elaborate login process or email acccount.
[+] [-] patcon|7 years ago|reply
In order to cheat that system, people would need to engage in mail fraud or buy a PO box.
Related: https://github.com/patcon/can-ereg-api#unofficial-national-d...
Happy to discuss, chris. Sidewalk Labs is setting up camp in Toronto, and I was speaking about the above at a local event, and they were really interested in the concept. I had a call with their head of identity, but was disappointed that he couldn't say anything of substance on _why_ it was relevant to SL efforts, at least not without my signing an NDA. As a community organizer in the civic tech scene, I had no interest in that. More secrecy in the smart city / open gov sector :/ blech
[+] [-] 616c|7 years ago|reply
[+] [-] mr_puzzled|7 years ago|reply
(Sorry if this sounds harsh or rude, there's no point in sugar coating the truth. Hopefully the keybase teams reads this criticism and does a little soul searching.)
[+] [-] tosh|7 years ago|reply
It covers aspects (think pareto principle) of email, linkedin, slack, github, dropbox, whatsapp, online banking and probably more core use cases that I don’t have on top of my mind.
That is now, today. With a decent user experience that keeps getting better (see recent improvements @ user profiles).
=> all of that end-to-end encrypted and delivered in a way that it is accessible and usable and fun with a long-tail of users in mind.
[I have no idea what an equivalent would be right now, not even as combination of multiple separate projects. Think about that.]
[+] [-] glerk|7 years ago|reply
There is integration with Stellar in keybase. I can use the app as a stellar wallet and send/receive lumens.
https://u.today/keybase-starts-supporting-stellar-wallets
[+] [-] LeoPanthera|7 years ago|reply
All these little quality-of-life improvements on top of that can only be a good thing, IMHO.
[+] [-] JshWright|7 years ago|reply
You're an idiot if you believe that.
(Still agree?)
[+] [-] Callmenorm|7 years ago|reply
[+] [-] dcbadacd|7 years ago|reply
[+] [-] floren|7 years ago|reply
[+] [-] oh_sigh|7 years ago|reply
I want a heads to come up. I add a couple of hacked members to the group, so there are 3 honest members, and lets say 3 coordinated dishonest members.
Everyone shares their commitment hash, and the dishonest members share their actual commitments amongst themselves. Once everyone has the commitment hashes, the 3 honest members broadcast their commitment. The three dishonest members now have everyone's commitments, but honest members only have other honest member commitments. Dishonest members compute the ultimate value - if it turns up heads, then they just share their commitments with everyone, and the final answer is heads.
If it turns up tails, then the dishonest members compute possible permutations of various dishonest members dropping out and never sending their commitments. So maybe if dishonest member 1 drops out, the resultant value from just the group of 5 would be heads. So dishonest member 2 and 3 share their commitments and dishonest member 1 goes offline.
So, this system will work when it is composed of only people you trust, but will not work when it may be composed of people you don't trust. And if you trust everyone in it, why go through this process in the first place? And if you decide that when someone drops out and doesn't share their commitment, you just have to rerun the algorithm, then you have just given a very easy way to give the dishonest people a way to spike your coin flipper, so that no one can ever get a value out of it, or the dishonest members can just keep dropping out until they encounter a round where the final value is determined to be heads.
[+] [-] leetbulb|7 years ago|reply
2. All members submit a hashed value of that random value (the commitment).
3. All commitments are distributed to all members. At this point, no more commitments may be submitted.
4. All members reveal their random values to each other and validate each value against its hash.
5. All values are then used to deterministically calculate the coin flip.
A dishonest member will not receive any values used in the coin flip calculation before step 4. If a member decides to change their random value, the hashed value / commitment will be invalid.
[+] [-] ummonk|7 years ago|reply
[+] [-] wildmanx|7 years ago|reply
> ~My wife~ Not sure.
Seriously? You work professionally in the crypto space and don't know where this is from? Or don't feel it's important to attribute such fundamental ideas to the appropriate people? If you really don't know, a quick google would have educated you. But what I fear to be more likely is that you apparently just don't give a damn.
For anybody remotely interested, look up Manuel Blum's work, e.g. "Coin flipping by telephone" presented at CRYPTO 1981. ACM Turing Award.
Or Rivest, Shamir, Adleman, "Mental Poker". Oh, those guys also got the ACM Turing Award.
[+] [-] jlrubin|7 years ago|reply
None of the folks you mentioned, I believe, invented commitment schemes. Whit Diffie has a good history here: https://ee.stanford.edu/~hellman/publications/24.pdf. So these innovations would have been ~1 academic generation prior.
Of course, the GCHQ probably invented them even earlier ;)
[+] [-] marcus0x62|7 years ago|reply
[deleted]
[+] [-] RawaHorse|7 years ago|reply
We can even think of a few "fun" uses of this new feature.
[+] [-] guessmyname|7 years ago|reply
Since the end of January 2019 I’ve started to notice more and more profiles with suggestive pictures of underage humans and anime characters. I almost never log into my Keybase account, but frequently check my profile to see “friend” recommendations, then I log in and follow people who I think are interesting, mostly tech influencers. But since January-February I randomly get recommendations that include one of these NSFW accounts, which is quite unsettling because other people may think my account is somehow involved with them. One day I clicked around and found that many of these accounts follow each other in a circle that composes around 20-30 profiles. Knowing that Keybase offers encryption as one of its main features, I wouldn’t be surprised if pedophiles are already using the service to share offensive content among them.
Edit: I reported 42 accounts a few weeks ago, but not knowing what these profiles were doing, I just asked them to check. The Privacy Team at Keybase started an investigation the day after. Today, none of these accounts exist anymore, I’m not sure if that was really a pedophile network or not, but I’m glad Keybase did something about it.
[+] [-] kannanvijayan|7 years ago|reply
The goal is to fairly select some candidate from a set of candidates. Each candidate `Ci` generates a UUID `Ui`. The hash of their UUID `hash(Ui)` is published by each candidate. Once all hashes have been collected, each candidate reveals the verifiable original UUID to all the others.
Each candidate then concatenates these UUIDs together (after normalizing the sequence in some way - e.g. sorting), and produce a selector code: `H = hash(U1 ++ U2 ++ ... ++ Uk)`. Finally, the selected candidate is simply the one whose UUID is the closest to `H` under some distance metric.
I tinkered a bit with adapting it for situations where the candidate set could shrink during the selection process (i.e. a candidate drops out), but didn't really pursue it much.
[+] [-] jmeyer2k|7 years ago|reply
https://github.com/randao/randao
[+] [-] betterunix2|7 years ago|reply
https://crypto.stanford.edu/pbc/notes/crypto/voting.html
[+] [-] bluesign|7 years ago|reply
[+] [-] rodrigosetti|7 years ago|reply
[+] [-] tuxxy|7 years ago|reply
[+] [-] algorithm47|7 years ago|reply
[+] [-] tlb|7 years ago|reply
[+] [-] garmaine|7 years ago|reply
[+] [-] tosh|7 years ago|reply
also love the details like “flip again”
[+] [-] malgorithms|7 years ago|reply
I didn't cover some details I find fascinating but which might have been overkill outside of HackerNews. For example, some assume the "one-way"ness of a hash function makes this protocol work. But that's not enough: we can't have Alice generating 2 different secrets with the same hash, even if Barb can't reverse the hash. What we also need is _collision resistance_, so Alice doesn't get to pick and choose what to expose in the final stage.
https://en.wikipedia.org/wiki/Collision_resistance
Lately, we've made much bigger, but less blogworthy, improvements to Keybase. It's faster, team on-boarding is getting better, and we'll be launching a very improved UX in the next month or so. I rarely get to stop and write about Keybase, so this was fun.
And for anyone looking to test, I'm `chris` on keybase. You can start a chat with me and do a `/flip cards 5 chris,yourname` and we'll see who gets a better poker hand. If you can deal yourself a flush or better on your first try I'll give a prize or something? Who knows. Anyway, we're having fun with it.
[+] [-] lavrov|7 years ago|reply
[+] [-] insomniacity|7 years ago|reply
It would give you an office suite play very very quickly - I can only see it as a winner.
[1] https://github.com/xwiki-labs/cryptpad
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] ummonk|7 years ago|reply
>A bad actor can't change the outcome of a flip but could prevent it from resolving.
The post glosses over this but it can get pretty bad. E.g. 99 actors have revealed their seeds and then the 100th decides whether to reveal or not, based on whether they or their confederates will be the winner after that final reveal.
[+] [-] chowells|7 years ago|reply
[+] [-] maxtaco|7 years ago|reply
https://security.stackexchange.com/questions/27776/block-cha...
[+] [-] maxtaco|7 years ago|reply
Edit (and meta-edit): I changed the wording in the FAQ accordingly.
[+] [-] yincrash|7 years ago|reply
[+] [-] malgorithms|7 years ago|reply
Each little square inside it represents a byte, so we map bytes (0..255) to colors ranging from a blue to a purple.
The matching secret is also 32 bytes, and of course those come in in random order, so we line up secret rows with the matching commitments. It sure is fun to watch.
We played with some different visualizetions. We actually had one version with a 3d sphere getting covered in data, but it felt too gimmicky. This gives a good feeling of people showing up.
[+] [-] LK83|7 years ago|reply
[+] [-] malgorithms|7 years ago|reply
If you're one of 10 people doing this to the light switch, then as long as you choose randomly, it doesn't matter what the other 9 people do. It has a 50% chance of ending up on and a 50% chance of ending up off. Even if the other 9 people are cheating together.
Of course this has the problem that whoever goes last wins, which is why the commitment ceremony is necessary.
[+] [-] Grue3|7 years ago|reply
[+] [-] latchkey|7 years ago|reply
[+] [-] emmelaich|7 years ago|reply
Is he being coy here? I mean - poker, right?