[losfair]

Nice project!

I'm wondering why you choose to implement your own cryptography routines instead of using something standard like TLS. Apparently your `DecryptData` and `Encrypt` methods are vulnerable to replay attacks due to a lack of (EC)DH-style key exchange.

[maxmunzel]

Thanks for the critique! I wanted to use symmetric crypto as its trivial to use without domains and certificates. The possibility of replays is a non-issue, as the key-value store is implemented as a CRDT and therefore all operations are idempotent.

On the other hand, I didn't anticipate replay attacks in the design and thanks to your comment, I'll keep them in mind should I ever find myself in a scenario where they are undesirable...

[losfair]

TLS is available in pre-shared key (PSK) mode. Looks like there is ongoing work to add TLS-PSK to Go's standard library: https://github.com/golang/go/issues/6379#issuecomment-117006...

[maxmunzel]

Cool! If this gets implemented, I'll definitely use is instead of raw AES.

[randomhodler84]

Yeaaah don’t use ECB.

AEAD or gtfo

[makeworld]

It doesn't matter if the operations are idempotent. The point is that an eavesdropper can replay a message that sets a key, for example, overwriting whatever was there previously.

It would be better to use an established cryptography system. You could do self-signed certs with TLS, like Syncthing does. Or just use SSH.

[DecoPerson]

If the CRDT part is done correctly, then replaying a message that sets a key will not change anything, ever.

If the message is:

Key: Foo

Reference CRDT node ID: 7654321 (the last node that the clients knows of that updated the value of ‘Foo’)

Operation: Update

Value: Bar

The ID of this new node: 1122112211

(Omitted for simplicity: Timestamps, hashes, …)

Replaying that message won’t do anything if the target already knows about the existence of that new node.

If the target didn’t know about the node, then I guess you’re helping them sync their own data? Maybe they owe you a thanks? If you knew what each encrypted message contained, you might be able to do some split-state shenanigans; for example: replay the message that sets a “PasswordAuthEnabled” key to “Yes” but deliberately omit the message that changes the “Password” key from its default of “password” to a genuine password. It’s very hard to imagine an actual situation like this occurring, but I guess that’s what makes crypto (and designing secure systems in general) so damn tricky. That and the math. And end users. And…

[makeworld]

I see, thanks. I was focusing on the "idempotent" part but yeah a CRDT would protect against replays. Still not a great design though, still opens yourself up to issues, in case not all messages are part of the CRDT, or you have a buggy CRDT implementation.

[tlb]

It's a shame that the meaning of 'idempotent' has gotten watered down by half-assed implementations. The original NFS paper from Sun [0] claims that write operations are idempotent, but they aren't really. Not if another operation has occurred. Like in:

  write '1' @ 0
  write '2' @ 0
  write '1' @ 0 (replayed through a duplicated packet)

the duplicated write RPC reverts the second write. Duplicated link and rename RPCs are even worse. They added a replay detection cache in the server later to prevent some common error cases, but it fails if the server reboots in the middle.

Anyway, CRDT correctness is hard enough that I'd be reluctant to trust it against an adversary who can inject replays.

[0] https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=75...