Can someone just guess shared secrets?


Recommended Posts

The UUID needn't be a "standard" type, it can be another full secret.

Again, maths is maths, people win Lotto -- not many, but they do win. Relying on pure random chance, you would be extremely unlikely to ever be compromised (unless the random generator is somehow flawed, then you are more likely to be compromised), but it is still possible; big numbers don't mean impossible, just extremely unlikely.

Link to post
Share on other sites
  • Replies 62
  • Created
  • Last Reply

Yup, absolutely right. Maths is maths.

Chance of winning the lottery ...

14000000 : 1

Chance of guessing a BTSync (160bit) key.

1461501637330902918203684832716283019655932542976 : 1

The lottery gets won every week, the BTSync key won't be hit till after the heat death of the universe ...

(or the big crunch, whichever comes first)

It ain't gonna happen man.

Link to post
Share on other sites
  • 2 weeks later...
  • 2 weeks later...

CEHv7 here -- let me share an industry secret with you. Security is nothing more than blanket on a cold night in most situations. There is usually a way around every type of security, even strong entropy.

Realistically if a process could be developed to 'test' keys for validity this entire program would become obsolete (the way it's designed currently) immediately. Any person can rent a supercomputer from Amazon (AWS) and would be able to run yottabytes of hashes per minute. For anyone that doubts me, consider the specs:

3,809 Octo-Core Processors (30,472 total cores)

27TB of RAM

2PB of Storage

Sure, it would cost you $1,279 per hour to use it, but with that kind of power (30th most powerful supercomputer in the world at those specs) it would only take you an hour to find a massive number of keys (maybe thousands) -- even with strong entropy.

Granted this situation is only viable if someone were to develop a way to 'test' keys for validity; I'm merely saying, if nothing is done about this single key system, this program will quickly out-date itself.

However, for testing purposes, and for general use (syncing simple paperwork, school work, MP3's) this program meets the mark and works fine. Just don't store banking information in your Sync folder and you'll be fine, even if there is a breach.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

If there will be an effective way to find a collision on 160 bits fully random key, there will be much bigger security problems than Sync.

Keep in mind one more thing, unless this is targeted attack, you will need to send and receive UDP packet to verify collision. It naturally adds 5-10ms for each key not mentioning requirement for the network and CPU. CPU and network will throttle any brute force attack at once.

Sync secret approach is by far more secure than any login/password and secret question approach. It is just not get used by mass market. We do take this pain to explain this solution to people, since this is a right way. It is much easier to implement login/password based approach but it is so insecure, so we don't want to take responsibility by providing bad security for your data.

Final question, would you replace 160 bits random string with YourLoginThatIsEasyToGuessWithSomePasswordYouBelieaveIsSecure string?

Link to post
Share on other sites

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.

Link to post
Share on other sites

Final question, would you replace 160 bits random string with YourLoginThatIsEasyToGuessWithSomePasswordYouBelieaveIsSecure string?

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.

Link to post
Share on other sites

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.

Although ironically as a password it would be more secure if it was spelt wrong because then it's not dictionary attackable ;)

Link to post
Share on other sites

Although ironically as a password it would be more secure if it was spelt wrong because then it's not dictionary attackable ;)

No, clever is out, it is not as /easily/ attack-able with a dictionary, but mis-spellings become part of any good dictionary attack, as does replacing letters with number or symbols.... just a larger dictionary, that's all.

Targeted attack is out of the question on the whole, but random attack isn't /as difficult/, still difficult though.

Oh and from another post, you can run as many iterations as you like to a secret to strengthen it, but at the end of the day, you still only have so many bits to work with. If the attack was done using just the final bits with custom code, then the strengthening wouldn't even count for anything here.

Link to post
Share on other sites
If the attack was done using just the final bits with custom code, then the strengthening wouldn't even count for anything here.

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.

Link to post
Share on other sites

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.

Which is why I would not attempt to break encryption, only 'guess' encryption. I know the characters (a-zA-Z0-9) used, and the range of characters (28-35). It would be much quicker to use 97,510.4 GHz of processing power (~3.2*30,472) and the 27TB of RAM paired with the 2PB HD to set dictionary of hashes instead of attempting to figure out the specific algorithm used to generate the hash.

Granted you'd never be able to use all 97,510.4 Ghz effectively, however, you'd be able to do a lot more side-by-side processing which would help your end result. Again, granted, this is all dependant upon being able to quickly test said keys for validity.

IMO, however, BTSync would be much better off with a SHA-512/384 private key and SHA-0/1 public key -- but that's just my opinion.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Lock/unlock is kind of complicated in p2p. Let me show you the problem. You want to add a new computer (#1) and approved it on computer (#2) while computer (#3) is down. Then #2 goes down, #3 is up. How #3 will learn that #1 is approved to join? The only way is to approve #1 on #3, but this would be a nightmare if you have more than two devices.

Link to post
Share on other sites

kos13 is right, I don't see how something like the lock/unlock feature can be implemented technically And Steve Gibson also mentioned the same problem with trying to implement that feature.

I understand the issues trying to comprehend the security model, but until it's proven that we cannot trust it, I'm perfectly fine the way it is today.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Even though lock/unlock is totally unnecessary, the ability to ban peers from the swarm could be really useful.

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

Link to post
Share on other sites

Lock/unlock is kind of complicated in p2p.

Yes, but it's solvable. Here's my suggestion (including the read-encrypted-only wish from the wishlist thread):

Have four secrets per folder.

1) Master: Can approve new devices, and read and write cleartext. Device approval list is signed and distributed with the folder content.

2) Read/Write (as it is now): Can read and write cleartext, but only devices on the approval list can connect.

3) Read only (as it is now): Can read cleartext, and only devices on the approval list can connect.

4) Store only: Can only read data in its encrypted form, and only the hashes or similar, not the original filenames.

Each device should also have a unique key, guessing an approved device name must obviously not be enough.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.