Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A few pub keys for a recipient. Encryption and signing. #1541

Closed
DenBond7 opened this issue Nov 8, 2021 · 5 comments · Fixed by #1523
Closed

A few pub keys for a recipient. Encryption and signing. #1541

DenBond7 opened this issue Nov 8, 2021 · 5 comments · Fixed by #1523
Assignees

Comments

@DenBond7
Copy link
Collaborator

DenBond7 commented Nov 8, 2021

Encryption and signing. NEW messages

Imagine that I have the following records in the local database

1| FINGERPRINT| [email protected] | KEY
2| FINGERPRINT| [email protected] | KEY1
3| FINGERPRINT| [email protected] | KEY2

I'm a sender. I'd like to encrypt and sign a message for a recipient. What combination of keys should I use?

  1. KEY + KEY1
  2. KEY + KEY2
  3. KEY + KEY1 + KEY2

Originally posted by @DenBond7 in #1188 (comment)

@DenBond7 DenBond7 self-assigned this Nov 8, 2021
@tomholub
Copy link
Collaborator

tomholub commented Nov 8, 2021

For encryption, use all of them, but:

  • filter only valid keys of recipient per A few pub keys for a recipient. Creating an encrypted message #1540
  • reuse our existing mechanism to choose sender's key based on sender email, but instead of choosing one, make it a filter. That means, any of my keys that contain the sender email address in any of their uids will get included. Also, if there isn't any valid key, show a modal about my own keys as before

For signing:

  • keep logic as before: sign with one chosen key as per the existing logic (we've already had several private keys before this milestone, so no change here)

@DenBond7
Copy link
Collaborator Author

For encryption

filter only valid keys of recipient per

Not revoked and not expired? right?

That means, any of my keys that contain the sender email address in any of their uids will get included

Before we just used the first from the matching list. So there no too many changes. That's great :)

DenBond7 added a commit that referenced this issue Nov 10, 2021
@tomholub
Copy link
Collaborator

filter only valid keys of recipient per

Not revoked and not expired? right?

And being generally usable for encryption - having primary uid, appropriate signatures and so on - overall a valid key (there should be PGPainless method to validate. Originally it was something like .usableForEncryption

@DenBond7
Copy link
Collaborator Author

Got it. I will check this info. Before we didn't do that.

@tomholub
Copy link
Collaborator

tomholub commented Nov 10, 2021

If we didn't do that before, and didn't run into big issues, then maybe can skip it for now as well. Can file an issue for later.

DenBond7 added a commit that referenced this issue Nov 10, 2021
@DenBond7 DenBond7 changed the title A few pub keys for a recipient. Encryption and signing. NEW messages A few pub keys for a recipient. Encryption and signing. Nov 10, 2021
tomholub pushed a commit that referenced this issue Nov 25, 2021
… keys per recipient (#1523)

* Added PublicKeyEntity. Refactored code. WIP.| #1188

* Fixed using ContactsDao.getAllContactsWithPgpLD().| #1188

* Fixed using ContactsDao.getAllContactsWithPgp()/getAllContactsWithPgpWhichMatched().| #1188

* Renamed ContactEntity to RecipientEntity.| #1188

* Renamed ContactsDao to RecipientDao.| #1188

* Refactored code.| #1188

* Renamed ContactsViewModel to RecipientsViewModel.| #1188

* Fixed a few methods in RecipientDao. Refactored code.| #1188

* Fixed RecipientDao.getRecipientByEmail().| #1188

* Fixed some moments with adding/updating a recipient with a pub key.| #1188

* Made a workable version after switching to use 'recipients' and 'pub_keys' tables.| #1188

* Fixed tests. Refactored code.| #1188

* Modified code to use a new logic to save contacts on the compose screen.| #1539

* Modified code to use a new logic to apply colors to recipients(chips).| #1540

* Added changes to use all recipient's pub keys for ecnryption + use all sender's mathing pub keys.| #1541

* Fixed signing option.| #1541

* Import recipients manually. Refactored code. Added LookUpPubKeysDialogFragment and ImportRecipientsFromSourceFragment..| #1542

* Added a base realization of importing pub keys manually.| #1542

* Added ImportAllPubKeysFromSourceDialogFragment.| #1542

* Removed unused source.| #1542

* Improved some classes.| #1566

* Added RecipientDetailsFragment.| #1566

* Fixed opening PublicKeyDetailsFragment. Refactored code.| #1566

* Fixed exporting pub key.| #1566

* Fixed deleting pub key.| #1566

* Fixed editing pub key.| #1566

* Fixed database migration bug.| #1188

* Fixed nav_graph.xml for test.| #1188

* Temporary disabled some tests.| #1188

* Temporary disabled some tests(step 2).| #1188

* Fixed Junit tests.| #1188

* Fixed some UI tests.| #1188

* Fixed merge conflicts.| #1188

* Fixed some PR comments. Refactored code.| #1188

* Fixed some PR comments. Refactored code. Step 2.| #1188

* Restored some code.| #1188

* Renamed a file.| #1188

* Fixed importing/updating pub keys for PublicKeyMsgBlock.| #1188
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants