2015-05-25 20:54 GMT+09:00 Markus Ottela <oottela@cs.helsinki.fi>:
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.
Yes, but the question was about situations wherin the hash function functions subpar, for example because of some esoteric relationship between one key and the next. Think also of a quantum computer, being able to work through such relationships exceedingly fast. A chosen plaintext attack is imaginable.
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).
Yes, it seems plentifully good enough if the hash function is perfect. But, is it? I am not able to say. I'm pretty confident that, even if it leaks more than expected, the space would still be large enough. The only serious issue arises with Quantum Computing, and whether or not that's a realistic thing to fear is yet TBD. I think it is though, perhaps in 40 years, but I'd like my chats to be private forever (iow: targeting at 100 years).
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.
Yes, this would be a problem. Data corruption also seems like it might be a serious issue.
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).
Fully agree. This actually means a hardware exploit is also irrelevant, so long as the diodes work! Wonderful :)
Pidgin is currently the ideal client, mainly because it was fairly easy to implement (readily available code) and because it's bundled with Tails.
Good reasons. My first thought was compatibility with other services, but that didn't really make sense given that the other party would obviously need to run TCB too. 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.
I have called "constant transmission" a "trickle-connection" (perhaps just a trickle) in the past, as information constantly trickles across, and analogies with plumbing are common in networking. I'm happy to see someone actually implementing it :) Keep it up! It looks good!