Mailing List Archive

Hi,

On Sun, Dec 15, 2019, at 2:05 AM, Dave via Gnupg-users wrote:
> I’ve been playing around some with OpenSSL recently, and it seems to me
> that the OpenSSL command structure is rather convoluted. I’ve read a
> number of articles, blog posts, etc. that criticize GNUPG and even make
> the case that people should stop using it, in large part because of
> concerns around the GNUPG command structure and general usability.

Most of the criticism I have seen is that it is difficult for the target users of a specific use case to use gpg effectively to protect themselves. This is things like message/email encryption/verification.

> Yet
> I can’t recall encountering any similar complaints about OpenSSL. I
> find this somewhat curious, and am wondering if there are OpenSSL
> detractors out there that I simply haven’t come across or if the
> OpenSSL command structure isn’t as complicated as it seems to me. Or if
> it seems to others that OpenSSL doesn’t get the same level of criticism
> as GNUPG does for usability, although the tools seem to offer a
> generally similar user experience.

I haven't seen OpenSSL pitched as the GPG replacement here, possibly for the reasons you cite. Mostly I see, use application X (Signal, etc.) and don't believe email can reasonably be secured without ALL parties being "experts" at GPG. The one use case no one seems to have a replacement for is "encrypt this file on disk for me to use later."

> I suppose that OpenSSL is geared toward a very technical and
> security-aware user base, who aren’t likely to complain about usability
> issues – while GNUPG is a tool that could be used by all sorts of
> users, some of whom are definitely not technically inclined or
> interested in details of information security. That alone could explain
> the difference, I suppose. But I’m wondering if anyone has any other
> thoughts around this topic.

My understanding is that most people encounter OpenSSL configured by someone else who is presumably a technical expert.

What usecases do you have in mind?

regards,

bex

>
>
> Thanks,
>
>
> Dave
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users wrote:
>I can’t recall encountering any similar complaints about OpenSSL. I
>find this somewhat curious, and am wondering if there are OpenSSL
>detractors out there that I simply haven’t come across

OpenSSL definitely has its detractors. They were for example very vocal
back in 2014 in the aftermath of the Heartbleed bug.


>OpenSSL command structure isn’t as complicated as it seems to me.

For what I have seen, most of the criticisms against OpenSSL are
directed at the code and/or the API rather than at the command line
tools. This may reflect the fact that OpenSSL is probably more often
used as a programming library than as a set of command line tools. That
being said I have seen complaints about the command line OpenSSL tools
as well.

(I’ve heard a crypto-nerd once telling me that the only way to correctly
generate a certificate signing request using OpenSSL’s req command was
to type the command while sitting in a demonic circle after having
sacrificed at least a dozen of chickens—or two dozens if the CSR is for
a ECC certificate.)


>I suppose that OpenSSL is geared toward a very technical and
>security-aware user base, who aren’t likely to complain about usability
>issues

I am not sure I’d buy that. All the criticisms I have seen against
either GnuPG or OpenSSL came from very technical-minded people.

By contrast, in my experience non-technical people showing up at
cryptoparties are very much willing to use the software as it is,
learning what they need to learn instead of complaining that the
software should be simple enough that they shouldn’t have to learn
anything.

(Of course those are the people motivated enough to attend a
cryptoparty. They may not reflect the larger group of users.)


Cheers,

- Damien

Damien Goutte-Gattat via Gnupg-users writes:
> On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users
> wrote:
>> I can’t recall encountering any similar complaints about
>> OpenSSL. I find this somewhat curious, and am wondering if
>> there are OpenSSL detractors out there that I simply haven’t
>> come across
>
> OpenSSL definitely has its detractors. They were for example
> very vocal back in 2014 in the aftermath of the Heartbleed
> bug.

I cannot speak for anyone else but from my experience the GnuPG
community ecosystem's way of dealing with issues is way more
conflict prone than how OpenSSL handles this.


One side of that conflict is how GnuPG treats the command line
"API". While my written OpenSSL instructions, automation scripts
around key generation, signing, de/encryption required (minor)
modification due to OpenSSL software changes in the last years,
GnuPG updates from Debian quite often require quite intruding
changes to written manual instructions or automated scripts.
To nail it down, here is the list of changes as an example and
the time to fix (estimate from memory):

OpenSSL:
* Generate dh-params during deployment and always use them on
connection (15 minutes)
* Force SSL to drop older TLS versions on internal connections
(5 minutes)

GnuPG:
* Initrd restructuring due to gnupg-agent use (4h)
* Secure forced termination of gnupg-agent for single-use
private key decryption (4h)
* Update, testing of numerous procedures after introduction
of "pin-entry-mode" (4h)
* Decoding of PGP private key format using RFC to resurrect
old private keys after suddenly not being useable any more
after a minor update (1 day)
* Workaround for secure GnuPG passphrase handling after gnupg
started silently ignoring the command line parameters to have
a stronger passphrase bruteforce security by integrating
GnuPG with argon2. (4h)

