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?