6/12/2023 0 Comments Trisquel retroshare![]() Note that we use our own implementation of Chacha20, which passes all the tests from RFC7539 (Chacha20 is not complicated really). files can optionally be non search-able, which keeps their hash secretĬonsequently, files shared anonymously using private channels, forums, or securely sent using private chat are guarantied to reach destination using end-to-end encryption that is both anonymous and MITM-resistant, the secret pre-shared information being the hash of the file.The construction is exactly the AEAD described in the RFC7539. That key is derived by combining a 96-bits random initialisation vector with the actual hash of the file H(f). data packets are encrypted and authenticated using Chacha20+HMAC(sha256) with a random key for each packet.encrypted tunnels are opened through tunnels requests based on H(H(f)). ![]() Let H(f) represent a hash of the file to share: We found a middle ground strategy (Partly similar to what GnuNet does, without using asymmetric authentication keys). Safely encrypting file transfer along anonymous tunnels is of course a chicken-and-egg problem: you would require a pre-shared secret information from which the encryption key is derived, with someone you cannot identify (by design, since the tunnels are made to be strictly anonymous), so it sounds impossible to avoid a man-in-the-middle decryption (if you’re a troll, stop reading here and think for a while). There are however a number of situations where such a feature is wanted, which can be summarized as: files that are shared in private channels, private forums, or even privately sent using distant chat should not be possible to intercept by a node in the network who’s passively listening for the traffic. There has been a lot of discussion about both the possibility and the reason to encrypt anonymous file transfer tunnels, since anonymity guaranties that whatever the data is, it cannot be attributed to anyone in particular. There is one limitation however: the total number of shared files and directories should stay below 4,194,303 for a maximum number of friends of 1023, because of the storage encoding that has been designed for maximal efficiency (the new system removed all pointers so that Qt can access the hierarchy content both securely and rapidely). If needed, you can still rename this file to force Retroshare to import it again.Īll these lists are of course stored encrypted on your disk including friends’ lists, which wasn’t the case before. The previous hash cache “file_cache.bin” is still loaded when found, and renamed to “file_”, and then converted into the new one “file_sharing/hash_cache.bin”. So if you share the same directories, the hashing step should be very fast. hashes are recovered from the previous version.users will need to re-define their shared directories, which is a good opportunity to test the new share manager □ and does not take long.“Pictures” is accessible *and searchable* anonymously but not visible in the friend list for any friend node.īackward compatibility is not fully provided, mainly in order to avoid keeping complicated pieces of code, but an acceptable middle ground has been found. No anonymous access is permitted to these files. In the example above, “Private stuff” is only visible to friend nodes in the group “myself” and “Holiday rushes” is only visible to Friends and Family. The right column shows groups of nodes who can browse the data. ![]() A flag as been added to allow files to be searched anonymously (See end-to-end file encryption). ![]() Changes only take place when the “apply and close” button is hit: Most data (directories, virtual names, friend groups,…) can be changed in place by double clicking on it. The file sharing manager has been re-designed with less popup windows and more contextual handles. The whole hashing system has also been improved. Random IDs are used when publishing directories to neighbor nodes so that they cannot be used to figure out what a friend is not sharing with you. We have designed a new system where directories are synced independently using a passive/active system: now friend lists are both passively synchronized in the background at a rather slow speed while being interactively updated while browsing. The old system for sharing list of files had originally been designed for a totally different purpose, and was very inefficient for this particular job since it required sending the full list of files every time something changed. This release brings a few good things, including a new differential file lists sytem and end-to-end encryption for file transfer (thanks Mr.Alice for that!), and a greatly improved GUI. ![]()
0 Comments
Leave a Reply. |