Currently, we use ChaCha20-Poly1305 for the DEM and elliptic curve cryptography (secp256k1 by default) for the KEM.
- Alice generates a ‘for publication to company’ label with associated public/private key.
- Alice issues policies for N-1 people allowing them to access documents encrypted under the ‘for publication to company’.
- Alice encrypts the company handbook under the ‘for publication to company’ public key.
- When other staff access the document the capsule associated with the company handbook would need to be regenerated as required.
For your HR scenario, the steps are correct. However, for step #4 in our terminology, we would say that each member of the staff would need to get the capsule re-encrypted (NOT 'regenerated’) for them.
Would this place an administrative burden on Alice’s (and other staff members) in managing the various keys and polices as people leave/join the company, particularly if N is large?
When someone joins, Alice would simply need to issue a policy for that particular person - all other previously existing policies remain valid. When some leaves, Alice would just delete the policy for that particular person - and again all other previously existing policies remain valid.
Alice is simply managing the issuance and revocation of policies. This is how you ensure that data owners maintain ultimate control over their data.
Of course, infrastructure can be built so that profiles of staff members, that include their public keys could be provided so that Alice can easily grant access to them. That would, however, be a layer built on top of the NuCypher Network.
Suppose Bob joins the company - does everybody need to create policies to add Bob, or is there some central mechanism for this to automatically add a policy for Bob to access Alice’s ‘for publication to company’ documents (which sounds very much like a master key and so I would be doubtful about this).
Only the data owner who wants to share data would need to issue a policy for Bob, everyone else who is a consumer of the data would have to do nothing extra.
The usual approach would be to introduce ‘group’ public/private keys, in this case a ‘company group’
That can be done, but in that case, each staff member would require access to the ‘group’ private key which is not ideal. Even worse, if a staff member leaves the company and has knowledge of the private key, you could have a data breach on your hands. To prevent that, you would then have to revoke access to the old group key and re-issue a new policy to a new group key, and then share that group key with the remaining staff members. This is essentially the shortcoming of plain old public-key cryptography.
The idea being that the membership of the ‘company group’ could be centrally managed via policies by single person (HR I guess in this case) making Alice’s and everybody else’s life easier.
As mentioned above, I think that tooling and infrastructure can be built on top of the NuCypher Network to make the administration part easier for individuals - our philosophy has always been to have the data owner dictate who can/can’t access their data. Group policy/key type practices can definitely be incorporated into our workflow, but you should consider what level of security is desired for the use case.