test/fix how the Android app handles revoked keys from EKM

[tomholub]

like FlowCrypt/flowcrypt-ios#1491

There will likely be a fix needed. On browser extension, the fix was mostly this:

 private static chooseSigningKey = async (
 view: ComposeView,
 senderKis: KeyInfoWithIdentity[]
 ): Promise<ParsedKeyInfo | undefined> => {
 const parsedSenderPrvs = await KeyStoreUtil.parse(senderKis);
 // to consider - currently we choose first valid key for signing. Should we sign with all?
 // alternatively we could use most recenlty modified valid key
 return parsedSenderPrvs.find(k => k.key.usableForSigning);
 };

Until then, it was using a key for signing that may not be usable (eg revoked).

On Android, we choose signing key based on email. We have to therefore additionally filter keys by their ability to sign messages.

Larger context of the PR FlowCrypt/flowcrypt-browser@cd824fc

[DenBond7]

@tomholub Could you clarify the main point of this issue? As I understand it relates to the message compose screen.

For now, if a user has a revoked private key we allow him to complete the message creation but don't allow him to send it. In detail, we can't create an encrypted message with such a key. We show the following error:

However, we can check available private keys on the message compose screen and notify a user about revoked keys.

What I see

1. On the message compose screen we have to check if a user has at least one private key that is available for encryption and signing purposes
2. If not, we have to show a hint

What do you think?

[DenBond7]

Also, it seems we allow to import revoked keys during the setup process. Is it normal?

[tomholub]

Also, it seems we allow to import revoked keys during the setup process. Is it normal?

importing during setup is correct

For now, if a user has a revoked private key we allow him to complete the message creation but don't allow him to send it. In detail, we can't create an encrypted message with such a key. We show the following error:

But what if the other key is valid - does it still fail?

The point of the issue is that we should not show any error there if there are other valid keys that could be used instead (for signing).

[DenBond7]

Thank you for the fast reply

The point of the issue is that we should not show any error there if there are other valid keys that could be used instead (for signing).

Got it. What should I do if we have a single key that is revoked?

[tomholub]

If we don't have any valid keys available, then do what you are doing - show an error.

But if we have at least one valid key that could be used for signing, then that key should be used without error.

[DenBond7]

@tomholub Maybe it doesn't relate to the current issue, but I'd like to clarify

The point of the issue is that we should not show any error there if there are other valid keys that could be used instead (for signing).

When we create an encrypted and signed message we should use the following rules:

1. for encryption, we use ALL suitable user's public keys
2. for signing, we use THE FIRST suitable and not revoked private key

For example, I have two keys: first.asc and second_revoked.asc. Then we will have the following

1. for encryption: first_pub.asc + second_revoked_pub.asc + recipients pub keys
2. for signing: first.asc

Please correct me if I'm wrong.

[tomholub]

it does relate to this issue as well

When we create an encrypted and signed message we should use the following rules:

1. for encryption, we use **ALL** suitable user's public keys

2. for signing, we use **THE FIRST** suitable and not revoked private key

yes

For example, I have two keys: first.asc and second_revoked.asc. Then we will have the following

1. for encryption: `first_pub.asc` + `second_revoked_pub.asc` + `recipients pub keys`

no. second_revoked_pub.asc is not suitable, because it is revoked.

So it would be: my first pub + recipient pubs

Let's say you only have revoked key for your self, and recipient keys. Then it would be error.

2. for signing: `first.asc`

Please correct me if I'm wrong.

This is correct.