Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Tony Lee]

First: I am impressed, and honoured, to have had a fast response from
Werner.

I vaguely understand your explanation that the 1024 "Count" value was
interpreted for backward compatibility with 1.4. However, according to
the info gpg, I had followed their instructions in asking for some
specific algorithms and Count values, as:

time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256   \
--s2k-count Count_Value cleartext_file

... where info gpg notes for --s2k-count n : Specify how many times
the passphrases mangling for symmetric encryption is repeated. This
value may range between 1024 and 65011712 inclusive.

... which seems to imply very clearly that I wished to use AES256
together with SHA256, and that I had specified permissible Count
values. Furthermore, this was symmetric encryption (my recipients were
not keen on installing gpg properly!!), with (several) defined
Count_Values --- for my test purposes. Incidentally, the code complained
about names AES-256 and SHA-256, but not about the names used above.

Thus, I do not really understand why my instruction was ignored to
give "1.4 compatibility".




I am still rather in the dark concerning your code as my C does not
exist: I am more the Algol, Fortran, Pascal, and IDL type (I said I
was a long-time, if occasional, User of GnuPG). I hoped I was using
Count values of 1024, 131072, 2097152, 65011712 --- all of which are
legitimate, although I understand that some may be rounded up. If
you need to change the detailed format, what Count values do these
actually produce?

> You can't compare some AES-KDF to the SHA1 based KDF of OpenPGP.  The
> increase in speed you see is due to caching effects on modern CPUs and
> the highly optimized SHA1 code in Libgcrypt.  Something a cracker
> would have also.

OK, this is another surprise to me. I had imagined the KDF would be
based on an iterated AES cipher, rather than an iterated hash
function, and that if a hash function were used it would be the
requested SHA-256. Hash functions may be more typically used to test
the result of KDF processing, rather than forming the KDF itself. As
you know, both AES-128 and SHA-1 are generally deprecated functions.

In any case, I understand that the AES and SHA families are compact
serial functions that can (I assume) be evaluated within a modern CPU
chip using a single thread. I have been assuming that the "Counts"
relate to iterations within the KDF (as AES-128 and AES-256 have
standard "rounds" counts of 10 and 14), which seems to imply the KDF
processing effort (and thus timing) should be linearly related to the
number of Counts.

Perhaps it is, although my uncertainty of effective "Counts" makes
this unclear. For the maximum 65011712 Count, the difference between
28 Bytes and 565 kBytes was 0.02 s, which may relate to the decryption
process. At 2097152 Count, subtraction of 0.02 from the 565kByte
result produces the 28 Byte result; and for this "decryption
subtracted" result, the 31-fold increase from 2097152 to 65011712
Counts produces a 0.320/0.013 = 24.6-fold time increase --- which may
well be equality within the crudeness of this experiment. Trying to
compare smaller (and unknown effective) Counts may well give results
too crude for credibility.


> The default of GnuPG is to let the system take about 100ms for the S2K
> to make brute forcing the password of the private key harder.  Using any
> non-full entropy password for symmetric encryption is a Bad Idea.  With
> a full entropy password the S2K iterations don't matter at all.
>
> So either use a a full-entropy password or use public key encryption.

OK, my plan was to produce a KDF delay of 100--500ms or so, so in
practice we are in the same ball-park.

By "full entropy" I assume you mean an assessed entropy of 80--120
bits. Although in principle I agree, in practice it is very difficult
to produce such randomness: for example, a lengthy English phrase has
certain regularities that reduce entropy, and this is the basis of
modified brute-force techniques. Remember, we are talking symmetric
encryption here; if this is used for communication, we need to
communicate the passphrase by different means, eg by telephone. My
experience is that it is all too easy to mis-communicate high-entropy
passphrases, with subsequent hassle. I agree public-key encryption is
much better for communication, but I have difficulty persuading others
to install gpg properly! The use of a high-delay KDF reduces the
practical number of brute-force attempts, mitigating the need for
high-entropy passphrases to a small extent. Using a modern KDF such as
Argon2 (memory-hard as well as time-hard) would also mitigate the use
of specialised hardware brute-forcing.

Of course, all the above is detail concerning "data on the move". In
practice, I am also concerned about "data at rest", where a hacker may
be able to access my system --- either while I am using passphrases,
or where they are stored. Symmetric encryption is typically used
to encrypt local files, where it is much more practical to use complex
passphrases as they need to be stored but not communicated. However, I
have no oversight of what has been done within gpg to protect
passphrases locally.

In my earlier comment, I noted that KeePass gave a usefully
encouraging oversight of how areas of memory were secured from other
applications while KeePass is in use, giving a degree of protection
from malware etc. It may well be that such techniques are so
blindingly obviously necessary that there is little point in
explicitly describing them. My own perception is that a similar
oversight on gpg would provide much-needed reassurance to someone like
myself who is in no position to evaluate such information from the
open-source code --- I must leave it to others to support/criticize
any reported oversight. Thus, I reiterate my earlier query: Does such
security oversight exist for gpg, and where do I find it? If not, can
it please be produced. It may well be that the descriptions for
KeePass may well provide a template for gpg, provided it is modified
to reflect truth.

As an additional point, during processes where security-critical
keys/passphrases as passed from (say) KeyPass or Yubikey to gpg, or
gpg decrypts secured information to make it visible, what steps are
taken to secure these critical items against malevolent software, or
unwanted storage on disk which may be vulnerable to subsequent attack?

As I explained, any "Counsel of Perfection" on avoidance of malware is
ultimately somewhat unhelpful. I would hope the gpg software would
provide at least some assistance in this area.


Hoping you can help me here.

 Tony