Generating Longer Keys

[Nazerb]

It is mentioned in the offical Faq that you can generate your own longer keys for additional security.

What is a "secret" and how does it work?
A secret is a key that connects different devices and joins them together. We automatically generate secrets to ensure their uniqueness. Since each secret is 20 bytes long, it is virtually impossible for the same secret to be automatically generated in two separate instances. After a folder is added to BitTorrent Sync, the Secret is stored in its advanced preferences and can be accessed by right click on a folder in the “Folders’ tab.

There are 3 types of Secrets: master (full access) secret, read only secret for one-way sync and one-time secrets (both full access and read-only). Read only and one-time secrets may be generated only for folders operated by master secrets.

If you are concerned about security, BitTorrent Sync provides opportunity to regularly generate new Secrets for a folder, or replace an existing secret with your own Base64 string more than 40 characters long. The new folder secret should be re-entered on all the devices in sync.

 

 

But i was wondering how would i go about generating my own longer keys that fit the format required, as if i just type a bunch of letters, i get a incorrect format notification. And hows it possible to make this a secure longer key?

 

Thanks for any help,

Nazerb

 

Edit: The only way i have worked it out is by joining two generated keys.

Edited September 17, 2013 by Nazerb

[dmason]

I never noticed that you could have your own longer keys. Interesting!

[dmason]

I'm not sure how to do it with the btsync program but here's how I'm getting longer keys in OS X.

 

$ head -c 1024 /dev/random | base64

 

Standard output is a pretty darn long base64 string that I have been able to use as a secret for shares. You can adjust the count as necessary. It would be cool if we could get a --generate-super-duper-secret 1024 (in addition to the already available --generate-secret) or something like that.

 

Edit: For some reason that command on my Linux machines seems to just sit there. Replacing /dev/random with /dev/urandom seems to work fine. I'm unsure as to why it does not work. If anyone knows why please let me know.

[nils]

/dev/random can block if it does not have enough entropy i.e. sources it uses to create pseudo-random numbers. /dev/urandom will not block, which could in theory lead to sequences which could be cracked - if knowledge of the system is available to the attacker. As this is highly improbable /dev/urandom can be used, see http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom

 

@dmason: thank you for the commandline version to generating new secrets

[jvhaarst]

Truly random should be this:

curl --silent -A "your@e-mail.adress" 'http://www.random.org/strings/?num=6&len=8&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new' | tr -d '\n' ; echo

This fetches random strings from random.org , removes the newlines so we get a nice long string. Here I chose 48, but you can use anything you like of course.

If you want to use this, please put your e-mail address in, so the owners of random.org can contact you in case you misbehave.

[dmason]

@jvhaarst Thanks! The only thing I'd change is to use https. Works great!

 

@nils The entropy thing makes total sense now. I'm still surprised at how quickly it works on OS X. That leads me to believe that it's either better at collecting entropy or somehow cheating. Either way thank you for the explanation.

[Nazerb]

Cool thanks for the advice Helps very much How long are you guys going with your keys? Because I guess longers more secure, but whats too long?

Thanks,

Naz

[ChrisH]

This fetches random strings from random.org , removes the newlines so we get a nice long string. Here I chose 48, but you can use anything you like of course.

 

Yeah, great idea. Let's all have someone else generate our keys and get them to us via an unencrypted channel.

It's not like there's anyone monitoring the internet or something.

[deadserious]

I have been SHA512 hashing a passphrase and then base64 encoding.  It seems to work fine.

 

I just wish I knew how to generate the Read Only key for it too.  

[strongergravity]

I used freepasswordgenerator.com You select upper, lower, and numbers, and then tell it how long you want.

[azar]

strongergravity

I think it is AN EXTREMELY BAD IDEA not advisable to use password generator as the one you have mentioned.

 

Connection to the site is insecure (no SSL), so anyone monitoring connections can snatch up your password as easy as a snap and gain access to your files. Okay, apparently it only works if JS is enabled, and seemingly everything happens on the client side.

 

And what about how it generates random numbers? How big is the entropy pool?

 

Personally, on all OS'es I use KeePass to generate and to store my keys, and always check an option to "Collect additional entropy" when generating a key.

[TheDurtch]

I use this on linux. Works very well for me and I get very long keys.
 

cat /dev/random | dd if=/dev/stdin bs=1 count=256 iflag=fullblock 2>/dev/null | base64 -i |  sed -e ':a;N;$!ba;s/\n//g' -e 's/[^a-zA-Z0-9]//g'

Sample: 1PwzT2xduLA4DujNydHmG8Nw6ZOo0DhKOL12FD3ZMA9K4yWbomTZFrTntkPCmwWfaXabTt5RoYgjfpgAMOmjlrC4CbT5TvZOlPxUJlnOlvXmV6xLQJUt7WNF6zFzyPagIDzrXo6kkzJa12N8lrvnflCaZnQhIETZzGDihHQ2R1uXuNZqknKTtir3Wdl6HDodCl9R5Lz4lpZjplFKhS17xWt0Jitvk0zbIAi9VtTw8STeHT311r5u1dXefBsm9uDsRidgDyu52ObFJZrSS4mCtEMLnvj8eO1F3VGxicnzBHbqkFnVEOIWjgCVS8L8OBEDcTHaVTno4a2rRI4eEkshWPYM6w

you can change 256 to 128, 64, 32 or any other number you want and it will make a key according to the number you put in.

[affinity]

TheDurtch  ... why so complicated?

 

"base64 -w0"

- will give you a string of chars without new lines, so no mucking around with sed to join and adjust lines.

 

base64 gives you a couple of extra characters, the "+" and "/" symbols,  why exclude them?

 

Here's another variation for you:

head -c $((256/4*3)) /dev/random|base64 -w0

 

[Mac users can omit -w0 or use -b0 instead  .... don't ask me why it is different, BSD might be the same as for Mac]

 

You can change 256 to any number you like.  It also won't matter if the base64 is padded with "=" signs at the end for the secret (the above won't pad anyway).  If the chosen number is perfectly divisible by 4, then you'll get the exact same number of characters back (which is a bit different to your version) -- and you won't be getting too many random characters to work with (just enough to achieve the result).

[d9nut]

I use 'pwgen' - specifically 'pwgen 100 1'

# pwgen 100 1phohraequet2yaej9ihe3gaeghoh9Aerudei6ceike8hi5wei5xu2UTahkieL1TaxaeNgieloyaequooP5eel9foi0Igai9Thai2

[affinity]

pwgen gets results too quickly,even for the "-s" option ... so it won't be using /dev/random