Security


mrf

Recommended Posts

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.

B) 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

Link to comment
Share on other sites

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

I stand corrected, I totally got caught up into the entropy level of the key generation and started overlooking the blatant obvious problem of someone else getting hold of my key this way.

I will sit in the corner and cry a little if you don't mind. I will be back when I find my brain. OH and if someone could change the "Advanced Member" below my name to "Blithering Idiot" please? :(

As for depleting the entropy pool and the hardware filling the pool, I still stand by what I say. The pool gets depleted quickly and randomness suffers from it. Whether or not this is really quickly exploitable is a matter of debate and implementation.

cat /proc/sys/kernel/random/entropy_avail should hover around 2000 for sufficient entropy. Mine hovers between 5 and 30. :blink:

Link to comment
Share on other sites

Moin,

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.

B) 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

Personally, I use lastpass and let it generate passwords for me.

Although I do concur it means that someone can brute force one of my passwords and gain everything, and if lastpass were to go rough then I'd be screwed, but, I'm too stupid to remember 80 different passwords, so, if I didn't do this then if you brute forced one of my passwords anywhere then you'd have all of my passwords. I feel as though this is a better solution.

FYI:- I used /dev/urandom and tr to generate my secret key, although, I have read somewhere that urandom isn't meant to be secure/what not.

Link to comment
Share on other sites

Personally, I use lastpass and let it generate passwords for me.

Although I do concur it means that someone can brute force one of my passwords and gain everything, and if lastpass were to go rough then I'd be screwed, but, I'm too stupid to remember 80 different passwords, so, if I didn't do this then if you brute forced one of my passwords anywhere then you'd have all of my passwords. I feel as though this is a better solution.

I think what you've got there is a great argument agains the current sorry state of web authentication more than anything else.

FYI:- I used /dev/urandom and tr to generate my secret key, although, I have read somewhere that urandom isn't meant to be secure/what not.

It's not so much that it isn't meant to be secure, it's that it'll give you insecure randomness when it runs out of the good stuff. /dev/random will block until its entropy pool is sufficient, which can happen arbitrarily and for arbitrarily long periods. So is secure, except when it's not, and it won't tell you when it flips between the two modes.

The tr bit is slightly more worrying to me -- unless it was an injective mapping (e.g. switching the encoding alphabet, or replacing all 8s with 7s and all 7s with 8s), you've done some damage to your possibly pristine / possibly already broken randomness.

Link to comment
Share on other sites

I think what you've got there is a great argument agains the current sorry state of web authentication more than anything else.

It's not so much that it isn't meant to be secure, it's that it'll give you insecure randomness when it runs out of the good stuff. /dev/random will block until its entropy pool is sufficient, which can happen arbitrarily and for arbitrarily long periods. So is secure, except when it's not, and it won't tell you when it flips between the two modes.

The tr bit is slightly more worrying to me -- unless it was an injective mapping (e.g. switching the encoding alphabet, or replacing all 8s with 7s and all 7s with 8s), you've done some damage to your possibly pristine / possibly already broken randomness.

I used TR to only extract alphanumeric characters as symbolic characters were giving me issues and HTTP (and my clipboard, *cough* null termination) don't like null, EOF, carriage return, new line, (etc...) ASCII characters.

Link to comment
Share on other sites

I used TR to only extract alphanumeric characters as symbolic characters were giving me issues and HTTP (and my clipboard, *cough* null termination) don't like null, EOF, carriage return, new line, (etc...) ASCII characters.

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.

Again, the correct answer is getting Sync to generate a secure 32-byte secret for you, but if you must do it yourself I'd recommend piping the /dev/random output through a utility like "base64" to get a clipboard-capable string:


</dev/random head -c 32 | base64

Link to comment
Share on other sites

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

Link to comment
Share on other sites

My brain is too full to remember many passwords, much less 32 character (or more) secrets! All of this conversation about brute forcing passwords or secrets just makes my hair hurt. What's the point of military grade security around these secrets if I have to haul them manually from one device to another??

Emailing them is the only "sane" way of moving them around right now and it could hardly be less secure.

The irony of this is apparently lost in the crowd...............or else I'm completely missing something.

In spite of that, I am eagerly awaiting further development of BTSync. It still seems to be the only viable alternative to the dead and gone Live Mesh. I am reluctant to add more folders to BTSync right now (I'm on 1.0.116 on Win 7 systems) because of continuing reports of folders/files being deleted somewhat inexplicably. Until I understand just how and why that is happening, I can't risk the time.

Link to comment
Share on other sites

In summary:

1. A "secret" really amounts to an address. BitTorrent has neglected to install a front door at each address.

2. There is a threat from botnets, hackers & anyone who cares enough to write a script. How many bots are there in a botnet? How many addresses are inhabited today - and in the future? Is there potentially a pattern to secret generating that may be spotted which isn't currently obvious?

On the one hand - yes it really would be astronomically "unlucky" for *you* to be robbed - even though *you* is plural. Should that unlucky day arrive for someone - it may be a shame there was no front door to close. I'd like to make the following 2 suggestions.

1) Add a "Lock / Open" facility. When users are happy with a client network setup any connected client user should be able to click a "Lock / Open" button to lock the network. When locked, BTSync should not permit any more clients on that share (i.e. simply ignore any new IP requests to sync). Clicking the button again will allow new clients to connect to the shared folder. To do this, each new BTSync client will probably need some sort of local folder specific GUID - with all other known connected clients being listed on a shared GUID list. Only listed GUIDs would be synced with.

