TFC 0.5.5 out

[Markus Ottela]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4050 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150525/2946fe35/attachment-0002.txt>