Sorry if this sounds blunt, still I wish to ask this question as I am new to libtorrent.
I am trying to write a file transfer mechanism using libtorrent but I run to this interesting error while doing a CMake Build
:
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindOpenSSL.cmake:334 (find_package_handle_standard_args)
CMakeLists.txt:162 (FIND_PACKAGE)
The error is pretty much understood - I have a missing dependancy and I could install it. But what I am wondering is whether the torrent traffic using the libtorrent is by default encrypted. I have already implemented an encryption scheme in my program and I wouldn't want to encrypt already encrypted data!
how encrypted and under what conditions matters here. Let's assume you're referring to bittorrent protocol encryption (encryption may be a bit misleading, it's really more obfuscation).
Then, yes, sometimes. Since it's really just obfuscation, it's allowed for non-encrypted incoming connections to be accepted, and likewise, if an encrypted outgoing connection fails (for any reason really), it may reconnect in non-encrypted mode. You can however configure libtorrent to not allow non-encrypted connectiosn, see pe_settings. Note that there still isn't really any authentication to speak of. Basically the info-hash of the torrent is the key.
That said, the openssl is not related to any of this. Libtorrent comes with built-in support for RC4 and Diffie-Hellman (from libtomcrypt). OpenSSL is only needed to talk to trackers over HTTPS and the (not widely supported) extension to run bittorrent itself over SSL (which does provide proper authentication between peers).
Also, it may be worth noting that tracker traffic typically is not encrypted. And even when it's done over SSL, it's common for trackers to provide self signed certificates (at least in my limited experience), so typically it's not practical to enforce authentication there either.