benguild Posted May 9, 2014 Report Share Posted May 9, 2014 If the secret length can't be changed, I think that having a "password" (of a variable length) for the secret would be great. Essentially all peers have to verify this password with each other directly for a given secret in order to actually communicate over a given secret. I realize that finding a way to verify passwords peer-to-peer that can't be easily spoofed/monitored/cracked might be a challenge given that there's no central authority, but a feature like this would definitely ease the wary minds of those concerned about the extreme chances of probability. This way, it's ideal since even if someone finds your secret they're most likely not going to find a matching passcode. ... Even BETTER would be a way to store, generate securely (based on the original passcode) a secure password "key" that is unique for a particular node... so that the original passcode is never actually stored or given to that node in plain text. Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted May 9, 2014 Report Share Posted May 9, 2014 If the secret length can't be changed...The secret length CAN be changed! See this thread. Also, there are already a wealth of other topics dealing with the exact same issue regarding security of secrets - some examples: (1 | 2 | 3 | 4 | 5 | 6 | 7) Quote Link to comment Share on other sites More sharing options...
benguild Posted May 10, 2014 Author Report Share Posted May 10, 2014 The secret length CAN be changed! See this thread. Also, there are already a wealth of other topics dealing with the exact same issue regarding security of secrets - some examples: (1 | 2 | 3 | 4 | 5 | 6 | 7) Understood, but not for the new types of nodes. As I understand, the older key styles are only supported for legacy reasons. Quote Link to comment Share on other sites More sharing options...
benguild Posted May 13, 2014 Author Report Share Posted May 13, 2014 I like the idea of having a "two-factor" authentication system. Aside from having matching secrets, it'd be nice if the nodes could have a pre-shared key that also has to match or they won't talk to each other. The idea here is that outdated notes could be excluded from the secret without having to change the secret, and it also provides and additional level of security where the user can create an much longer secret key of mixed character sets. I think this would be a great advanced/hidden option for added security given that it would be basically impossible for someone to guess a secondary key, but it makes use of the existing 33 character secret system. Quote Link to comment Share on other sites More sharing options...
ChrisH Posted May 14, 2014 Report Share Posted May 14, 2014 What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits. And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it? Quote Link to comment Share on other sites More sharing options...
GreatMarko Posted May 14, 2014 Report Share Posted May 14, 2014 What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits. And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it? Totally agree! I think it's basically about the perception (or rather misconception!) that people "feel" more secure if they are asked to provide two pieces of information instead of one! Quote Link to comment Share on other sites More sharing options...
benguild Posted May 24, 2014 Author Report Share Posted May 24, 2014 Totally agree! I think it's basically about the perception (or rather misconception!) that people "feel" more secure if they are asked to provide two pieces of information instead of one! Right—However if the second key is of a variable length vs. the first being of a fixed length for simplicity and branding's sake... then that's different. Another way to treat this might be to treat the secondary key as a data encryption key ... where perhaps without it someone can connect to your "stream" just by having your secret, but won't be able to actually decode anything otherwise. Quote Link to comment Share on other sites More sharing options...
NightOne Posted May 24, 2014 Report Share Posted May 24, 2014 I like this idea as well, I have been using Sync for a while and love the simpliciy of it... just wish I had more control over who I send the keys to as I have noticed some friends reply and CC other people into the email with the sync key. I installed syncthings this weekend to have a look at the diffrence. syncthings has the idea of nodes and repositories... so you set up trusted nodes with two keys.... meaning you set up one node and send your friend a key, he/she has to set up the node on there side with your public key and then send you a public key of their own... so its a two way trusted node.... then when you want to sync a repository with them you simply check a box to "sync" with their node. I for one like BTSync more as it just is a slicker and nicer interface and easier to set up... but I would love to see a better implementation of the key trust. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.