As I have the feeling I use OpenSSL and GnuPG in a similar number
of procedures, the much huger amount of time required to keep
GnuPG operational and secure does not make me cheerful about
command line/operating system API stability.


As mentioned above, this is only one side of that conflict. The
other one is, that when such problems occur, which cannot be
avoided even with best software, then documentation or online
resources are usually not very helpful. Thus the community contact
is sought, but to my opinion replies are often not acknowledging
the problem (not accepting that someone might have used GnuPG
for such procedures before the change and requires to find a
working solution to keep production running), empathic (a reply
like: "sorry, we understand this is annoying for you, but this
change was technically required ...), not increasing community
knowlege to build a better GnuPG community (the change was needed
for use-case [reference], thus requirements [reference] contratict
your use case. See [doc-url] for considerations, workarounds ...").

So for example following following sequence or events represents
quite well the usual experience I perceive dealing with GnuPG
software issues:

* Discovering accidentially that GnuPG private key passphrase
bruteforce somehow was reduced to 1/100 strength with new keys.
* Searching the documentation, internet, not finding anything
of relevance to this issue.
* Asking the GnuPG security contact finding out a) the parameter
for better bruteforce protection is silently ignored in GnuPG2
passphrase symmetric key generation b) there is no problem
GnuPG downgrading security on its own without any warning
by ignoring the parameter, c) the documention is outdated/ambiguous
and does not mention the change, c) why do you want to have
a strong bruteforce protection, the reduced value is way better
for good user experience with gnupg-agent? and d) gnupg-agent
will manage (calibrate) that parameter for optimized user
experience automatically to 1/100, no need to mingle with that.
* Me not being happy to reduce bruteforce protection to something
used 10 years ago, thus integrating GnuPG with argon2 to have
appropriate protection again.

Having such experiences more than once reduced trust and sympathy
for GnuPG, thus also willingness to contribute to testing or
development. But maybe just my expectations of GnuPG as open
source software are wrong and my limited communication skills
do not allow me to sort it out in a more positive manner.

hd


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Having such experiences more than once reduced trust and sympathy
> for GnuPG, thus also willingness to contribute to testing or
> development. But maybe just my expectations of GnuPG as open
> source software are wrong and my limited communication skills
> do not allow me to sort it out in a more positive manner.

One of my repeated complaints about GnuPG is that nobody can agree on
what it is. Is it a toolkit for building bespoke cryptographic
solutions? Is it an RFC4880 implementation meant for end-users? Is it
an RFC4880 implementation meant for MUAs? Is it...

A lot of the things you're (rightly, I think) criticizing are the result
of this clouded vision of what GnuPG is meant to do. In the course of
trying to be all things to all people it's occasionally being very
annoying.

You're using it as a toolkit for bespoke solutions. You want your tools
to work consistently across versions.

Other people are using it as an end-user tool. They want the end-user
experience to be continuously refined.

This leads to things like gpg-agent ignoring s2k iteration counts in
order to give a positive end-user experience, at the risk of frustrating
people who are wondering why their bespoke solutions with custom s2k
iteration counts no longer work.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 17/12/2019 14:55, Robert J. Hansen wrote:
> One of my repeated complaints about GnuPG is that nobody can agree on
> what it is.  Is it a toolkit for building bespoke cryptographic
> solutions?  Is it an RFC4880 implementation meant for end-users?  Is it
> an RFC4880 implementation meant for MUAs?  Is it...
>
> A lot of the things you're (rightly, I think) criticizing are the result
> of this clouded vision of what GnuPG is meant to do.  In the course of
> trying to be all things to all people it's occasionally being very
> annoying.

One of my frustrations has long been that the design is inverted - the
core utility is the fully-featured CLI (gpg), and the wrapper interface
is the reduced-featureset API (gpgme). This is a reflection of its
history, especially PGP backwards-compatibility, but causes problems
when trying to use it as a component in a larger system. Unfortunately,
refactoring it to be a fully-featured API with a reduced-featureset
and/or backwards-compatible CLI is a project so overwhelming that I'm
sure nobody wants to take it on...

--
Andrew Gallagher

?On 12/17/19, 9:55 AM, Robert J. Hansen wrote:
> One of my repeated complaints about GnuPG is that nobody can agree on
> what it is. Is it a toolkit for building bespoke cryptographic
> solutions? Is it an RFC4880 implementation meant for end-users? Is it
> an RFC4880 implementation meant for MUAs? Is it...

