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?