Feels like we have come full circle! 
1 Like
I think it’s a great analogy. The mnemonic encodes a certain strength within it (32 bits of entropy per word). Likewise the passphrase+password is acting as an entropy source, and the weaker it is the easier it is to break.
When authenticator was in use the passphrase/password strength was checked with zxcvbn. But now, no, there’s no check. We are basically using brainwallets for all account auth, which I’m not such a fan of (but 2FA/MFA could help improve). The cli has a --config flag when logging in which specifies a file for passphrase/password, and I’ll be using that to locally store very secure values (in the near future there will be a PR that will ensure this file is encrypted, like how bitcoin wallets are).
It’s also worth noting that not all private data stored on the network is currently encrypted, for example the account permissions map is not encrypted, but will be in the future:
https://github.com/maidsafe/sn_api/blob/master/sn_api/src/api/authenticator/mod.rs#L206
Likewise, private sequence data is not encrypted with the client keypair (but may be in the future, it’s a little complex because if permissions change then does it affect the encrypted data too?). I’m sure many other data types are not currently encrypted in the way we expect in the final network (it’s no problem for testnets). So for now I have assumed in my mind that all data on any testnet is stored unencrypted and I think it wise for everyone else to do the same. Don’t ever use real secrets with testnets!
The client keypair is used to pay for puts (but not anywhere for encrypting or decrypting the put data itself). And it’s used to sign the get request to the first hop elders, but not for encrypting or decrypting any data for the get request. I just want to make sure the current usage of the client keypair is clear with respect to encryption vs signing. The client keypair is not currently used at all for encrypting. It’s only used for signing. I expect this will change in the future.
Also keep in mind self_encryption is used for blobs (self_encryption does not rely on any keypair so there’s no chance of using the client keypair for security inside self_encryption, only outside it).
The easiest way to think of the current use of the client keypair is for proving ownership (signatures), not for privacy (no encryption). I expect this will change in the future though.
4 Likes
Yes, we will create a x25519 key from a source, probably the hash of the ed25519 secret key. There is a way to convert ed->x (in fact Signal does this) but it can be dangerous. So best to not use the same key for sign and encrypt.
When we get there I imagine it will be encrypted with an x25519 key for individuals and we would use BLS for group encryption.
A question folk have sometimes is permissions, what if permissions change and we remove a person from an encrypted data share. Do we re-encrypt all data ? The answer is no, we assume if you have access to data you will have access forever. So on perms change you would not see any new data (see == be able to read) but you will still have the data you did have access to.
Reason for this is 2 fold, re-encrypt is really a lot of work and secondly it’s probably useless as the person removed probably has copies anyway. We consider worst case, they did copy the data. So removal and re-encrypt is costly and probably deceiving.
10 Likes
So, does this mean that the client key-pair doesn’t need to (necessarily) live on the network? It sounds like there is an option to keep these offline and use them to ‘login’ when you start the client.
Presumably, people would be advised to keep the permission groups small and only give access to trusted parties when needed? I can see this being an area where people will have a harder time adapting, but it obviously makes sense from an immutable/encrypted data perspective.
I suspect there is also a good argument for frequent key rotation (and therefore permissions) with this in mind. This way, new data can be encrypted with new keys. People who did have permission to older data wouldn’t then automatically have access to newer data.
We should also bear in mind that corporations often restrict access of data from company devices. So, someone leaving a company wouldn’t necessarily retain access and/or be able to download and keep data. If client key management is done via external devices, I could imagine corporations not providing a login that could be used directly too (i.e. they won’t know how to derive their client key-pair).
Yes, it can be in a hardware device or piece of paper etc. So plenty of options, use a keyphrase/passphrase (brainwallet like, but needs security of weak passwords handled) or have the keys random generated with a crypto random num generator and store offline.
Yes, I would hope so.
3 Likes
Thanks for confirmations.
Given hardware devices could hold key-pairs, the devices themselves could be used to manage permissions too. So, the device holder could access whatever group(s) the device permits. Maybe the device could even be managed remotely to make this more seamless.
Anyway, I’m just thinking aloud really. Corporations can be obsessive about removing access when no longer needed, but it sounds like there are ways and means to manage this outside of the network too. This opens up a number of options that could work well.
2 Likes
Ok, I’ve done some digging around the source code and I think I’m starting to get a better understanding of this. Excuse my mind dump, but maybe it will help someone else too! 
So, ‘key-pair’ on its own is confusing, as there are 2 main types (as I understand it) - the client key-pair (used to connect the client to the network) and the application key-pairs (used by your apps).
When you login with a passphrase and password, the location and the client key-pair are derived (through various hashing routines).
The client key-pair is used by the client to connect. I haven’t explored far beyond that, but I can see this client key-pair is being passed to the client when it connects to the network. Said client is also used to retrieve a balance, so they client key-pair presumably must be used here.
The location is used for storing/retrieving application key-pairs. These are stored in a permissions map.
When you create a safe, the client derives the client key-pair and location, then connects using the client key-pair, then prepares the permissions map to store your application key-pairs.
When you unlock a safe, the client derives the client key-pair and location, then connects using the client key-pair, then retrieves the permissions map containing your application key-pairs.
–
So, my chatter above about storing the key-pair to retrieve the location is full of holes. Of course your client key-pair and can be kept offline as it isn’t stored on the network. Only your application key-pairs are stored on the network. Likewise, the location of the application key-pairs isn’t stored on the network (that bit is obvious!).
Both the client key-pair and the location can either be derived via passphrase/passwords or by any other means. They can be created/generated externally, stored on an external device or whatever is ideal. However, you need a safe to exist at the location in order to store application key-pairs.
I want to explore how the coins relate to the above, but things seem much clearer in my mind after reading through the code a bit. I hope the above may help others who are grappling with the terminology/explanations without a complete understanding of the code!
7 Likes
This reminds me ISO-27000 Information Security Management System is huge but has some really useful stuff.
1 Like
Something to throw out here for those looking at the code, which I think you’re seeing but perhaps this helps as a clarification. What you’re looking at there (@traktion) re: location/keypair generation is for the authenticator app.
The authenticator could be one of many ways to simplify key management (your app keys eg). Which we’ve also chatted about doing this via tokens for apps eg. But the data for those apps / their keys does not have to live on the network. That’s just one ‘log in from anywhere without a device’ type strategy.
But it is not needed in terms of network access. All you actually need is the ability to sign requests (aka, a keypair); somewhere. Currently at sn_client you have to provide the keys at instantiation. And it manages signing of the various requests. but we already have some code waiting in the wings to basically wrap the sn_client, which would produce messages to be signed however you want (outwith).
But aye, my main point I guess is don’t confuse ‘authenticator’ code with sn_client, the former is an app for key management, the latter is the code needed to sign messages on the network (which in the end is all you really need).
10 Likes
Some info on BLS hardware wallets on the chia subreddit:
https://old.reddit.com/r/chia/comments/p6wvq0/you_know_what_chia_really_needs_support_for/
Not sure what they need from us when our understanding is that Ledger needed to do work on their side to support BLS, which was the biggest hang up. I’ll look into it.
Edit - yeah definitely sounds like there is some communication mix-up internally on the Ledger side, we’ll make a gentle reminder to them that the BLS ball is in their court.
4 Likes
I keep going back to the fact that while Ledgers are nice and ‘crypto’ etc., there are enterprise grade cryptography keys e.g. Yubikey that are already owned by people outside the cryptosystem and which have e.g. Rust libraries (http://13.57.91.247/yubikey/0.4.1/yubikey/). Some sort of industry standard off-the-shelf method of signing and 2fa that doesn’t require writing a ledger app seems like an appropriate first step. And if something like U2F can be made to work in tandem with a password, then ledger will support that too.
Glad to see that SAFE is on it via a generic abstraction of the authenticator.
4 Likes