Support rotating accounts wiht multiple admins #8137
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vaf-hub
force-pushed
the
crypto/dev
branch
2 times, most recently
from
f492bbd to
c6e8e0b
Compare
vitoreiji
force-pushed
the
crypto/dev
branch
from
c6e8e0b to
6725f5d
Compare
vitoreiji
force-pushed
the
crypto/dev
branch
2 times, most recently
from
207d8eb to
5153a24
Compare
1 task
When adding a new admin and an admin key rotation is pending we inform the admin that he must wait the rotation to finish first. tutadb#1905 Co-authored-by: vis <[email protected]>
tutadb#1906 Co-authored-by: vis <[email protected]>
This key serves to authenticate the new admin group key to other admins, and should therefore be accessible by each admin. We have two options for this: the old admin group key, or each admin's existing user group key. The previous implementation derived the authentication key from the admin group key, which is not what was defined in the design of this key rotation process. tutadb#1906
When performing a user group key rotation after another admin already performed the admin group key rotation, each admin must validate the authenticity of the newly received admin group key and then encrypt it with their new user group key. tutadb#1909
…otation, authenticate the key at every usage as admin tutadb#1922
Co-authored-by: bedhub tutadb#1925
Allows creating and verifying tags. This is useful to manually verify authenticity of non-confidential data. tutadb#1937
Co-authored-by: vaf-hub <[email protected]> Co-authored-by: Sara <[email protected]> tutadb#1937
This commits binds the user distribution key to the version of the new user group key being distributed therefore increasing security. For this new distribution key will only be used for decryption and a later commit will use it for both encryption and descryption. Co-authored-by: mab <[email protected]>
extract PublicKeyProvider to enforce constraints in a central place use type system and checkKeyVersionConstraints function to enforce constraints everywhere tutadb#1933
make convertToVersionedPublicKeys part of PublicKeyProvider and private tutadb#1926
… version constraints on key versions, only accept rsa public keys in version 0 fix mimimi after changing Versioned to have versions as u64 instead of i64 tutadb#1926 tutadb#1933
This affects only Key Rotation related derivations, i.e., authentication keys and the distribution encryption key. We do not change the user group distribution key derivation, that is a separate change. This moves all the binding data to the authentication key derivation step. It doesn't really matter if it is there or in the tagged data, as long at it is somewhere, but by using it in the key derivation salt we increase the security of the resulting authentication key. We also bind the entire MAC tag system together. The idea here is to make it easy to find the corresponding tag creation and verification in the code, and also ensure that the parameters passed in are the same. This also makes it easy to see how key authentication works in general. We respect the constraint that no classes or functions may be passed in or out of the facade (due to IPC). tutadb#1940 Co-authored-by: vis <[email protected]> Co-authored-by: hec <[email protected]> Co-authored-by: mab <[email protected]>
These groups have been deleted and are no longer supported. It doesn't make sense talking about "global admins" anymore, so we just refer to them as "admins". tutadb#1919 Co-authored-by: Vitor Sakaguti <[email protected]>
We still use the keys, but we show a warning if we detect that TutaCrypt keys should have been used instead. In practice, this means that if we have TutaCrypt keys at all, the sender should have used those. However, in order to prevent unnecessary warnings when doing a key rotation, we consider it normal to receive RSA encrypted mails in the same session where we did the key rotation. There is a corner case when we show a warning even though the RSA encryption was legitimate, and that is if we decrypt an old RSA mail after rotating to TutaCrypt keys. We don't expect this to occur very often. Co-authored-by: hec <[email protected]> Co-authored-by: mab <[email protected]> tutadb#1932
#tutadb1962
This fixes some linter errors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.