Setpref is not working or is it a bug or something?

[Robin Mathew Rajan]

Hi gnupgpack, :)

You can delete these values from your current gpg.conf.

s2k-digest-algo SHA256
s2k-cipher-algo AES256
cert-digest-algo SHA256
digest-algo SHA256

Reason 1: Those values are used when options like 'personal-cipher-preferences', 'personal-digest-preferences' and 'personal-compress-preferences' are not given! But here, you already gave those three options already.

Refer: https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html

Reason 2: Those values are known to break the OpenPGP standard. OpenPGP is nothing but a set of guidelines which instructs on how the PGP concept should be implemented in various softwares.

Let's quote an example to get the idea of 'IETF standards' effectively.

We all know how a Desktop Computer looks like. Mouse, Keyboard, LCD Monitor, A case in which the CPU, Motherboard, HDDs are included and a unique OS etc. That's what a typical desktop computer look like. We can call that 'typical' desktop computer to be 'reference model.' Or in another words, that computer could be a 'standard computer'.

Now let's have a look at another Desktop Computer.

Based on the earlier reference model of Desktop Computer, another one built a Desktop Computer. This computer has all the features of earlier reference model, plus, the features of its own. This one includes: bigger case with lots of fancy lights, liquid cooling systems, SSDs, GPGPUs, OS with more features etc. None of these extra features are not in the earlier reference computer.

Both are Desktop Computers. But what's the difference? The former is a reference computer with all the essentials built-in which respects compatibility. The latter one is a high-end one which includes fancy options but not compulsory to be in a computer. And moreover, since the OS second computer holds more features than the reference model, when connected to a network, the both computers can't communicate. 

To communicate, both computers should know a common language with common instructions. If the communication language is different, there will be no communication.

It's just like we humans use 'English' as a common language. We all come from different nations. We all have different languages. But there should be something in common to communicate. Moreover, surprisingly, the English language itself has different accents around the world. I'm an Indian. We use Indian accented English. So does people from other parts of the world. But since the accents of English language is fragmented, there should have one reference accent which all other people from all nations should consider learning. And that's the native accents 'British' or 'American' accents mainly.

That's the same OpenPGP does. OpenPGP standard is just a reference model. Anyone can modify it and include unique features. But it's not necessary to be those 'unique features' to be included in every OpenPGP implemented products. But when it comes to communicating each other, there comes the problem if there's no common standard rule.

With those settings, the communication between Symantec owned PGP products and GnuPG will be problematic. That's why we have to stick to the reference standards as much as possible.

But there's a caveat with strict implementation of standards. In cryptography, there's a Performance vs Security thing. If we tend to move more towards Performance, the Security will be low. And if we tend to move more towards Security, the Performance will be low. We have to maintain the level of Security vs Performance trade-off, to be medium as possible.

As because there are so many OpenPGP implementations, we can't really guarantee which configuration is more compatible and which configuration is most secure. If we tend to move more towards compatibility, the level of security will be low. And we tend to move more towards security, compatibility will be an issue.

That's why I chose, these four extra configurations which I believe most secure with fewer compatibility issues with newer releases of OpenPGP implementations and other softwares. These preferences won't break the OpenPGP implementation, but at the same time, offers high security too.

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 CAMELLIA128 AES CAST5 IDEA BZIP2 ZLIB ZIP
personal-cipher-preferences AES256 CAMELLIA256 TWOFISH
personal-digest-preferences SHA512
personal-compress-preferences BZIP2

But at the same time, these settings might be incompatible with older softwares. But that's something we should decide personally. Should we choose the most compatible configuration or the most secure configuration? Let's that decide ourselves.

Refer: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html

Reason 3: You have set 's2k-digest-algo', 'cert-digest-algo' and 'digest-algo' configurations to SHA-256. But at the same time, you have set 'personal-digest-preferences' and 'default-preference-list' configurations to SHA-512.

That's incompatible and contradictory configuration. Our, Robert J. Hansen already said that in another thread in 2012.

"Robert J. Hansen | 27 May 13:29 2012
Re: A mixed case of keys and AES256 vs CAST5

> In my gpg.conf file, I have the following settings:
> 
>    cipher-algo aes256

Please don't do this.  This overrides GnuPG's built-in algorithm
selector.  The algorithm selector makes sure that your traffic will be
readable by your recipient's OpenPGP implementation.  There exist a lot
of OpenPGP implementations (particularly PGP 7.0 and prior) that don't
support AES256.  This option will make your data unreadable by those
systems.

It is enough to have AES256 listed as your most-preferred cipher.

>    personal-digest-preferences SHA256
>    default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192  AES
> CAST5 ZLIB BZIP2 ZIP Uncompressed

These two lines contradict each other.  First you say SHA256 is your
preferred digest, then you say SHA512 is.

I don't have an answer for why you're seeing two different algorithms
being used, I'm sorry.  I have a few guesses, but no certainties.

> A message will be sent to an organisation and the sender does not want  to
> encrypt it with her own key, ergo mail address. However, she wants  to have
> possible access to the content in the future.

This is what the "hidden-encrypt-to" option is meant for.  You don't
need symmetric encryption."

Refer: http://comments.gmane.org/gmane.comp.security.pgp-basics/7339

Additionally, by typing this command, we can see how our existing keys are encrypted.

For Linux: gpg --list-packets ~/.gnupg/secring.gpg

For Windows: %APPDATA%\gnupg\secring.gpg

For example, C:\Users\Admin\AppData\Roaming\gnupg\secring.gpg

Replace 'Admin' with your user name.

So it becomes, C:\Users\<replace user name here>\AppData\Roaming\gnupg\secring.gpg

Thanks and regards, :)
Robin Mathew Rajan
https://www.robinmathewrajan.com/


> What's about the standard SHA1 hash with signatures?
> In gpg.conf really no need for:
> 
> s2k-count 1000000
> s2k-digest-algo SHA256
> s2k-cipher-algo AES256
> cert-digest-algo SHA256
> digest-algo SHA256
> personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5
> personal-digest-preferences SHA512 SHA384 SHA256 SHA224
> personal-compress-preferences ZLIB BZIP2 ZIP
> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH AES192
> AES CAST5 ZLIB BZIP2 ZIP
> 
> ???
> 
> Thanks a lot, regards @g.
> 
> *still learning...*