TFC 0.5.5 is now out I found another vulnerability in the constant transmission feature; between each long message only one command would be sent at most. This issue has now been fixed. After a request, I added further message authentication for CEV: In addition to GMAC it now does encrypt-then-MAC style authentication using HMAC-SHA2-512 (512-bit key) and SHA3-512 MAC (1144-bit key) before GCM authenticates and decrypts the ciphertext. I upgraded all keys to 512-bit ones so cyclic hashing of keys won't reduce security over long period of time (there is no key negotiation in TFC). I also upgraded hashes from Keccak-256 to Keccak-512 and at the same time the Keccak-CTR key size was upgraded to 512-bits. So 1280-bits of symmetric key security in total. As for key generation, CEV now has constant 2kHz sampling speed (1.5M samples are loaded in total), three vN whitening passes and between each of those, Keccak-512 compression with 2:1 ratio (1024 bits in, 512 out). User can now input different entropy from keyboard for each of the eight 512-bit keys generated. Also fixed lots of bugs and typos, and as usual, updated whitepaper and manual where necessary. UI was tweaked slightly: I added cleaner completion messages and some startup animation for the lulz (disable option available in settings). Full update log: https://github.com/maqp/tfc-cev/blob/master/0.5.5%20update%20log.txt
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?
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?
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!
participants (2)
-
Lodewijk andré de la porte -
Markus Ottela