Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

Bernhard Reiter bernhard at intevation.de
Mon Sep 12 11:43:21 CEST 2022


Am Dienstag 30 August 2022 18:41:19 schrieb Tony Lee via Gnupg-users:
> 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

Generating passphrases from a large dictionary makes this feasable
E.g. https://wald.intevation.org/scm/browser.php?group_id=71&scm_plugin=scmhg
is a small tool I wrote a few years ago to understand this better,
calling it with the English dictionary from `trans`, I get

./ppgen.py -2
Reading entries from /usr/share/trans/de-en....................
Found 129207 dictionary entries.
|= Number of words |= possibilities |

|                4 |    2^67.9      |
|                5 |    2^84.9      |
|                6 |    2^101.9      |

So with 5 or six words, you easily have a passphrase in the desired range.
(There are other generators a well.)
In my experience, it is possible to memorize such passwords, by construction
a story around it. Of course it is some effort, but then again 3 or 4 words
maybe enough for your use-case and see next point:

> I agree public-key encryption is
> much better for communication, but I have difficulty persuading others
> to install gpg properly! 

Given the overall advantages, what are the difficulties to convince
your peers to install GnuPG? (Or any other OpenPGP implementation.)

> 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

More documentation naturally is helpful, but it is a lot of effort
to write and it must be kept in sync. Who tells you that the overview
documention still represents the technical implementation well?
A lot of things are changing by the months, not just the implementation,
but also the understanding of security properties (like attack capabilities).
But those have to be re-considered if the necessary summary judgement
of the overview shall be useful I think.
So I think this overview documentation you are asking for, would be less 
useful than expected.

> what steps are
> taken to secure these critical items against malevolent software, or
> unwanted storage on disk which may be vulnerable to subsequent attack?

The first and most important step is to secure your operating system,
environment and storage according to your security needs.
The challenge here is that this is beyond GnuPG (or any other single 
application) to control. Nor is it useful to try in many cases.

Take virtualisation as example, there is no way for GnuPG to know if
it is runsin a virtual computing environment where the memory can be
frozen into storage at any time. Same with safe deleting of files.

Putting the effort into following general secure computing practive
will help your GnuPG security more, usually.

Regards,
Bernhard

-- 
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220912/8e4d1442/attachment-0001.sig>


More information about the Gnupg-users mailing list