search

rnpgp / rnp

RNP: high performance C++ OpenPGP library used by Mozilla Thunderbird
https://www.rnpgp.org
Other
199 stars 55 forks source link

Add logic to determine symmetric encryption mode based on recipient keys? #2219

Open falko-strenzke opened 5 months ago

falko-strenzke commented 5 months ago

Currently, the decision whether to encrypt using v5 AEAD packets is, according to our knowledge, only based on caller parameters. The recipients keys, specifically the Features Subpacket are not evaluated for this purpose.

For the v2 SEIPD packets introduced in the crypto-refresh (currently only supported as experimentally by RNP), the current logic is to encrypt using v2 SEIPD to a v6 key by default. Also here the Features Subpacket, which can indicated support for v2 SEIPD / v6 PKESK independently of the key version, is not evaluated.

Is it of interest that we add such a logic for the evaluation of the recipient keys for the decision which encryption to use to RNP? Or is it the intention to leave that to the caller?

@ni4 @TJ-91 @kaie

ni4 commented 5 months ago

In my view RNP is a tool for higher-level implementation, which gives the caller right to make the decisions, with some reasonable defaults of course. And until v2 SEIPD is widely adopted and used by some major implementation(s) I don't see a need to care about it in advance. Having experimental rnp_op_encrypt_enable_pkesk_v6() and non-experimental rnp_signature_get_features() is pretty enough for this now, as for me.

kaie commented 5 months ago

Is it of interest that we add such a logic for the evaluation of the recipient keys for the decision which encryption to use to RNP? Or is it the intention to leave that to the caller?

I don't know yet what functionality Thunderbird might want here.

As I understand your question, we're talking about the symmetric data packets, which means, all recipients of the email must have the ability to decrypt it.

I think that Thunderbird might want to control which encryption mechanisms it generally allows or disallows, out of compatibility concerns.

As of today, TB doesn't try to be involved here. It asks for algorithms/strength, but currently it doesn't worry about the communication protocol.

I think TB would want this to be automatically decided, based on the set of all the chosen recipient keys. If TB has allowed the use of certain protocol/packet versions, and RNP can automatically determine which versions are supported by all the chosen keys, then I think RNP should make the decision which packet versions or encryption algorithm to use.

Falko's suggestion to allow this selection independent of key versions, but based on feature flags. As I understand it, we're talking about the scenario in which v4 keys might be used for all recipients, but the feature flags of a v4 key might suggest that the recipient supports the new encryption from C-R.

In an ideal world, we should be able to to rely on that. But do we live in that ideal world?

If implementation A imports a key from implementation B, and B supports C-R, but A doesn't support C-R, then A might accidentally advertise support for C-R.

I don't know if we can expect that all implementations will thoroughly adjust feature flags in the future and avoid false feature advertisements.

As long as there is risk that we cannot rely on feature flags to get correctly adjusted by implementations, feature flags are useless for decisions.

It might be more reliable to make decisions based on (sub)key versions.