The absence of whitelists creates the absence of security

[elimohl]

I cannot trust any conversation at all even if have а list of all genuine fingerprints for all devices my buddy has. Even if lurch shows me all fingerprints of my buddy and I check that every of them is good, I will only know that things are good in this very moment. If in the next second an attacker come, I will not notice that.

It will be much better to have an option whether to use whitelist or not, and while whitelist option is set, prevent a user from sending any messages without either whitelisting or blacklisting every buddy's fingerprints.

[blahjig]

do you know how it handles when your buddies identity key changes? Does it just silently accept it and continue allowing messages to pass through?

[gkdr]

Yes, that is what currently happens. I am aware of this issue but figuring out a usable way to do this with libpurple only (i.e. no GUI) was too much at the time, and I am currently still extremely busy with other things. It is the next big thing on my list, I promise :D

[splurched]

And this is the purpose of XEP-0016. It is challenging to understand why people want to depricate utility into a subset of [oversimplified] blocking.

[GigabyteProductions]

To clarity, XEP-0016 says "The protocol . . . can be used to block communication with unknown or undesirable entities." While reading the rest, it is clear that this is similar to server-side blocking of email addresses that are sending you spam (well, it is about creating privacy lists, but for this kind of purpose, it appears). This is not within the same scope or context as creating a trust whitelist of fingerprints for encryption.

To restate the issue, Conversations clients will silently accept keys of new devices (new devices of the same user, which especially makes privacy list applicability questionable), which opens room for privacy invasion by means of being able to decrypt some or all messages (think user password was compromised, or malicious server pretending a user user has a new device), depending on how much attention, to their key lists, users provide. Being a trust issue, creating a whitelist (meaning to not use any keys except for the ones the user has expressed that they trust) is the only sensible solution.

[GigabyteProductions]

Whoops, thought I was on Conversations issue tracker. However, what I said still applies to lurch.

[voidstarstar]

For comparison, on my system the pidgin OTR plugin creates the following files:

~/.purple/otr.fingerprints
~/.purple/otr.private_key

Even without a GUI, these can easily be edited (the fingerprints are stored in a simple human readable plain text file). For simplicity, I would suggest possibly modeling the lurch whitelist after the otr.fingerprints file.

I think the format is as follows:

contact_name account protocol fingerprint status

I think this should be implemented by creating an omemo.fingerprints (or use the sqlite db) file that contains all known fingerprints. Fingerprints can be added in 4 ways (and they could be implemented in this order):

1. Manually edit the fingerprints/sqlite file.
2. Automatically add fingerprints when first contacted.
3. Create a set of convenience commands to manipulate a fingerprint. For example,

   /lurch fingerprint add
   /lurch fingerprint remove
   /lurch fingerprint verified
   /lurch fingerprint unverified

4. Create a GUI wrapper around the above commands (possibly modeled after the pidgin OTR plugin GUI).

Adding a fingerprint, by any means, should always default to unverified status and therefore not be "whitelisted". During a conversation, some visual feedback mechanism is necessary to tell the user if the fingerprint status is verified or unverified. OTR uses a green/yellow/red text for verified/unverified/unencrypted respectively. Colors are ideal, in my opinion, but for a non GUI option, some additional unicode symbols would be good too (e.g. 🔐, 🔒, 🔓, ✔, ✘, etc.).

The OTR plugin has the following options:

1. Enable private messaging
2. Automatically initiate private messaging
3. Require private messaging
4. Don't log OTR conversations

I would recommend lurch add something similar. I would also recommend an additional option that is relevant to this whitelist issue: Require verified fingerprints. This option would simply block communication using any fingerprint that is not present in the database and with a verified status. Enabling this option would act as a whitelist and disabling would act as the current implementation does. I agree with the OP that enabling this option is a necessity for security, especially since there's no visual feedback on the status of fingerprints currently being used in a chat. (Even with visual feedback, this will still prevent accidental security leaks.)

[GigabyteProductions]

Colors can't be the only visual feedback, because of color blind people.

Sorry I can't comment about the rest. I haven't given any deep thought to this, yet.