more than one public key per recipient

[tomholub]

(I'm filing a separate issue to discuss from #480 )

Right now, we import one public key per recipient email. So for recipient@domain.com I can only have one public key. Would it be possible to allow more than one public key per each recipient email? Then we can import any keys, but have to change logic on how to choose the right key when we send out encrypted message, for example.

[DenBond7]

So for recipient@domain.com I can only have one public key.

That's true for now

Would it be possible to allow more than one public key per each recipient email?

I think yes. For example, we can store a few pub keys as a single source in the database record. In that case, a user will have a list of pub keys(in most cases with a single pub key) instead of a single key.

Then we can import any keys, but have to change logic on how to choose the right key when we send out encrypted message, for example.

It's possible. For now, we just create a data class that contains only recipient emails. But we also can store for example email<->fingerprint pair. After that during the creation raw MIME message, we can choose the right key. Of course, we should create UI for that.

Anyway, it's possible.

[tomholub]

After that during the creation raw MIME message, we can choose the right key. Of course, we should create UI for that.

This would be automatic - we'd have rules about how to choose the right one. No user interaction.

I think yes. For example, we can store a few pub keys as a single source in the database record. In that case, a user will have a list of pub keys(in most cases with a single pub key) instead of a single key.

Would this end up being three db rows with three public keys, or one row with several public keys in it?

[DenBond7]

Would this end up being three db rows with three public keys, or one row with several public keys in it?

only one row as before. Just public_key column will contain a list of keys. Also, we can add a new column, for example, default_key, and store a fingerprint of the default key.

[tomholub]

Would it alternatively be possible to do a migration and be able to store more than one row per recipient, with one key per row? It's more work but it would be the most flexible.

[DenBond7]

Would it alternatively be possible to do a migration and be able to store more than one row per recipient, with one key per row?

yes, we can do that. I don't see any problems with that.

[IvanPizhenko]

why not store additional keys in the additional table? one record per key, referencing recipient as foreign key?

[tomholub]

That's roughly what we do on browser extension - a list of recipients in one table with references to public keys, and a public key table next to it.

[DenBond7]

why not store additional keys in the additional table? one record per key, referencing recipient as foreign key?

That's roughly what we do on browser extension - a list of recipients in one table with references to public keys, and a public key table next to it.

@tomholub I'd like to clarify the relationships between contacts and pub_keys tables. Will it be one-to-many or many-to-many?

Is there a situation when we can have a single pub key for two different email addresses? (a pub key that contains a few user ids). What we are going to support?

I'm going to add the following

@Entity(
  tableName = "pub_keys",
  indices = [
    Index(
      name = "email_fingerprint_in_pub_keys",
      value = ["email", "fingerprint"],
      unique = true
    )
  ],
  foreignKeys = [
    ForeignKey(
      entity = ContactEntity::class,
      parentColumns = ["email"],
      childColumns = ["email"],
      onDelete = ForeignKey.CASCADE
    )
  ]
)
class PubKeysEntity(
  @PrimaryKey(autoGenerate = true) @ColumnInfo(name = BaseColumns._ID) val id: Long? = null,
  val email: String,
  @ColumnInfo(name = "fingerprint") val fingerprint: String,
  @ColumnInfo(name = "public_key") val publicKey: ByteArray
)

[DenBond7]

• Discuss all actions with recipients and pub keys
• Add a testable version
• Add migration
• add tests
• test that deleting a contact also deletes dependent keys

[tomholub]

On other platforms (browser and iOS) we have renamed Contact to RecipientWithPubKeys as follows:

struct RecipientWithPubKeys {
    let email: String
    /// name if known
    let name: String?
    /// last time an email was sent to this contact, update when email is sent
    let lastUsed: Date?
    /// public keys
    var pubKeys: [PubKey]
}

So instead of Contact that has one pubkey in it, it's a recipient which has an array of keys in it. I recommend to do it the same, it works well. Then when pulling keys from database, most of the time, you will pull the RecipientWithPubKeys as a whole.

When ordering the public keys that come from the database, please use this logic: FlowCrypt/flowcrypt-ios#714 it will save us trouble later.

After that, when deciding color of the recipient now that several keys are involved, use this logic (after sorting methodically, use the first key for the color) - FlowCrypt/flowcrypt-ios#712

@tomholub I'd like to clarify the relationships between contacts and pub_keys tables. Will it be one-to-many or many-to-many?
Is there a situation when we can have a single pub key for two different email addresses? (a pub key that contains a few user ids). What we are going to support?

To give you some examples:

Tom may have a key for Tom + Human + Security
Human may have a key for Human
Mart may have a key for Mart + Security

So you can definitely have a situation where Tom has more than one key (expected) but also where one key is shared by Tom and Human or Tom and Mart (I think this answers your question).

In this situation, it would be best to de-duplicate keys by their fingerprints. So that you don't have to store the shared key twice, and when you update it on one end, then it updates on both.

I suppose that makes it many-to-many?

[DenBond7]

Thank you for the clarification 👍

Tom may have a key for Tom + Human + Security
Human may have a key for Human
Mart may have a key for Mart + Security

So you can definitely have a situation where Tom has more than one key (expected) but also where one key is shared by Tom and Human or Tom and Mart (I think this answers your question).

Some moments are worrying me. Let me explain.
As for me specifiyng a pub key for a particular user will be more flexible. I mean it would be better to have a separate copy of a key for each recipient.
I see the following

1. For example on a server we have a pub key with the following userIds: tom@flowcrypt.test, human@flowcrypt.test and security@flowcrypt.test. One key that relates to three recipients.
2. A user opens a compose screen and types 'tom@flowcrypt.test'. we fetch a pub key from the server and save it to the local database. We will have a row with a unique recipient email and the key fingerprint. Based on that data we will be able to fetch all available keys for a particular user (including deleting or modifying)
3. If a user deletes some recipient, keys that relates to that recipient will be deleted automatically. (Cascade deleting).
4. This logic will help us keep recipients independent of each other. It's very similar to what we have with account private keys. We had to migrate to that logic to be more flexible and clear.
5. In that case we will have one-to-many case. It's simpler.