TFC 0.5.5 out

[Lodewijk andré de la porte]

2015-05-25 20:54 GMT+09:00 Markus Ottela <oottela at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4710 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20150526/a7b991a2/attachment-0002.txt>