We should work on a clear and specific metadata security threat model for the bare Cryptid protocol.
Metadata security is very tricky to do right and has implications for all users (since the entire point of is to make the metadata characteristics of every user as consistent as possible).
Mitigating some of the more subtle metadata attacks often requires spending expensive resources: bandwidth and user time.
As an example on the “difficult to 100% mitigate” end of the spectrum is this paper with some findings on WhatsApp and Signal https://arxiv.org/pdf/2411.11194 where ack times leak significant metadata about device activity to anyone with the delivery address. Does the Cryptid protocol hold up under this model? Will it continue to as we evolve it?
And on the easier side, will we pad protocol messages to a fixed block size? If so, what size? Will we mitigate traffic frequency fingerprinting attacks?
The most difficult part of this is that whatever decision is reached should be written into the protocol, as any divergence or configurability in user behavior will just leak more metadata.
Part of me wants to delegate all of this to the transport layer. I don’t have a lot more thoughts on this but i thought it was worth getting a discussion started
So, initially I kept the scope limited because I wanted to finish a version of the spec in time for my master’s thesis. Now that that’s done, I’m not opposed to expanding the scope of the spec, but since we’re in soft freeze right now, we should wait until we hit 1.0 and see if the system even works in practice.
Once we see get into the guts of it all and see the way things are working, I’m fully open to jumping into more stuff.
Yes, this is something we definitely want to do. The current spec already mentions that we don’t try to protect against traffic analysis beyond minimal routing data and I feel like that’s the first thing we should tighten up post v1.0. I’ve been brainstorming ways to do traffic mixing as well, so we’ll most likely have padding plus some sort of traffic shaping/mixing written into the protocol post v1.0 instead of leaving it as an implementation detail.
I fully agree with this.
Right now, I don’t think Cryptid has anything that really prevents attacks in that class. The threat model section explicitly says we don’t provide strong resistance to traffic analysis and that timing patterns are still observable, and the current design has per‑message acks and real‑time delivery semantics similar to other messengers. So I’d expect an active attacker with a delivery address and good timing measurements to be able to learn at least coarse online/activity patterns, just like in the paper.
I feel like this is the sort of thing we’ll only be able to reason about properly once we have real implementations to poke at. Post‑v1.0 I really want to work on adding mandatory jitter and batching on acks, and maybe an “always‑on mailbox” style behaviour where the server’s visible RTT looks the same regardless of whether the client is actually active or not. At the very least that should make these timing side channels more expensive to exploit, even if we can’t eliminate them completely