If you ask GnuPG to encrypt to a recipient that prefers "AES256, AES192, AES, CAST5, 3DES" in that order, and to another recipient that prefers the reverse order "3DES, CAST5, AES, AES192, AES256", then GnuPG will use 3DES.
This is by choice:
/* Note the '<' here. This means in case of a tie, we will
favor the lower algorithm number. We have a choice
between the lower number (probably an older algorithm
with more time in use), or the higher number (probably a
newer algorithm with less time in use). Older is
probably safer here, even though the newer algorithms
tend to be "stronger". */
For NeoPG, I want the code to always behave as if a crypto preference list has been set by the user that overrides all preferences in the selected keys. The default list should prefer AES over 3DES if it is available.
In case AES is not available in the chosen key, we should raise appropriate warnings or even abort.
I think it is possible to configure this with the right combinations of options in GnuPG, too, but it should be the only way to do it, the right defaults need to be chosen, and the rest of the code can be removed.
If you ask GnuPG to encrypt to a recipient that prefers "AES256, AES192, AES, CAST5, 3DES" in that order, and to another recipient that prefers the reverse order "3DES, CAST5, AES, AES192, AES256", then GnuPG will use 3DES.
This is by choice:
For NeoPG, I want the code to always behave as if a crypto preference list has been set by the user that overrides all preferences in the selected keys. The default list should prefer AES over 3DES if it is available.
In case AES is not available in the chosen key, we should raise appropriate warnings or even abort.
I think it is possible to configure this with the right combinations of options in GnuPG, too, but it should be the only way to do it, the right defaults need to be chosen, and the rest of the code can be removed.