Generate Very Secure and Random BTSync Secrete in Linux

[TheDurtch]

I have written a very simple code that uses /dev/random to generate your secrets

https://pastebin.com/siAh1ksW

Let me know what you think or if there are any improvement that can be made. I know it is "slow" but /dev/random is "slow" so that can't be fix and I WON'T use /dev/urandom just for the speed boost.

EDIT: I would like to be able to "silence" dd cause it will sometime cut my secret in half

EDIT_EDIT: I just reallized i just mispelled Secret so many times

EDIT: dd is now quite. Thanks ultramancool.

EDIT: Thanks LazyWolf for letting me use part of your script.

[handle]

Seems cool, but bittorrent sync already uses /dev/random (or /dev/urandom, but that's also very secure) to generate secrets and so I don't really see a use for this

[ultramancool]

If you want dd to shut up, you need to redirect dd's stderr output like this:

 cat /dev/urandom | dd if=/dev/stdin bs=1 count=128 iflag=fullblock 2>/dev/null | base64 -i | base64

[rdebath]

That's not that good.

You are grabbing huge amounts of data from /dev/random when you only need 256 BITS and then you almost throw away a lot of those bits by encoding the data twice. Luckily BTSync saves you by hashing the long string it gets from you down to 256 bits.

All you need to do is this ...

head -c 32 /dev/random | base64

This does usually take a little while to run because Linux very carefully underestimates the amount of randomness available in it's pool. You're probably more than safe enough using /dev/urandom in reality.

Though actually, my preferred method is to provide lots of real random data to a hash command perhaps like this:

cat /var/log/syslog.0 | sha256sum - | xxd -r -p | base64

[ultramancool]

That's not that good.

You are grabbing huge amounts of data from /dev/random when you only need 256 BITS and then you almost throw away a lot of those bits by encoding the data twice. Luckily BTSync saves you by hashing the long string it gets from you down to 256 bits.

All you need to do is this ...

head -c 32 /dev/random | base64

This does usually take a little while to run because Linux very carefully underestimates the amount of randomness available in it's pool. You're probably more than safe enough using /dev/urandom in reality.

All good and true.

Though actually, my preferred method is to provide lots of real random data to a hash command perhaps like this:

cat /var/log/syslog.0 | sha256sum - | xxd -r -p | base64

You just went fucking batshit, /dev/urandom is _much_ more secure and has much higher entropy than your syslog. Maybe this could be used as one source of entropy, but using it as the sole source is a terrible idea. Remember that the kernel already takes disk writes into account in its entropy gathering.

[rdebath]

Actually, it's a lot better than you imagine, you see there are firewall logs in there too. All that yummy randomness donated to me by the dumb script kiddies of the world.

BTW: The kernel takes account of the timing of the disk writes which is a physical process and so subject to some randomness, the actual content can't really be assumed to have more than zero bits of entropy in the general case.

But if you want REAL randomness you need to go here: https://www.fourmila...e_generate.html or here: https://www.random.org/ or here: http://www.randomser...ient/random.php

[LazyWolf]

Not sure if it has been fixed yet but I found that when a base64 string used as a key contained backslashes sync would ignore the rest of the key...

Say your secrete was...

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\BBBBBBBBBBBBBBBBBBBBBBBB

I was able to use the key AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

That was in 1.0. and I haven't tested but I use have a little script in my bin dir...

#!/bin/bash
key=`openssl rand 1024 -base64 | tr '/\n' '\0' | tr '+' '\0' | tr '[a-z]' '\0' | tr '=' '\0'`
echo "A"$key
exit

[TheDurtch]

Seems cool, but bittorrent sync already uses /dev/random (or /dev/urandom, but that's also very secure) to generate secrets and so I don't really see a use for this

I use it for really long keys since I don't like the short keys it gives me.

That's not that good.

You are grabbing huge amounts of data from /dev/random when you only need 256 BITS and then you almost throw away a lot of those bits by encoding the data twice. Luckily BTSync saves you by hashing the long string it gets from you down to 256 bits.

I encode it twice to get rid the slashes that can appear like so

user@Kate ~ $ head -c 32 /dev/random | base64
tisIvd+Shp/aceh+Ax/hVzcrJykTzS6vPwNmfhlgX9g=

I had problems the last time i had slashes in my secret

If you want dd to shut up, you need to redirect dd's stderr output like this:

cat /dev/urandom | dd if=/dev/stdin bs=1 count=128 iflag=fullblock 2>/dev/null | base64 -i | base64

Thanks worked great I will keep that in mind when I work on more scripts.

Not sure if it has been fixed yet but I found that when a base64 string used as a key contained backslashes sync would ignore the rest of the key...

Say your secrete was...

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\BBBBBBBBBBBBBBBBBBBBBBBB

I was able to use the key AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

That was in 1.0. and I haven't tested but I use have a little script in my bin dir...

#!/bin/bash
key=`openssl rand 1024 -base64 | tr '/\n' '\0' | tr '+' '\0' | tr '[a-z]' '\0' | tr '=' '\0'`
echo "A"$key
exit

I tried this script and it works but they are only upper cased characters. I like to have mixed case.

I removed

 tr '[a-z]' '\0' |

and i like it much better.

Would you mind if i take the last bit of you r script and added it to mine?

[LazyWolf]

Have at it, I like having mixed case as well but I liked this method because it made it harder to predict the end length.

Here is a more cleaned up version...

openssl rand 1024 -base64 | sed -e ':a;N;$!ba;s/\n//g' -e 's/[^a-zA-Z0-9]//g'

[TheDurtch]

Thanks and updated. I kept my cat|dd script cause I fill /dev/random up really quickly on my server.