rdebath

Re: This Message Can I request that unlike the 1.0.* to 1.1.* transition the generation of the "info hash" depends on the encryption algorithm in use and the protocol version. ... eg: SHA2("BTSync" + ProtocolVersion.tostring + Secret + EncryptionAlgorithm.tostring + EncryptionFlags + ...) Then to use this when you expose the options to use different encryption and MAC algorithms that the OpenSSL library provides as "really advanced" options. PS: Please include the "none" option for this algorithms where appropriate.

So you're saying that SHA3 gives the opportunity for better performance because the MAC and the encryption are done at the same time. This might be true if the algorithm is in itself quick enough. The problem I see with that is that there are specific instructions built into current x86 processors that are included only to calculate AES encryption. The OpenSSL library that BTSync uses has assembler routines to encrypt using these instructions if the (run time) processor supports it. This generally makes it a rather quick algorithm in practice even though others might be faster in theory. Another problem with SHA3 is that OpenSSL doesn't do it yet. So they'd have to change the encryption provider not just 'flick over' to a different algorithm. From what I've read SHA3 is not a security upgrade there are no indications that SHA2 has any significant security problems. The only reason for switching over is a possible improvement in performance. Now while this has been proven in a "level playing field" most current processors and devices have a substantial bias to AES. If this "bias" (these AES partials) can be reused for SHA3 or SHA3 is good enough without them the switchover can be quick. If not it'll have to wait several years for the hardware assists to become common. In either case a well supported multi-protocol library like OpenSSL is probably the best choice to get there quickest. BTW: Changing the hash algorithm later is a "clean" change as the same key will provide different "info hashs" depending on the algorithm used. But changing the algorithm results in lots of "encryption failure" errors. So ... kos13 Can I request that unlike the 1.0.* to 1.1.* transition the generation of the "info hash" depends on the encryption algorithm in use and the protocol version. ... eg: SHA2("BTSync" + Secret + ProtocolVersion.tostring + EncryptionAlgoritm.tostring + EncryptionFlags + ...)

Read The Friendly Manual: Turn off the "search LAN" option in the preferences for the share.

Refresh the web page completely; I had some broken icons until I did a proper F5.

No. Sync is not a "cyberlocker" (or whatever the current media buzzword is) it's a simple, secure file transfer protocol. It transfers all the files in a directory and, unusually, any files you add to the directory to all the other copies of BTSync in the world that are running with the same secret key. If you want to setup a different set of files you need a different directory. But, this is Alpha software and things will change before release. Describe what you'd like on the wishlist thread and it may happen. PS: You will probably be disappointed by your ADSL upstream if you sync single files from "your house".

Word doesn't see it as a valid lock file; to be valid there has to be a process on your machine or across a supported (by Microsoft) network protocol holding the file open. It would be reasonable to exclude it because it's 'clutter', nothing more.

If you turn on the debug log the IP addresses are shown in there. There is a continual stream of packets directly between the peers, if your firewall/router will show you it's connection tracking tables, the peers are likely to stick out a bit. Though if you've turned DHT on there will be quite a bit of other noise. Tcpdump, jnettop, wireshark and similar network monitoring tools can give you solid pointers too. Lastly, in theory, if you're a programmer, it wouldn't be too difficult to send a query to the tracker too, the messages are quite simple bencode'd packets.

Don't forget some filesystems on Linux are case insensitive ... sometimes. eg: vFAT can be either depending on the mount options. What's more even windows can be case sensitive under the right conditions; NTFS is actually a case sensitive filesystem, but the Win32(Win64) environment usually enforces case insensitivity. But, it's simple enough in concept; it's just a conflict, as if two different machines had created the two files with the same name at the same time. So the "normal conflict resolution process" should be triggered. My preference is that one of the files gets renamed for any true conflict.

Check the unofficial FAQ ...

You read my earlier message; the one that says what you need is an upside down encfs ... well, seems it exists ... Problem solved

It sounds like you're all after "on going" central control of who is allowed to connect to the network. The primary way of doing this is the Kerberos protocol. Both nodes basically logon to the key server at the same time and the keyserver proves they are both allowed to connect. The keyserver then gives them a time limited key so they can talk to each other. OTOH, it may be enough to use a simple protocol like Each node has a private key (including the keyserver) The keyserver has copies of all the public keys who's private keys are allowed to connect. A node sends a signed, timestamped request to the keyserver encrypted with the keyserver's public key. The keyserver encrypts the current share key with it's the node's public key, signs it and sends it back The node decrypts the share key with it's private key. The node uses the share key for up to X hours After X/2 hours have elapsed the node starts attempting to contact the keyserver for a new share key. Perhaps the keyserver can also send an early revocation. Probably, there's a 'connection' secret to allow connection to the keyserver, this might be just the sha256 of the keyserver's public key. There are several existing protocols that would work, but, the primary requirement seems to be central control and revocation which needs a machine trusted to do this, none of the nodes are trusted so you need the keyserver. Note: Authentication communications do NOT all have to be directly to the keyserver; re-keying messages can be forwarded for authenticated clients. But obviously not for unauthenticated ones. PS: Just looked at the flash video; yup he's not wrong. He also highlights that separate password is a nice idea. I would like having two boxes, one for the generating the info hash (the share name) and one for doing the wire encryption. That way I can turn off the line encryption or have two acceptable passwords on a share while I go round all the sites and change the passwords.

I don't see how a user process can even get into a state where it's unkillable, run by root, okay, but even then not for BTSync it doesn't need to do anything that dangerous. Can you do something like this on the 'hung' process so we can, maybe, see what sort of hang it is ... ps u wwp 4729 ; ps l wwp 4729 ; ps s wwp 4729 ; ps j wwp 4729

