PKESK and SEIPD logic: parameter object's type should become ternary

[falko-strenzke]

Currently, various booleans are used in the code to indictate which packet type is processed.

for instance in stream-write.cpp: pgp_dest_encrypted_param_t

bool                       has_mdc; /* encrypted with mdc, i.e. tag 18 */
bool                       aead;    /* we use AEAD encryption */
bool    is_v2_seipd = false;

These should be united in single enum: mdc, aead and v2seipd

This needs to be addressed analoguously for encryption.

[falko-strenzke]

stream-write.cpp:

in the code pgp_source_encrypted_param_t->aead is used to check for whether to use AEAD packets.

pgp_source_encrypted_param_t should receive the functions:

• is_aead_packet(): to check whether an AEAD packet will be used. This function will replace (in refactored version in the future) all references to param->aead. The function decides based on the ->aead and ->seipd_v2 booleans. If both are true, then it returns false as this is interpreted as seipd_v2.
• is_v2seipd: to replace all references to ->seipd_v2 in the said struct.
• ->has_mdc should also be inferred by a function instead

Once the whole code has been refactored independently by the RNP maintainers the boolean parameters can be replaced by a ternary enum. For the PQC integration we would for now only use the functions in our new code.

stream-read-cpp:

• pgp_dest_encrypted_param_t->aead similarly like above indicates an AEAD packet.
• we introduced the new field ->is_v2_seipd into this struct.

Here we will take the same approach as for stream-parse.cpp outlined above, as the use of the fields is identical.

[ni4]

Sure, this should be refactored to some expandable enum (which could be expandable even further, having two variants of AEAD encrypted packet). I'll do a refactoring PR soon.

[ni4]

PR with proposed changes: https://github.com/rnpgp/rnp/pull/2014 Does it look good to you? To adopt seipd_v2 it should be enough to add new value to rnp::AuthType, updating places where it's value is checked.

[falko-strenzke]

This PR looks good to me. Will you adapt it into the main branch? Then we can merge it into our code.

[ni4]

Thanks. Yeah, it will be merged to the main branch once PR got approved by other team members. I could recommend to do periodical rebases on the main to have less possible merge conflicts afterwards.

[ni4]

JFYI: PR is already merged.

[falko-strenzke]

:+1: great, we're integrating it