You don't lose one bit for each message. The idea is that the average length of cycle for a good 512 bit hash function is 2^256. So after 2^256 messages, keys might start to repeat. 2^256 keys last for 10^73 messages, or 10^56 years with 1TB/s continuous transfer speed. This however doesn't mean the ciphertext will repeat. That would require that all four encryption keys are the same (Probability for that is 1 / (256^4)) and that all nonces are same as well (even less likely). You can't guarantee all messages make it through, and there is no return channel from either RxM to sender's TxM to tell if some message has not been received. If more entropy would be transferred inside messages, drop of packets could lead to keys getting out of sync. But since the keyspace of current implementation effectively never runs out, this is not necessary. I think the local testing version comes very close to the "microservice" model you described. The local testing version runs all three programs on same computer and messages are transmitted unidirectionally via files. But whatever you can exploit on the single system, can lead to exfiltration of keys so the HW data-diode model is infinite times more secure. Malware isn't going to break the laws of physics inside data diodes (removing other covert channels from audio to heat between TCB units is of course required). Pidgin is currently the ideal client, mainly because it was fairly easy to implement (readily available code) and because it's bundled with Tails. If the constant transmission feature of TFC is combined with hidden service XMPP server, the amount of metadata should be about as low as you can make it. On 25.05.2015 07:18, Lodewijk andré de la porte wrote:
Cool! I like the cipher-cascade :)
Regarding the FS: if Keccak loses some entropy in it's hashing, the entropy in the key used would slowly degrade. Certainly Keccak doesn't preserve all entropy, but it probably doesn't leak it fast enough to matter. You could probably add some new entropy from the random generators. To prevent padding, you could replace, say, merely the last bit as Keccak doesn't (seem to) lose a bit of entropy per cycle. Could someone more knowledgeable comment on this issue? It's probably inconsequential so long as Keccak is what it seems, but it's much weaker-looking than the cipher-cascade.
I'm also impressed by the idea of data diodes. At first I thought they were in software, and already thought "what an effective way to limit risk!". Write a "microservice" that fronts two other processes, with separated user accounts, and allows only data in or data out. Formally prove the fronting microservice (it's small enough) and any error in your own code becomes far less harmful (side channels are still there; cache- ,DOS, timing-attacks, etc). Doing it in hardware is even better. It's highly likely that it works, and that's *very cool*.
My biggest question is, why as a plugin for Pidgin?