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.
Cryptographic coin flipping, now in Keybase
91–100 of 101 posts
Re: Cryptographic coin flipping, now in Keybase
#92Earlier quoted context omitted.
Assuming you mean the attack where one person can wait to be the last to reveal their secret and then influence the game by dropping out, it doesn't appear to. > What if someone loses network before the secret stage? > A bad actor can't change the outcome of a flip but could prevent it from resolving. > The Keybase app will highlight this scenario. Odds are it was just a network issue, but if you have such a person d…
One way to solve this issue is to shuffle the possible outcomes and encrypt or hash their positions along with a nonce. This info would be distributed to clients during the game initialization. At reveal time, the server presents these outcome positions to the clients along with the other client secrets. Also see my other comment in this thread where in a client/server architectured version of this protocol, the reve…
Makes sense to me!
Even requiring a deterministic reveal order (without a central, independent server) would reduce the chance an individual could force a reroll after knowing the outcome from 1/1 to 1/n, which would be significant. The 'central server' solution is probably more relevant for Keybase though.
Re: Cryptographic coin flipping, now in Keybase
#93Earlier quoted context omitted.
The clients are. The platform they all run on top of is centralized, made up its own irresponsibly insecure key handling and crypto protocols, and is proprietary.
They didn't make any of their own security, they use very well established open-source security libraries for everything. Stop spreading FUD.
I have researched their approach in great detail and found design flaws in it like: https://github.com/keybase/keybase-issues/issues/1946
A lot of trust is rooted in their centralized proprietary walled garden API and to make matters worse they actually silently bypass hardware security modules in favor of keys exposed to system memory!
They even encourage users to expose their PGP private keys to their browser and didn't even bother to isolate it to a service worker so browser plugins can't steal it (or just supporting hardware tokens which GPG already did just fine)
Almost everything they do is non standard, not interoperable with anything else, not distributed to keyservers. They are the internet explorer of cryptography.
They did this in the name of UX but it turns out you can have super easy PGP UX AND follow standards as OpenKeychain has demonstrated.
Keybase introduced lock-in and their own protocols for problems that did not at all need them. They are 2 steps forward on UX and one huge backwards step for security.
Re: Cryptographic coin flipping, now in Keybase
#94Earlier quoted context omitted.
They didn't make any of their own security, they use very well established open-source security libraries for everything. Stop spreading FUD.
I have researched their approach in great detail and found design flaws in it like: https://github.com/keybase/keybase-issues/issues/1946 A lot of trust is rooted in their centralized proprietary walled garden API and to make matters worse they actually silently bypass hardware security modules in favor of keys exposed to system memory! They even encourage users to expose their PGP private keys to their browser and d…
You have been on this crusade for a long time now and you have posted this link often, I just realized that keybase is not just a GPG replacement and that using it with my smart card is not a good fit and not the problem they want to solve. So I just accepted that and actually tried to figure out what keybase is actually doing and why rather then demanding they do what I initially wanted from it.
They have been focusing on a per-device key system and its not really a gpg front-end. NaCl is a well known library and what they do is based on it. Saltpack is an open library they use and they use other open libraries as well. I happen to like the how the keybase security system works and I think it has advantages over the GPG that I like.
If you don't want to use the evil centralized system at least spamming the same issue every-time Keybase comes up. If Keybase is not the solution you like then just move on with your life.
Re: Cryptographic coin flipping, now in Keybase
#95Earlier quoted context omitted.
Interesting! Thanks for the reference. I'm not sure how not revealing the pre-image would allow them to affect the result with any degree of predictability - it is equivalent to them selecting a different uuid, is it not? I'll try to read up and see if I can answer that question.
Say that all the other participants have revealed their pre-images, and you're the last one left you reveal your pre-image. Before you reveal it, you realize you alone have all the pre-images and can calculate the result. You calculate it, and realize you don't like the result. You could then decide to throw away your pre-image to force a new roll. If necessary, claim your computer crashed, your connection dropped, e…
Couldn't this be solved (or the risk of manipulation largely mitigated) using a trusted third party to witness, and perhaps hold, each candidates pre-image generation?
Re: Cryptographic coin flipping, now in Keybase
#96I don't really understand why they use HMAC-SHA256. Why do many schemes decide to do this needlessly when they can use SHA3 or Blake2b?
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.
HMAC is useful because it fixes some flaws with the Merkle-Damgard construction that SHA2 uses.
SHA3 and Blake2* use different constructions that don't have these flaws, thus they don't require HMACs for their needs.
Re: Cryptographic coin flipping, now in Keybase
#97Earlier quoted context omitted.
Interesting! Thanks for the reference. I'm not sure how not revealing the pre-image would allow them to affect the result with any degree of predictability - it is equivalent to them selecting a different uuid, is it not? I'll try to read up and see if I can answer that question.
Say that all the other participants have revealed their pre-images, and you're the last one left you reveal your pre-image. Before you reveal it, you realize you alone have all the pre-images and can calculate the result. You calculate it, and realize you don't like the result. You could then decide to throw away your pre-image to force a new roll. If necessary, claim your computer crashed, your connection dropped, e…
I misworded the first sentence confusingly. Here's what I meant:
>Say that all the other participants have revealed their pre-images, and you're the last one left to your reveal your pre-image.
Re: Cryptographic coin flipping, now in Keybase
#98I'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…
What a coincidence, slightly!
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.
Re: Cryptographic coin flipping, now in Keybase
#99Earlier quoted context omitted.
Say that all the other participants have revealed their pre-images, and you're the last one left you reveal your pre-image. Before you reveal it, you realize you alone have all the pre-images and can calculate the result. You calculate it, and realize you don't like the result. You could then decide to throw away your pre-image to force a new roll. If necessary, claim your computer crashed, your connection dropped, e…
Couldn't this be solved (or the risk of manipulation largely mitigated) using a trusted third party to witness, and perhaps hold, each candidates pre-image generation?
If you have the trusted party reveal all of the pre-images, then you're just passing off the ability to decide not to reveal the pre-images to them. You could layer on the ability for all of the parties to reveal their pre-images if the third party fails to reveal them, though now you have the complication that the parties could reveal different pre-images than they gave to the third party. (Maybe one of the parties could realize the third party would defect because of a certain result that party doesn't want either, so that party could change their pre-image to avoid that result.)
The third party isn't any different than the main parties in the mix. If everyone can decide who the most trustworthy party in the mix is, you can have them reveal last.
Re: Cryptographic coin flipping, now in Keybase
#100Earlier quoted context omitted.
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.
HMAC is useful because it fixes some flaws with the Merkle-Damgard construction that SHA2 uses. SHA3 and Blake2* use different constructions that don't have these flaws, thus they don't require HMACs for their needs.
Ok, your original comment wasn’t clear on intent.