
Handshake: A Peculiar Chat Experiment - jstanley
https://nomasters.io/posts/handshake-alpha/
======
doomrobo
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
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
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?

~~~
rojoroboto
> So the number of messages you can send is precisely the number of keys that
> you generate at the start? How many is that?

Bingo. The demo only generates 10K keys per participant, but 100k keys in
storage takes less than 200ms to generate and only uses 6MB of storage space.
This will be user configurable per chat. It's important to note, each message
burns two keys. The first key encrypts the message, the second key encrypts
the reference to that message for the rendezvous point.

> 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?

Correct. There are plenty of other tools that do a beautiful job of handling
that. This is designed specifically to provide short-lived chats with specific
guarantees. The handshake happens just once at chat creation and all
participants must be present.

------
telesilla
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?

~~~
clevrcat
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
Yes that was a great read, thanks! [https://nomasters.io/posts/killcord-
alpha/](https://nomasters.io/posts/killcord-alpha/)

------
mempko
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
for the mobile app, the plan is to use QR codes + cameras, but its just byte
blobs, so other transmission methods could be used.

------
losvedir
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
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.