, The problem to be solved in that thread was with UNC paths on windows. The problem in this thread is for ALL platforms and is a simple result of making the temp files 6 characters longer than the existing file they refer to. When the existing file name is the maximum length it can be (or nearly so) the file cannot be transferred because the temp file name will be too long for the filesystem. I propose the temp file name is in the (per share) .Sync directory with a name based on the info hash.

Dunno, what it means but this looks wrong: "[20130504 22:23:27] Got metadata size 0, pieces 69" So, time to email I guess: http://forum.bittorr...-syncapp-issue/

Ah; a rainbow table. A full rainbow table would need 207691874341393105141219853168803840 petabytes, that is 233840261972944466912589573234605283144949206876160 bytes. Good luck with that. Oh, and "guessing" is just a very uneducated form of "breaking". Usually, to break encryption you use "a technique" to reduce size of the space you have to guess from "impossible" (eg 2^160) to "workable" (eg 2^50) then keep guessing 0, 1, 2, 3, 4, 5... until you find the right one. BTW: There are 32 valid character in a BTSync 32 character key (Yes both 32) they are ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 in that order. The characters 018 are duplicates of OLB. This means a 32 character base32 BTSync key has exactly 160 bits. The 42+ character secrets use the Base64 character set so are a minimum of about 256 bits long. You'll have to as kos13 (or rather the developers) how these are distilled into usable secrets; I'd guess SHA256 and SHA1.

Chances are the peers will not use the VPN unless you set them up as known peers. But I'll only say that because I'm allowed to guess, kos13 has given you the real answer.

I bet! Any chance of seeing a copy of this list? Priority bands would be nice too.

greenone83, The central server doesn't have to know anybody's IP'port. It doesn't need any way of finding peers turned on. It will respond and construct a two way link with anyone who talks to it. (and has the secret key). TCP/IP doesn't help in initiating connections; if you've only allowed TCP/IP on the server's firewall the server will have to hole punch it's firewall. The hole punching requires that both ends initiate the connection at approximately the same time. Which means that to hole punch both ends have to know the IP of the other. UDP/IP must be open inbound at one end (the "server" end) to remove the need for hole punching. BTSync does NOT need tcp open on a firewall and will not use it if it is open because the remote host's IP address will not be one of those designated as 'LAN'. PS: fogbav, your posts have an edit button.

As it happens "YourLoginThatIsEasyToGuessWithSomePasswordYouBelieveIsSecure" is both a valid passphrase (after I corrected your spelling) for BTSync and probably between 160 and 300 bits of entropy. (It's mixed case and very, very long) So yes, it is a good passphrase and probably better than a 160 bit random string. To make a 60 character password insecure you have to do something really obvious like making it "000000000000000000000000000000000000000000000000000000000000". Just joining words together to make a 60 character string is unlikely to be less than a 128bits of entropy. Even making the first word your name doesn't make an attack significantly easier.

Yes indeed, there is a possibility that a symmetrical cipher like AES could have it's keysize halved, that's why a lot of people say that it's better to run AES with at 256bit rather than the standardised 128 bit key. BTSync does this. Though, practically, that 5-10 year is almost certainly until "significant results", that will include increasing the number of qubits from the upper limit of a few hundred today to a few thousand. The number of qubits that'll probably be needed to factor a cryptographically significant number is of the order of 10 million. For all this theory I'd better mention that the largest successful (public) brute force attack was against a 64bit RC4 cipher so even if AES-128 were reduced to half it would need an entire internet of idle quantum computers ... and as for AES-256, well that's 18446744073709551616 quantum internets to you.

Xanza, The machine you mention is tiny compared to the sort of machine that's needed to defeat the encryption used by BTSync. The normal aim for modern encryption is to defeat Maxwell's demon, ie use the basic laws of thermodynamics to calculate the sort of brute search that could be done (ignore the cost of testing for a match, it's not relevant) if the 'computer' were perfect. That's why BTSync's default key length was upped from 128 bits to 160 bits. With a 128bit key it would just about possible that somewhere in the universe there are two identical random 128bit numbers; if the universe were entirely made of random numbers. With 160bits you need (a large) multiple number of universes. But in one way you're not wrong; idiots and rubber hoses will both trump maths books.

You need to provide logs from all machines. Could be a permissions issue; perhaps something to do with quotas. Could be an MTU issue; only small packets are getting through. Could be a lot of things.

First you'll need to find if it actually has copied everything or not... Do a full comparison of the shares; sfv/md5sum or something. Second turn on debug logging and look at the sync.log.

Harold, You've fallen into the trap that a lot of people do. XP64 is identical to Windows 2003, Like Windows 2003 it doesn't NEED a SP3 to be the same as XP SP3 because all the changes from XP SP3 are included in windows 2003 SP2. Not supporting XP i86 SP2 is not a good reason for not supporting XP x64 SP2. In fact supporting XP i86 SP3 is a good reason to support XP x64 SP2 as well. I also note that Windows 2003 is on extended support for a year longer than XP32 so XP64 will continue to get security patches well after XP32; but they'll probably have to be installed manually.

Oh, "IO Error", that explains the hung process ... tell me how good are your backups? BTSync will have no access to do anything that may result in a hung process if you're not running as root. BTSync has no need to do anything that may result in a hung process. Your problem isn't anything to do with BTSync. If you check your /var/log/kern.log file you will probably find hard disk errors. With luck you'll be able to transfer most of your system to a new disk before it dies for good, but you've already lost at least one file; if it's not on a backup. Best of luck.