encrypt for all of recipient's keys when sending a message

[seisvelas]

Currently, if I have the wrong key for someone, they can send me their key, and the extension will offer to update the contact to the new key.

But really what will happen is we'll now have both keys for that contact. So when I write them another email, this time hoping to use their correct key - nope, it will still use the same key as before.

So here are my questions:

1. How does the extension currently decide which key to use?
2. Can't we just use the most recently added key by default?
3. If not, perhaps when a recipient has multiple keys on file, we could offer a selection for the sender to choose, instead of just assuming?

[tomholub]

How does the extension currently decide which key to use?

Good question, this should be reviewed. I suspect we arbitrarily choose the first key that matches the criteria described below.

Can't we just use the most recently added key by default?

There should be other criteria first, like the key has to be valid, not expired, not revoked etc. After that, if there is still more than one key, we could think about what to do.

If not, perhaps when a recipient has multiple keys on file, we could offer a selection for the sender to choose, instead of just assuming?

I would prefer to generally not bother the user, this should be last resort if we cannot come up with a more clever mechanism.

[tomholub]

Btw the user could delete the key they don't like in contacts, which would fix the issue they are experiencing.

[seisvelas]

Btw the user could delete the key they don't like in contacts, which would fix the issue they are experiencing.

This is also what I came up with to solve the users issue (the problem originated in a support email), good to know this was the correct thing to suggest :)

There should be other criteria first, like the key has to be valid, not expired, not revoked etc. After that, if there is still more than one key, we could think about what to do.

That makes sense. Here is the current code:

flowcrypt-browser/extension/js/common/platform/store/contact-store.ts

Lines 608 to 623 in 6e6b847

	private static dbContactInternalGetOne = async (db: IDBDatabase, emailOrLongid: string): Promise<Contact | undefined> => {
	if (emailOrLongid.includes('@')) { // email
	const contactWithAllPubkeys = await ContactStore.getOneWithAllPubkeys(db, emailOrLongid);
	if (!contactWithAllPubkeys) {
	return contactWithAllPubkeys;
	}
	// pick first usableForEncryption
	let selected = contactWithAllPubkeys.sortedPubkeys.find(entry => !entry.revoked && entry.pubkey.usableForEncryption);
	if (!selected) {
	selected = contactWithAllPubkeys.sortedPubkeys.find(entry => !entry.revoked && entry.pubkey.usableForEncryptionButExpired);
	}
	if (!selected) {
	selected = contactWithAllPubkeys.sortedPubkeys[0];
	}
	return ContactStore.toContactFromKey(contactWithAllPubkeys.info, selected?.pubkey, selected?.lastCheck, Boolean(selected?.revoked));
	}

So we already handle expiration, revocation, etc, and even sorting, but instead of sorting by recency, we sort by this method:

flowcrypt-browser/extension/js/common/platform/store/contact-store.ts

Lines 391 to 406 in 6e6b847

	private static sortKeys = async (pubkeys: Pubkey[], revocations: Revocation[]) => {
	// parse the keys
	const parsed = await Promise.all(pubkeys.map(async (pubkey) => {
	const pk = await KeyUtil.parse(pubkey.armoredKey);
	const revoked = pk.revoked || revocations.some(r => ContactStore.equalFingerprints(pk.id, r.fingerprint));
	const expirationSortValue = (typeof pk.expiration === 'undefined') ? Infinity : pk.expiration!;
	return {
	lastCheck: pubkey.lastCheck,
	pubkey: pk,
	revoked,
	// sort non-revoked first, then non-expired
	sortValue: revoked ? -Infinity : expirationSortValue
	};
	}));
	return parsed.sort((a, b) => b.sortValue - a.sortValue);
	}

So it looks like, we could just add recency as a sort factor in the above method (to be considered after revocation and expiration), and this would work the way I propose.

[tomholub]

I'm setting this to first priority to discuss it but it's not actionable until we arrive at some conclusion on how to handle it.

I recognize the behavior is broken: if someone receives an encrypted message that doesn't match, then the extension prompts them to send back public key. The original sender then is prompted to click import key. Which used to fix the problem (a newly sent message would get encrypted for this key, since there can be only one per recipient) but now it no longer fixes this issue, and therefore results in broken UX.

I'm thinking, instead of choosing a key to encrypt for (from a list of keys of a particular recipient), encrypt for all public keys associated with that recipient that are valid for encryption right now. Assuming a fussy recipient that has different keys on mobile then desktop or whatever, it would always work no matter what the user does.

@rrrooommmaaa does that approach sound ok?

[rrrooommmaaa]

instead of choosing a key to encrypt for (from a list of keys of a particular recipient), encrypt for all public keys associated with that recipient that are valid for encryption right now.

Yes, as the message (or a one-off symmetric key, to be exact) can be encrypted with multiple keys, the recipient has to have any one of the matching private keys to decrypt it, this approach seems viable and robust.