Disappointed Cat

Members
  • Posts

    299
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Disappointed Cat

  1. Good point. How could I not think of that? By that time all other clients should be using the new key. If there is a client with the old key and there is none currently online with the new key then they would keep sharing until one comes online. Or maybe the revoked client could be tricked into leaving the swarm. Also it wouldn't just work with the device name only and it's supposed to be transparent so the client being revoked wouldn't know until it's too late. Anyway, this is an idea born dead. Maybe custom trackers could be used for optional central management one day.
  2. That would exclude everything (including the files). I'd try /*/ or /*/*. The latter would leave empty directories on the other peers.
  3. Even though lock/unlock is totally unnecessary, the ability to ban peers from the swarm could be really useful. For example If I want to revoke access from a peer I'd have to change the secret everywhere. I think this could be propagated throughout the peers. Banning clients is just as much pain as lock/unlock but sending out a new secret excluding the revoked clients, the rest could transparently change the secret to a new one. Now I don't know if this could be implemented securely but if yes this is a must have.
  4. Check out this thread. I don't know about Mac, and Linux doesn't has this problem.
  5. It's still rough around the edges. You need to stop all clients if you're adding ingnore rules that will affect already indexed files. PS: It's been discussed in multiple topics.
  6. Thanks. I'm looking forward to it. You should give the heads up here too when you're starting to send out details about the app - just in case.
  7. Then could you look into it please? I used the same email address I'm using here. The subscription page says I'm on it (droid), but I didn't recieve anything. Interestingly I get newsletters and stuff from no-reply@bittorrent so my emails are working.
  8. Are there confirmation mails sent after subscribing like someone quoted earlier? I subbed to android yesterday and still didn't recieve anything - if it's a manual process then forgive my impatience.
  9. That's the point. The default secret size and charset doesn't generate the entire key space. Not that all this trouble would be worth it for a small portion of the key space when you can generate big enough secrets too.
  10. Good points and I completely agree with you. But to keep the interesting discussion rolling: (In a targeted attack scenario.) The attackers know the secret is 32+ alpha-numeric characters and they easily have the hash and know the hashing algorithm. Let's assume they have quantum or alien technology ahead of this time. There won't be many hash collisions with the given length of the secrets so even if they have to send packets to verify the secret it's only a few times. Of course we're way out of the ballpark here. Heck they could even compromise the tracker(s) and brute force all valid hashes. Secrets could be further strengthened if the app would do say 10 million rounds on it before generating the final key. So it would be pointless to try and brute force the secret instead of brute forcing the absolute entire key space. Not much and useless with self-generated longer secrets - just a thought. Back in the real world any possible breach will be because of users sending secrets in plain text everywhere.
  11. I also tried to rewrite /btsync to /gui without luck. All I could come up with is simplifying your code: Redirect /btsync /gui <Location /gui> ProxyPass http://127.0.0.1:8888/gui ProxyPassReverse http://127.0.0.1:8888/gui ...
  12. Indeed. Thanks for bringing it up. I just switched to it so I can use my global base auth configuration with fail2ban. If anyone is interested in this, here's how: * Configure base auth like you'd normally do in a location or directory block. * Send btsync a static auth header: STRING=BASE64(user:pass) AuthUserFile /etc/apache2/htpasswd AuthGroupFile /etc/apache2/htgroup AuthName "asdfs" AuthType Basic Require group admin RequestHeader set Authorization "Basic STRING" This also sort of eliminates the problem of btsync stroring passwords in clear text. Listening on localhost only.. You can set it to any dumb thing and just authenticate over the proxy.
  13. Once they manage to sustain and stabilize them I think qubits will quickly increase like transistors up to billions. What does a 128 bit key worth then? Or a 160 bit hash? The developers did say they're planning long term.
  14. I used Notepad++. * Insert the certificate text after selfcertLEN: - after removing the original of course. * Apply unix EOL conversion. * Then select the inserted text (including the last new line) and write the length after 'selfcert' and before the ':'. (The status bar will show how many characters you selected.) Like this - first the public, then the private key: selfcert1880:-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- As for the RSA part: It didn't work for me if I only wrote BEGIN and END PRIVATE KEY as it is in the original file. Edit: You did try to access it via https://host:8888/ right? If you want to ommit the port you'd need to change the webUI's listening port to 443, assuming it wouldn't collide with your webserver.
  15. If we're talking about theory and what ifs then it's worth mentioning that quantum computers may be only 5-10 years away. That halfs the time needed to brute force keys so we would need 256 bits to be as secure in the post-quantum age as with 128 bits now. Prime factor based public keys will become vulnerable too. The good question is who will be able to afford them. Google and NASA already has a joint project going to research machine learning.
  16. I don't. It's just inconvenient configuration. Things to look out for: - Using (BEGIN|END) RSA PRIVATE KEY instead of just (BEGIN|END) PRIVATE KEY - Windows EOL conversion and so the length of the block You could also use a bencode editor.
  17. The webUI supports SSL. Am I the only one who tried it without hacking around first? Although to change the certificate to your own you have to edit the settings.dat file manually, and it doesn't log failed login attempts so it can't be hooked up with fail2ban.
  18. If you're using Windows you can try junction points (mklink /J name target) for the same effect. Actually, even BTSync synchronizes them because it can only recognize unix symlinks but not windows symlinks. Edit: It appears Dropbox takes more resources when syncing a folder with a SyncID file, but it's still low. It's probably because both apps are checking the lock on the file.
  19. If you run Dropbox on Linux you can use symlinks to include specific directories in Dropbox. Anyway what kind CPU can't deal with syncing one file frequently?
  20. I found a few .!sync files lying around for weeks. I think this is a byproduct of changing, deleting files while they're being synced - most of them were deleted files. If not removing derelict .!sync files is intended then there should be a feature that notifies the user about them.
  21. This: /folder1/folderX The leading '/' is relative to the sync root and not the system root. I like to avoid using the leading slashes though because that way you can't use the .SyncIgnore files as an ignore list with 'tar' for instance.
  22. I think Peer Exchange would suffice instead of a full blown tracker and PEX is already an implemented feature in the torrent client. You only need a few known hosts and the tracker can be disabled. The only thing left that you can't control is the periodical DHT flood but at some point I think everything will be configurable. I can't wait.
  23. On a related topic: Please disable DHT completely if no shares are using it.