4 ms·

Handshake: A Peculiar Chat Experiment

74 points by jstanley 8y ago

losvedir 8y ago
This is neat. I'll have to look later when I'm at my computer but at a glance I'm not seeing a mobile app. Is it supposed to be compiled and sideloaded?
- rojoroboto 8y ago
  The mobile app has some early proof-of-concept drawings and code, but that part hasn't been built yet. Right now its just core library in go with a simplified CLI interface and the ability for the code to compile to gomobile. The plan is for the mobile app to be reactNative + go (gomobile) with the ability to compile and sideload on iOS and Android. I plan to submit to the app stores, but using that depends on your risk model.
telesilla 8y ago
I'm curious about how this works for dead-drops, especially when I think about journalism, political dissent and whistle-blowing. It means, I assume, there has been some previous offline interaction where keys can be exchanged, but how does that stop the keys getting into nefarious hands? Isn't that always a concern?
- deleted 8y ago
  [deleted]
- clevrcat 8y ago
  Check out their post on Killcord on nomasters.io - I think it would interest you regarding dead-drops. (Sorry for post/delete/post. I was moving quickly and wanted to make sure I was accurate.)
  - telesilla 8y ago
    Yes that was a great read, thanks! https://nomasters.io/posts/killcord-alpha/ https://nomasters.io/posts/killcord-alpha/
mempko 8y ago
Pretty cool. I think mapping the code to words would make it easier to type out during the handshake. Are there alternative ways to share the private key? For instance, if both devices have mics, maybe a local sound could be cool too.
- rojoroboto 8y ago
  for the mobile app, the plan is to use QR codes + cameras, but its just byte blobs, so other transmission methods could be used.
doomrobo 8y ago
So if I understand correctly, in order for Alice to catch up on the messages she might've missed, she decrypts the pointer to the HEAD of the message chain, and then decrypts that message. That ciphertext contains the address to the preceding message in the chain. Alice goes there and decrypts that. She continues doing this until she finds a message that's already in her chat history. Doesn't this construction make forward secrecy impossible? Normally you'd ratchet your key on every message, but if you're decrypting backwards, you can't do that. Also I suppose the fact that it's a group chat makes everything harder.
- rojoroboto 8y ago
  oh. I love these questions. Handshake author here. Handshake provides a way for Alice and Bob to generate a large pool of one-time pre-shared keys as well as a set of one-time lookup hashes to go with these keys. Both the lookup hashes and the pre-shared keys are generated using separate KDF processes and the input bytes are destroyed upon generation. This pool of "lookup hashes" are unique to both Alice and Bob and can be used in any order. There is no further coordination of future key generation, so this is very much the "impractical One-Time Pad" pattern. In fact, there is no reason that a true XOR based OTP couldn't be implemented as a "strategy" for Handshake. So, no ratchets, just a bunch of "dumb" one-time-use symmetric keys with a lookup table for each chat participant. The value prop here is that, for some reason, you suspect that Eve is capable of cracking assumptions of difficulty or implementations of PKI at a level in which you want a symmetric-only crypto alternative. This puts Handshake squarely in "cyber-punk vanity project". Operationally, the biggest known risk with Handshake is device security. If Eve was able to get a hold of your device, she'd be able to decrypt all future messages related to that chat conversation (though she wouldn't be able to decrypt messages before interception, since keys used by both the sender and receiver are aggressively destroyed upon use).
  - doomrobo 8y ago
    Ah, thanks for the response! So the number of messages you can send is precisely the number of keys that you generate at the start? How many is that? This also probably means you don't support long-running (think multi-year) conversations or the ability to add/remove people to/from the group, is that right?

74 points by jstanley 8y ago

This is neat. I'll have to look later when I'm at my computer but at a glance I'm not seeing a mobile app. Is it supposed to be compiled and sideloaded?

rojoroboto 8y ago
The mobile app has some early proof-of-concept drawings and code, but that part hasn't been built yet. Right now its just core library in go with a simplified CLI interface and the ability for the code to compile to gomobile. The plan is for the mobile app to be reactNative + go (gomobile) with the ability to compile and sideload on iOS and Android. I plan to submit to the app stores, but using that depends on your risk model.

telesilla 8y ago

I'm curious about how this works for dead-drops, especially when I think about journalism, political dissent and whistle-blowing. It means, I assume, there has been some previous offline interaction where keys can be exchanged, but how does that stop the keys getting into nefarious hands? Isn't that always a concern?

deleted 8y ago
[deleted]
clevrcat 8y ago
Check out their post on Killcord on nomasters.io - I think it would interest you regarding dead-drops. (Sorry for post/delete/post. I was moving quickly and wanted to make sure I was accurate.)
- telesilla 8y ago
  Yes that was a great read, thanks! https://nomasters.io/posts/killcord-alpha/ https://nomasters.io/posts/killcord-alpha/

mempko 8y ago

Pretty cool. I think mapping the code to words would make it easier to type out during the handshake. Are there alternative ways to share the private key? For instance, if both devices have mics, maybe a local sound could be cool too.

rojoroboto 8y ago
for the mobile app, the plan is to use QR codes + cameras, but its just byte blobs, so other transmission methods could be used.

doomrobo 8y ago

So if I understand correctly, in order for Alice to catch up on the messages she might've missed, she decrypts the pointer to the HEAD of the message chain, and then decrypts that message. That ciphertext contains the address to the preceding message in the chain. Alice goes there and decrypts that. She continues doing this until she finds a message that's already in her chat history. Doesn't this construction make forward secrecy impossible? Normally you'd ratchet your key on every message, but if you're decrypting backwards, you can't do that. Also I suppose the fact that it's a group chat makes everything harder.

rojoroboto 8y ago
oh. I love these questions. Handshake author here. Handshake provides a way for Alice and Bob to generate a large pool of one-time pre-shared keys as well as a set of one-time lookup hashes to go with these keys. Both the lookup hashes and the pre-shared keys are generated using separate KDF processes and the input bytes are destroyed upon generation. This pool of "lookup hashes" are unique to both Alice and Bob and can be used in any order. There is no further coordination of future key generation, so this is very much the "impractical One-Time Pad" pattern. In fact, there is no reason that a true XOR based OTP couldn't be implemented as a "strategy" for Handshake. So, no ratchets, just a bunch of "dumb" one-time-use symmetric keys with a lookup table for each chat participant. The value prop here is that, for some reason, you suspect that Eve is capable of cracking assumptions of difficulty or implementations of PKI at a level in which you want a symmetric-only crypto alternative. This puts Handshake squarely in "cyber-punk vanity project". Operationally, the biggest known risk with Handshake is device security. If Eve was able to get a hold of your device, she'd be able to decrypt all future messages related to that chat conversation (though she wouldn't be able to decrypt messages before interception, since keys used by both the sender and receiver are aggressively destroyed upon use).
- doomrobo 8y ago
  Ah, thanks for the response! So the number of messages you can send is precisely the number of keys that you generate at the start? How many is that? This also probably means you don't support long-running (think multi-year) conversations or the ability to add/remove people to/from the group, is that right?