2) BTSync should require a 2nd secret (32+ chars) when first connecting to an existing secret / client pool. Failing to enter secret #2 correctly five times would result in all secret #1 sharing clients blocking the requester's IP address indefinitely. Some hidden, plain-text IP blacklist file would be shared between clients. Any client(s) can therefore remove an IP (or all IPs).

Link to comment
Share on other sites

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)

You're absolutely right that using tr to drop characters not in the base64 alphabet results in a secure random key (eventually). Perhaps I jumped to the wrong conclusion, but I read "alphanumeric" as [a-zA-Z0-9] and not [a-zA-Z0-9+/] (the latter being the base64 alphabet). In either case, I was referring to the distribution of the encoded bits, not the distribution of the bits in the encoding. The bit-per-bit premium we pay in base64 introduces redundancy (reduces entropy) to facilitate transmission, but the whole purpose of encoding is that the encoded bits retain maximum entropy. 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.

In summary:

1. A "secret" really amounts to an address. BitTorrent has neglected to install a front door at each address.

2. There is a threat from botnets, hackers & anyone who cares enough to write a script. How many bots are there in a botnet? How many addresses are inhabited today - and in the future? Is there potentially a pattern to secret generating that may be spotted which isn't currently obvious?

On the one hand - yes it really would be astronomically "unlucky" for *you* to be robbed - even though *you* is plural. Should that unlucky day arrive for someone - it may be a shame there was no front door to close. I'd like to make the following 2 suggestions.

Not astronomically unlucky -- the stars exist, whereas the chance a collision will happen is so small it's reasonable to say it's impossible. Note that almost all of the web's infrastructure is guarded with public-key cryptography, which in your analogy, is also an address (in an unimaginably vast space) that lacks a front door.

That said, a whitelist like #1 is reasonable and currently achievable (disable the relay server, tracker, and LAN search and use only predefined hosts and I think you're there). As for #2, I believe penalizing incorrect secret attempts has been suggested and accepted before, but I'd posit that it's very hard to maintain an effective blacklist (IPs are not so much identity as an accessory) and the security of a second secret is marginal (especially vs. just including those bits in your original secret).

Link to comment
Share on other sites

I had a similar worry and started another thread because I didn't find this one.

My suggestion would be instead of just the secret which is the address, have another key which is the authentication token.

I am not sure if it would work with the technology and how you have central authentication on a distributed service, but something like a a second key would dramatically increase the security, it is the basis for most security on the web, your email or username is the identifier like the secret is in this case, and the password is the authentication token.

Again, I don't know how it would work in practice, but ideally it would be good to limit the users who can access a file. So in the extremely unlikely case that they stumble across the secret, they would still not have access and would then have to try brute force the authentication token to gain access.

Would a designated list of rsa public keys work? The original host whitelists an rsa key, and it automatically propagates to the peers?

Sorry if I am suggesting stupid things, I have only a vague idea of how this all works.

Cheers

Link to comment
Share on other sites

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

Link to comment
Share on other sites

well if you have a system that you follow for creating keys, you can always do it again without needing to copy it from another location....

like me i always use the name of the folder as the base of all hashes that i get my keys from, but if someone else has the same system they could easily generate the same key from knowing the folder's name.

so its better to just generate a very long key

on an unrelated topic, i hope there could be an option to use username and password to store all keys associated with an account, and possibility to just login and choose what keys to sync or not.

Link to comment
Share on other sites

Asymmetric key lengths must be longer to match symmetric key security. See for example Table 2 in http://www.rsa.com/rsalabs/node.asp?id=2088 , and read the whole thing for a better understanding.

32 characters in base 32 = 32^32 = 2^160

That’s a potential key length of 160 bits, more than enough for AES-128.

The recommended minimum RSA public_key length is going up from 1024 to 2048 after 31st December 2013[1]. Also RSA is an asymmetric system. Yours is symmetric afaik.

This indicates that your 32 char length is not secure in any way.[2]

[1]See here: http://news.netcraft...s-or-rules.html

[2]More to read: http://en.wikipedia....thm_key_lengths

Link to comment
Share on other sites

Moin,

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.

--

Henryk Plötz

Grüße aus Berlin

Could you clarify how this represents '...a perfect example of an implemented attack.'?

Link to comment
Share on other sites

Definitely, lock and unlock works for me with folder UUIDs-- if you get in when it is unlocked, then the "owner" can see and accept your entrance, then store your UUID to allow you to connect again at any time in the future when the setup is otherwise locked from new users.

And sure, a very long key, much longer than the default 32x base32 chars .... there is only ONE base32 character set, it includes A-Z and 2-7 only -- so, no zeros or ones to confuse with the letters O and I.

Certainly use base64 and very long keys and your chance of a random clash is virtually impossible, but a lock/unlock mechanism will make it absolutely impossible when the "owner" watching each new connection during a period of the system being unlocked.

Alternative base32 sets are not base32 exactly, see this link:

https://en.wikipedia...Base32_alphabet

I think unless it is otherwise stated, then the RFC standard should be used, which is very clear as to which characters are used.

Any use of Base32 or Base64 will allow for very long passwords and use of entire bit space, the 21 character full bit space translates to 32 characters of Base32 ... so you are not losing bits if you lengthen the secret appropriately.

Link to comment
Share on other sites

Definitely, lock and unlock works for me with folder UUIDs-- if you get in when it is unlocked, then the "owner" can see and accept your entrance, then store your UUID to allow you to connect again at any time in the future when the setup is otherwise locked from new users.

nice idea. another layer of security.

Link to comment
Share on other sites

How is the encryption key derived from the secret? Are you using an appropriate key derivation function like pbkdf2, bcrypt, or scrypt, or are you (mis)using a common cryptographic hash? If you are using a password hash, which one, and how many iterations?

More generally, is your encryption code documented somewhere?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.