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

[DenBond7]

Encryption and signing. NEW messages

Imagine that I have the following records in the local database

1| FINGERPRINT| sender@flowcrypt.test | KEY
2| FINGERPRINT| recipient@flowcrypt.test | KEY1
3| FINGERPRINT| recipient@flowcrypt.test | 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)

[tomholub]

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]

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 :)

[tomholub]

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]

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

[tomholub]

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.