[Security]

Moin,

You're absolutely right that using tr to drop characters not in the base64 alphabet results in a secure random key (eventually).

My point was that this is entirely independent of the alphabet.

If the generated key is considered base64 encoded but can never contain a + or / character, I have a slightly better than 50% chance of guessing the next bit in the encoded stream.

Ahh, here's the point of confusion: The underlying alphabet in the 'tr approach' isn't base64, it's whatever alphabet the tr user choose. Every character in that alphabet will have exactly(!) equal probability (if the underlying random byte generator was working correctly). I'm assuming the confusion stems from a slight switch in topics. We started out with BTsync custom secrets, where the alphabet is indeed base64, but the commenter using 'tr' for the first time was, to my understanding, speaking about web passwords in general.

Also note that in both cases -- BTsync custom secret, password -- even if you don't get *maximum* entropy per character according to whatever externally defined alphabet was imposed on you, you still get a very *well defined* entropy per character if your alphabet is a subset of the actual one. You can thus compensate for lost entropy by just making your secret/password longer, if allowed by the mechanism. If I interpret the things I've read correctly, then the BTsync custom secret can be of arbitrary length > 40 characters and is mostly used in things like SHA1. For this use case the entropy per character is actually irrelevant, as long as there's enough total entropy.

--

Henryk Plötz

Grüße aus Berlin

[Security]

Moin,

Your modified pseduo-random stream does not pass the next-bit test; knowing (or guessing) your enforced distribution gives me a much better than 50% chance to guess the next bit in the stream.

[…] I'd recommend piping the /dev/random output through a utility like "base64

Huh? Of course, if you restrict your alphabet per character then you're losing bit-by-bit-randomness. This is no different with base64 or any other restricted alphabet. The test is meaningless for this case. Important is the entropy per character, and here both approaches differ (and both are good):

• base64: Map an integral number of bits onto a different integral number of bits. In base64 3*8 bit (3 characters with 8 bit entropy each) become 4*6 (4 character with 6 bit each).
  
• tr: Check whether the value is inside your (arbitrarily defined) allowable set. If yes, output, if not, discard. The resultant stream will have maximum entropy, not necessarily with an integral number of bits per character but still with equal distribution per character over the entire character set.
  

A *bad* example that actually introduces a bias would be anything that doesn't discard but instead translates only a sub-set. E.g. the algorithm that was used for EC card PINs in the dark past was: Convert to base-16 (no bias introduced here), then translate A-F to 0-5. This gave a considerable bias towards the numbers 0 through 5, since there were two possibilities that mapped there. (I think they also additionally prevented having 0 in the first place, making things even worse.)

--

Henryk Plötz

Grüße aus Berlin

[Security]

Moin,

When worried about entropy used in your random key, please take a look at http://random.org or http://www.fourmilab.ch/hotbits/

I use these to generate my own key, not depending on PRNG's.

Do not, do not, DO NOT use any sort of external service to create 'random' keys for you.

a) It's simply stupid and quite against the concept of private/secret keys to let others have anything to do with them. I especially like (in a sarcastic, face-palming sort of way) sites like https://www.grc.com/passwords.htm that jabber on about how they are secure and safe and using SSL and whatnot and yet constitute a perfect example of an implemented attack.

It's completely, utterly and in every other way unnecessary. Every modern operating system has a facility for random number generation from hardware sources and has had this for years. This incorporates sources such as keyboard/mouse events, hard disk/network interrupts and others. Some modern CPUs (and even some less modern chipsets) also have dedicated hardware random number generators which generally will automatically be picked up and incorporated into the OS random pool. Bittorrent sync already used the right buzzwords by telling us they retrieve their entropy from dev/random under Linux/MacOS and CryptoAPI under Windows.

--

Henryk Plötz

Grüße aus Berlin

[Can't sync mounted drives in Linux]

GVFS uses FUSE to make directories visible to programs not using the Gnome framework, mounted under ~/.gvfs or /run/user/${USER}/gvfs (at least that's what it's doing for me since the last Ubuntu upgrade). FUSE mounted file systems (similar to NFS) generally are more restrictive with regards to user access. You can usually not override permissions by just being root, and even if the file system permissions would allow other users access, this is filtered by FUSE which by default prevents access to users other than the mounting user.

You didn't specify, but I suspect it will only work if you start the btsync client as exactly the same user that used GVFS. (Or find some way to relax the FUSE options, see man mount.fuse, but I'm not sure that will work with GVFS.)

--

Henryk Plötz

Grüße aus Berlin

[Security]

@mrf I see your problem, but all your calculations and assumptions are way off.

Assuming the secret has full entropy in any case (http://labs.bittorre...ogy.html#secret mentions using dev/random or cryptoapi for that) we have, for the various mentioned secret lengths:

• 32 characters of base-32 text, meaning 5 bits per character: 160 bit of entropy
  
• 40 characters of base-64 text, meaning 6 bits per character: 240 bit of entropy
  

(@verloren: Thinking of security in terms of "number of possible combinations" usually leads to ununderstandable numbers and in security discussions should be reserved to snake-oil vendors who want to dazzle you with incomprehensibly large numbers with no real meaning. Just express everything in log₂, that is: bits, and everything becomes so much easier. Especially since multiplication becomes simple addition.)

@mrf: The security of AES-128 is about 128 bits. It is generally agreed upon that any number exceeding the ~80-90 bit mark falls into the "impossible" category. There are various nice calculations about the effort needed to break a 128 bit key with results like "storage: 1 result per atom -> more atoms than there are in the universe", "more time than is left before our solar system is swallowed by our sun" and "the energy required would boil up all the oceans on planet earth". I think full-entropy(!) keys of this magnitude can safely be said to not be worth worrying about.

Compare your folder name suggestion: English language has an entropy of about 1-2 bits per character, folder names will probably be about 10 characters average (note: this is the only number I've pulled out of my ass), leaving you with about 15 bits of additional entropy. Compared to the 160 bit we talked about before that's next to nothing. But adds considerable inconvenience (see Automatic Coding's post).

@mrf The other point you were talking about (undirected attacks) is called a birthday attack. Instead of breaking a a particular key, in this instance an attacker just wants to find *any* two identical secrets. For an attack on a specific secret of length 160 bits, an attacker can expect to succeed on average after 2¹⁵⁹ tries. For a birthday attack success will, on average, reach a high probability after approximately 2⁸⁰ attempts (half bit size).

Now: 80 bits is still insanely large. Additionally think about what it means: The collision the attacker would find would with overwhelming probability be one with his own attacks.

More realistically attacking *any* other secret should be treated as subtracting from the secret length. Say every person on earth (7 billion) had a thousand synced folders, leading to 7*10¹² distinct secrets on the network. In log₂ that's about 43. The complexity to attack *any* folder now is 160-43 = 117 bit. Have fun boiling the oceans while waiting for the sun to go red giant! :-)

@kos13/bittorrent sync team: I still have problems understanding the security properties. One of the issues is the exact secret length. The number above (32 characters base-32) I came up with by counting in the screenshots. Your website sometimes mentions 21 bytes, which is different from 160 bits. Also you offer up the encryption algorithm to be AES-256, which whould require a 256 bit key. Then there's the base-64 thing with still a different number.

A concise table with exact security parameters (paying attention to the distinction between bytes, bits and characters) would be nice.

Also, coming from sort of a security background, I don't fully understand how read-only/time-limited keys are supposed to work. It would be really great if you had a protocol description somewhere. How does a secret become a key? How is the actual transmission protected?

--

Henryk Plötz

Grüße aus Berlin