I would just like to say that GnuPG is meant to be an RFC4880 implementation for MUA's. Anyone who says otherwise is just WRONG ;-)

-- Says the guy who has written countless mail clients and libraries over the years...

Jeff


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

And thank you for doing so, fejj. I'm a big fan of your work, even if we
don't agree on everything.

On Tue, Dec 17, 2019, 11:36 Jeffrey Stedfast via Gnupg-users <
gnupg-users@gnupg.org> wrote:

>
> ?On 12/17/19, 9:55 AM, Robert J. Hansen wrote:
> > One of my repeated complaints about GnuPG is that nobody can agree on
> > what it is. Is it a toolkit for building bespoke cryptographic
> > solutions? Is it an RFC4880 implementation meant for end-users? Is it
> > an RFC4880 implementation meant for MUAs? Is it...
>
> I would just like to say that GnuPG is meant to be an RFC4880
> implementation for MUA's. Anyone who says otherwise is just WRONG ;-)
>
> -- Says the guy who has written countless mail clients and libraries over
> the years...
>
> Jeff
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Robert J. Hansen writes:
> > Having such experiences more than once reduced trust and sympathy
> > for GnuPG, thus also willingness to contribute to testing or
> > development. But maybe just my expectations of GnuPG as open
> > source software are wrong and my limited communication skills
> > do not allow me to sort it out in a more positive manner.
>
> One of my repeated complaints about GnuPG is that nobody can agree on
> what it is. Is it a toolkit for building bespoke cryptographic
> solutions? Is it an RFC4880 implementation meant for end-users? Is it
> an RFC4880 implementation meant for MUAs? Is it...

Yes, I fell this is exactly the cause. But what adds to that
frustration is, that e.g. offering to participate in defining
use cases, requirements, scope of various components seemed not
the way the project would like to go forward, maybe as this would
surface the conflicts in a short run (while avoiding them in
long run).

> A lot of the things you're (rightly, I think) criticizing are the result
> of this clouded vision of what GnuPG is meant to do. In the course of
> trying to be all things to all people it's occasionally being very
> annoying.
>
> You're using it as a toolkit for bespoke solutions. You want your tools
> to work consistently across versions.
>
> Other people are using it as an end-user tool. They want the end-user
> experience to be continuously refined.
>
> This leads to things like gpg-agent ignoring s2k iteration counts in
> order to give a positive end-user experience, at the risk of frustrating
> people who are wondering why their bespoke solutions with custom s2k
> iteration counts no longer work.

I can second nearly everything you wrote, but here I have a different
opinion:

Changing the value might be good for gnupg as end-user tool and
therefore I completely understand, that a change in the default
is positive to most users and hence the project itself. It also
increases the security of the average user I guess, as most likely
they did not configure stronger KDF settings on their own.

I also understand, that such changes being fruitful for many
users (the main use cases) might require others with different
usecases to adopt to the new standard.

What I do not get is, why such design changes are applied in
a non-defensive manner, thus making the end users search for
the changes instead of clearly defining the new API, e.g. by
failing with exit(1). I would hope for that to be a standard
in security-aware software instead silently ignoring a parameter
that once before contributed major boost in protection.



By saying that, I hope I could make clear, that I am not against
having an agile approach to moving open source software forward,
when it is also causing some breakage sometimes. At least gnupg
should not be come the new MS with eternal backward compatibility
in some domains :-)

What I would wish for (and would offer to participate in creating
it) is some formalized, written down quality optimizing procedures
to drive development with such a life-cycle-model in mind for
API, features and deprecation. Maybe some of these already exists,
otherwise it might make sense to define it?

* Write down current usecases, requirements we are aiming to
fulfill at the moment. This makes it more transparent what
gnupg is at the moment and was it wants to be in the future.
By formalizing this process, different opinions are easier
to integreate at design phase thus avoiding troubles after
implementtion. I believe this could also reduce frustration
for gnupg-devs as changes are less disputed (usually only
those opposing are the ones being loud, thus reducing the
feel-good-factor of their great work).
* Rules for deprecation of features settings some rules for
backward compatibility but also removal of features. One thing
I could envision is something like a "--quality" mode switch
with GnuPG. Using this, the software will hard-fail if any
function marked for deprecation (--s2k-count, weak ciphers,
storage formats, ...) is used. While this would still allow
great flexibility for the average user (not depending on
special API or cryptographic properties) while the others
may also run with "--quality" in their continuous integration
environment, thus catching update frictions before those reach
production.
* Define a user feedback process to get a better insight and
real numbers on their usecases (could be as something like
having a lime survey open plus a defined feature request/
positive criticism process) to have real numbers, hard evidence
where end users are moving to. This can then be combined
with the strategy, where we want to move them to, e.g. to
get mail-encryption more common.


hd


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users