Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

Question: When will Tixati support DTLS 1.3.

by Guest on 2024/03/01 09:31:17 PM    
RC4 connection enryption is not secure and is widely regarded as obselete as far as symmetric ciphers are concerned. I know that Libtorrent can use DTLS 1.3 to encrypt connections and Tixati should too.
by Guest on 2024/03/02 11:04:46 AM    
“Secure” and “not secure” is empty marketing bullshit aimed at clueless public nowadays. What exactly are you trying to achieve? Evading bittorrent traffic detection is currently not possible in a public network. Even if your client supports unrecognizable data encryption, 100 other peers will happily send more or less obvious bittorrent packets to your port. Widespread obfuscation support needs global BEP to implement in most clients. Moreover, it has social consequences, as admins often need to classify and de-prioritize p2p traffic. A cellphone network in a modern city won't work if users are able to run torrents, the laws of physics dictate that. For the same reason your home router drops (almost) all broadcasts on wireless interface.

On the other hand, if someone is actually cracking your traffic encryption to directly spy on data being exchanged (as opposed to passively collecting public hash announces), you probably have much bigger problems.
by Guest on 2024/03/02 01:14:06 PM    
Oh great, encryption "experts" strike again.  It's all so tiresome.

RC4 is secure if the first 1024 bits of the keystream are discarded AND the protocol layer beneath has a data integrity mechanism (ie. hashing).

The bittorrent protocol does both these things.  RC4 is perfectly secure in this context.

Cue the know-it-alls to now bring forward completely irrelevant examples of RC4 being used insecurely in a totally different context.
by Guest on 2024/03/02 01:32:21 PM    
The problem with TLS is it's a much heavier protocol to negotiate which algorithm to use.  This requires more round trips and slows down the connection establishment time, and may also cause much more CPU usage at high bandwidth depending on the cipher that is ultimately used within.  Really a bad choice and a waste of developer time.  Just like the bt-v2 fiasco.

RC4-drop-1024 is just fine the way it's used.  If anything, it would be better to swap it out for AES just because it's a little bit faster on modern CPUs that have dedicated instructions for it.
by Guest on 2024/03/03 01:53:33 AM    
RC4 is secure/insecure
Guys, you are asking for cipher change because of the wrong reason. BEP 8 is for obfuscation, not for encryption. RC4 is no longer suitable for obfuscation, because BitTorrent is pretty much the only remaining protocol that uses it.

A cellphone network in a modern city won't work if users are able to run torrents,
This statement is false.
First, cell and data traffic are on different networks. The operators do not rely on packet inspection to separate them.
Second, on data traffic the operators do not need to know the about BitTorrent to do bandwidth shaping based on DSCP headers.
by notaLamer on 2024/03/04 02:09:07 PM    
I did not see any mentions of DTLS being used for peers on libtorrents issue/PR page. It's only mentioned in topics with WebTorrent support.
From what I know, encrypted RC4 hasn't been invisible for a very long time now. It has helped after introduction but on a new connection it's caught by signatures too. If ISPs really wanted to block BT users and just lock a port, they could see other peer's connection attempts as Guest suggested or detect DHT traffic and block that port as a potential BT user.




This web site is powered by Super Simple Server