possible crypto_provide bug

[tristen]

hello deluge team

deluge: 1.3.6
libtorrent: 0.16.8.0
distro: fc18

i think i've found a problem with deluge's encryption. i've run a few tests and when i set the encryption options from "edit > preferences > network", deluge doesn't seem to be sending the correct value in crypto_provide when deluge initiates outbound connections.

from http://wiki.vuze.com/w/Message_Stream_E ... cification

ENCRYPT2() is the negotiated crypto method.
Current options are:
0x01 Plaintext. After the specified length (see IA/IB) each side sends unencrypted payload
0x02 RC4-160. The ENCRYPT() RC4 encoding is continued (no reinitialization, no keychange)

i can't remember where or why or how i learned that 0x03 means let the peer decide, but hey.

when i set deluge to "forced" encryption for outbound connections and a level of "handshake", deluge is transmitting 0 (zero) in crypto_provide
when i set deluge to "forced" encryption for outbound connections and a level of "fullstream", deluge is transmitting 1 (one) in crypto_provide
when i set deluge to "forced" encryption for outbound connections and a level of "either", deluge is transmitting 2 (two) in crypto_provide

it appears deluge is transmitting a value one less than what it should be.

to confirm this, i set deluge to a port blocked by my firewall and:

1. i participated in a torrent with the encryption in deluge set to "forced" and "handshake". this resulted in no peers.
2. i participated in a torrent with the encryption in deluge set to "forced" and "fullstream". bam! this resulted in peers immediately.
3. i participated in a torrent with the encryption in deluge set to "forced" and "either". bam! this too resulted in peers immediately.

in case 1 i think peers are rejecting deluge: crypto_provide is zero instead of one.
in case 2 i think peers are connecting but in fact are connecting using handshake-only (plaintext) encryption, not the fullstream encryption: crypro_provide is one instead of two.
in case 2 i think peers are connecting but in fact are connecting using fullstream (rc4-160) encryption and is not giving the peer the option to choose: crypto_provide is two instead of three.

note: "i think" means i'm not 100% sure, because i can't readily debug how deluge connects to external peers and i can't see in the gui what encryption level has been negotiated with the peer.

also, a side issue, the checkbox "encrypt entire stream" doesn't appear to alter the value transmitted in crypto_provide (i think it's therefore redundant.)

i'm happy to raise this as a bug if necessary, i thought i'd post here first and see what people think.

regards
tristen

ps: i've just got to say: deluge rules them all.

[Cas]

You will need to discuss this with the libtorrent dev: https://code.google.com/p/libtorrent/issues/list

[tristen]

hello cas

i reported the issue over at libtorrent:

https://code.google.com/p/libtorrent/is ... ail?id=474

i think the dev there concluded two bugs:

libtorrent shouldn't allow a client to send a crypro_provide of zero.
deluge shouldn't ask libtorrent to send a crypto_provide of zero.

and i think there might generally be a bug with deluge: instead of deluge requesting libtorrent to send a crypto provide of 0x01, 0x02 or 0x03, deluge is requesting libtorrent to send a crypto_provide of 0x00, 0x01 or 0x02 depending upon which encryption option the user chose in the drop-down list in the gui.

the libtorrent dev asked me to raise this as a bug with deluge, but i can't see a way for me to raise a bug here?

[Cas]

Thanks for that. If you create a bug ticket and mark it for 1.3.7 milestone.

http://dev.deluge-torrent.org/wiki/Cont ... ortingabug

[tristen]

done!

http://dev.deluge-torrent.org/ticket/2324