Can someone just guess shared secrets?

[Disappointed Cat]

So he just enters the secret (which he knows) on another machine, or renames his device. Then what?

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.

[affinity]

Steve was responding to myself during the podcast, but he said something that I think has a solution rather than being a problem.

Let's say with ssh for instance that you can accept protocol 1 and protocol 2 -- you would want protocol 2 as an improved protocol for ssh. Now a protocol 2 for BTSync.... let every installation have a long generated "secret" for the client, such secret should be able to be set specifically, just like changing ports. Using protocol 2 of BTSync, you send the secret for the sync AND also send the user's own "installation" secret -- so a double length secret now.

Set your BTSync to only accept protocol 2 so it requires 2 keys, the sync secret plus the unique "installation or personal" secret. You never do the WPS security flaw of saying, right, the secret is correct, now what is the next auth key? You only accept the remote connection IF both the secret and personal key are correct and you give no indication if one or the other is incorrect -- you simply drop the connection and stop it from proceeding any further; that is you don't accept or reject it, but just drop it. When a connection fails due to being dropped, it should have the same effect as having never found the secret in the first place.

To further secure the installation secret, the user should be able to supply the sha256 of the secret to the approver, by whatever means to help identify themselves -- their own secret is never known by any other party, but the sha256 of the secret is sent.

[rdebath]

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.

[btusername]

I do agree. However cryptographically correct those who say it is not necessary may be, I am a supporter of the lock/unlock feature. I think even Steve was coming round to that way of thinking in the end!

the problem I can forsee with the lock/unlock feature is this.

Attacker finds a secret key that has been locked (he finds the key and some kind of even occurs).

Attacker now knows hes found something worth looking into.

Attacker spoofs his IP address, uses TOR, or whatever method to bypass an IP blocklist as puprosed in the past for this lock/unlock setup.

Attacker then sets up a system to continue to test this secret, or saves it for testing in the future.

A much better solution to this problem would have been to implement a PGP or GPG solution where there is a private and public key.

[btusername]

actually a perfect example is with the recent revilations of the NSA leaks.

to share/sync, you have to know and hand out your "secret". If your sending that secret key over facebook, aim, yahoo, etc... theres a good chance big brother has it and will use it.

the lock/unlock feature wouldnt really help here as if you are handing out your secret key, there is a good chance you are giving it to someone else to sync with and the folder/file will be unlocked at that time.

Heck M$ follows all links sent via skype. It would be failry easy for them to implement a simular feature to log and sync any secret key sent.

Solution? Send your keys via email using PGP/GPG encryption, or maybe depending on the security and outcome of the new messenger service Heml.is ... or a deaddrop

https://github.com/deaddrop/deaddrop

[Brian Buchanan]

Can someone apply the Birthday Problem to the numbers in this keyspace? I'd like to know how many secrets are needed before there's a greater than 0 possibility of a collision?

[verloren]

Well if you have two secrets then you have a greater than zero possibility of a collision, though the probability really is very small. More interestingly, sing the first approximation from http://en.wikipedia.org/wiki/Birthday_problem#Approximations we can work out how many secrets there would need to be before we had a 50/50 chance of a collision. Assuming my maths is right, which is a massive assumption, it looks like you'd need 12 billion billion billion secrets to get those odds. That's about 240 million billion secrets for every human that has ever existed.

The maths: http://www.wolframalpha.com/input/?i=1+-+e%5E%28-%28%281.2*10%5E28%29*%281.2*10%5E28%29%29%2F%282*36%5E36%29%29

[Brian Buchanan]

Thanks. I'd hate to be the first person that's victim of a collision. Can you find how many secrets are needed for a 1% chance of collision and a 0.1% chance? (rather than 50%) (Sorry I couldn't figure it out myself, I just don't understand the math)

Edit: I just saw the Probability table (and reading the Birthday Attack) for 128-bit key and the 1% probability for 128-bit is 1.6×10⁷⁶ which is huge and the secret is 168-bit? and the keyspace would be 2⁴⁰ times bigger?

[verloren]

1% ~ 4.8 billion billion billion

0.1% ~ 480 million billion billion

To demonstrate how unlikely even that last number is, if every human alive had started creating secrets when the universe began, at a rate of 9 per minute, we'd now have hit that 0.1% chance of a collision.

[rdebath]

I raised the issue of the birthday problem when the default keys were 128 bits; with that there is a very borderline chance that someone may be able to break something so that there is just barely a chance of a birthday attack within the foreseeable future.

The minimum key was extended to 160 bits and fixed this.

[Brian Buchanan]

Each share has two keys right? RW and RO? So those probability numbers should be halved?

This scheme is very interesting as it treats legitimate and illegitimate users the same. The issue is the possibility of legitimate users colliding. With a username & password legitimate users will never collide as they use their username, and so illegitimate users only have to guess the users password.

[y7k]

Maybe when 1 host is looking for the ones which have a specific secret, the protocol should systematically wait at least 1 or 2 seconds before answering to subsequent requests from the same host/IP (without distinction if it's the same or a different key), so that a brute force attack would be impossible to do without controlling all IPs of the world?

It would make parts of the protocol slower, but it would greatly enhance security at a very low cost...

Or maybe the use of some kind of 2-step key part exchange, with at least 1 or 2 seconds between steps originating from one host?

Generally, adding some delay is a very good approach against brute force attacks and thus against guessing keys...

[ChrisH]

+1 for the tarpit idea.