@malgorithms, what are the colored bars from each participant? Is it a colored representation of the hashes?
Cryptographic coin flipping, now in Keybase
21–30 of 101 posts
Re: Cryptographic coin flipping, now in Keybase
#22I 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?
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.
The plaintext isn't guessable, though. The post says they use a 32-byte random string.
Re: Cryptographic coin flipping, now in Keybase
#23It 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).
Re: Cryptographic coin flipping, now in Keybase
#24Has 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 Stel…
Try updating your client.
Re: Cryptographic coin flipping, now in Keybase
#25@malgorithms, what are the colored bars from each participant? Is it a colored representation of the hashes?
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.
Re: Cryptographic coin flipping, now in Keybase
#26I 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?
Re: Cryptographic coin flipping, now in Keybase
#27I'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.
Re: Cryptographic coin flipping, now in Keybase
#28I 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.
In theory you are right, but in practice, flips take fewer than 10 blocks of AES output, so the sequence should look random unless AES is very broken.
Edit (and meta-edit): I changed the wording in the FAQ accordingly.
Re: Cryptographic coin flipping, now in Keybase
#29Earlier quoted context omitted.
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.
The plaintext isn't guessable, though. The post says they use a 32-byte random string.
Agreed we could have used either of those. We needed a PRF keyed by the Game ID (so the revealed secrets of this game can't be replayed in the next). Blake2b and SHA3 would also have worked fine.
Re: Cryptographic coin flipping, now in Keybase
#30I 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?
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.