We have that in Australia now with what used to be 6 months in prison (now years) for not surrendering them. Usually the media focus is on “password” but that in effect is your key anyhow. But the law from what I can gather includes providing the way to decrypt the data which would include the keys.
Yes, it’s inevitable.
Thinking further, would a Russian doll mode work i.e the software is always listening (no prompts) for a keyboard combination, voice command etc…that would load another version of a users profile. You could set up unlimited invisible profiles under 1 account.
2 Likes
Damn, Australia seems to be worse than in America.
What happens if you genuinely want to give it to them but can’t remember the password?
3 Likes
That is up to a Judge to decide, which is why we have judges so law enforcement cannot just jail you forever.
Maybe not that but having multiple accounts will certainly help. You can have a full account with all and a restricted account with only keys/data you’re will to give up.
So then you can satisfy the law even if you have not satisfied the investigators. If they don’t know about it then how can they demand it, they may ask if thats all but cannot demand what they don’t know they don’t know about.
2 Likes
That’s the obvious ploy and one that will be used for both good and evil…but I still think one’s public account should have no breadcrumbs by default and have the facility for hidden layers.
1 Like
That requires a password or some system to access it and if the investigators know the system they can ask you for that information. At this time I think separate accounts with some shared keys/data is better. Maybe someone can think up a better way
1 Like
Plausible deniability would work even better if under the same username you could generate/access a different account just by having a different password and pin.
But on the SafeNetwork profilename is registered to only one of them, if your profilename is publicly known (let’s say you are a prolific blogger) then they will know it is not your account.
I think the following is not possible under the current design, but it would be neat if you could create sub-accounts generated by different pass/pin combos.
So even though it shows logged in under your proper username and profilename, it doesn’t show everything since the sub-account has been set up to be restricted to certain areas.
It would be impossible to prove if the account that he has logged in is the “master account” or a “sub-account”.
But this is just security porn, I think that for 99% of the cases will suffice having different accounts.
5 Likes
This is what I was saying with the 2 accounts above. The one you reveal has a subset of data/keys of the master one.
The credentials do not relate to any of the data/keys inside unless you do that yourself.
I would say that someone will create an APP that allows easy ability to copy keys/data-maps from one account to another.
6 Likes
I totally agree with this and I have argued many times that account location should be based on username + password instead of on only on element (secret). Last time was here.
Your remark about plausible deniability is an additional argument for this.
10 Likes
I agree with you both and suggest we have a lot of approaches that can be take here. Nice thing is they are simple.
I cleared up something recently in house.
Account → The login thing can be considered a container of keypairs. (plus a wee bit more for getting your files etc.)
Identity → The public key on the network that has a Balance of coins associated
So the login thing gets the account which is now called LoginPacket on the network IIRC.
So the public key is used as an identity to connect (signed by the secret key message )
These keypairs can be in hardware wallets or whatever.
This does not change your convo @tfa but just to bring you up to speed a wee bit on this clarification. Accounts can have as many keypairs as they wish).
Another trick we do is from the passwords (this is the part that may change, the 2 password thing) we derive a keypair as we have to sign the message to retrieve the login packet with that derived key. Just to prevent range based attacks on the login packets. Elders holding the packets obviously can see them etc. This is just an addition to prevent mass downloads of them.
So plausible deniability can be delete the Identity (keypair) you used, but not necessarily the login packet, if that makes sense?
12 Likes
As David mentions, the SafeIDs / Profiles you see in these mockups are not “accounts”, they are identities assumed by a User, depending on the context and the User’s requirements. A user can have as many of these SafeIDs as they want. They could directly identify them (if they chose to do that), or they could be re-usable pseudonyms, one-time only pseudonyms, or the default—no identify at all: anonymous.
So, there is one unique human per account, but as many different identities can be assumed and used from that account as the User requires. But the crucial thing here, is that there is no publicly availible connection between a SafeID and the account that owns it.
I’d not favour this approach—if what you are calling a username is a publicly known thing—as it would allow individual accounts to be specifically targeted for brute-force or password list attacks. No part of a an account’s login credentials should be publicly known or shared, they must only be known by the account holder in my view.
5 Likes
What mode of attack are we talking about here? Because if we are talking ‘rubber hose’ all of this plausible deniability stuff goes out of the window.
But if we are just talking a milder form of pressure, how is just denying you have a Safe account any different than offering to log-in under a sub account that is empty? And given that any attacker will know about the facility to have sub accounts, or might assume you created multiple accounts, they will just keep pressure on until they get the information they want… or you get prosecuted for “failing to reveal a sub account” etc.
4 Likes
Not a lawyer here, but regardless 
… I think it’s tricky to prosecute on the basis there may be something that has not been revealed. That’s very different from knowing an account exists and demanding access.
If it can’t be proven that something has not been disclosed, well, you can just lock people up at will and if we’ve reached that point the law is irrelevant.
I think it boils down to whether they can convince a jury you’ve not given something up, versus you convincing the jury that you have revealed everything.
5 Likes
I think this gets a lot harder if your credentials involve something publicly known, like your username or email address, as I mentioned above.
5 Likes
Just generate account location from both username + password so that you can’t get account packet in the first place.
So, my question is: why don’t you generate the account location from the 2 elements of the credentials?
If you do this then we can argue if the first element can be a username (or friendly name, pet name, …). But by deriving the account location from only one element you prevent any debate because, of course, in this condition this element must be secret.
1 Like
It would be at least from the two things, hashed in reverse, double hashed etc. This part of the debate is good and does need hashed out (sorry for the pun (edit cheers @draw ) ). But if folk pick say a bad password and we can grab all email addresses (say) and create rainbow lists of these hashed with all known bad passwords then it is easier to crack than perhaps 2 bad passwords?
6 Likes
I assume this a typo. I don’t mind a pub, even if that causes my speaking becoming ‘hashed’. 
3 Likes
2 passwords are very unusual (personally I have never seen that before) and in doubt, just strengthen the password.
One password was only insecure in your case because you generated account location from one element only (past tense because now I have good hope that you will generate it from both elements).
But it’s still insecure if the other element is publicly known, and worse still, it allows an attacker to target me specifically.
In my mind I was imagining that both accounts would have access to the same “unclassified” information, with the difference that the sub-accounts has certain sections inaccessible. And from the perspective of a sub-accounts there is no indication that there is any more out there.
So if I login with:
User: piluso
Pass: myfirstpassword
Pin: 1234
I get access to:
ProfileIDs: pilu | coco | Deepthroat
Files:
/public
/private
└secret/realstuff
And if I login with:
User: piluso
Pass: Mysecondpassword
Pin: 5678
Which gives access to:
ProfileIDs: pilu | coco
Files:
/public
/private
└secret/bogus
Access and permission level to /public would be identical in both, where you can edit the contents from both accounts.
Under such scheme if you properly compartmentalize your contents, there would be no way of knowing if you are accessing your master or your sub-accounts, as the username is the same for both, and the public information is shown in both.
There would no way of checking if you have set up a sub-accounts or not, as it would be identical if you had one or more.
Edit: added profiles, just to illustrate it a bit more
1 Like