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