On Thu, Apr 14, 2016 at 05:41:34PM +1000, Trent W. Buck via luv-main wrote:
[Warning: super ranty email follows.]
Ben McGinnes wrote:
On Wed, Apr 13, 2016 at 10:06:11PM +1000, Russell
On Wed, 13 Apr 2016 05:26:49 PM Ben McGinnes via
As far as I'm concerned if you can't be
bothered editing your
algorithm preference order in gpg.conf and editing your keys and
subkeys (actually they're set according to each UID) to match then you
have no business trying to make keys larger than the default maximums.
Actually I think it's the responsibility of DDs in question (and
other OS developers) to ensure that GPG defaults to the correct
Currently the default in most Linux distros (or OSes for that matter)
is to create ~/.gnupg/ if its not there when the program is invoked,
but not to generate a default gpg.conf.
Why is it the DD's responsibility,
rather than upstream GnuPG project's responsibility?
Because most distros will decide which options their default
installation will compile with. You're assuming that the most common
defaults will be so everywhere *and* that every OS or distro compiles
in all the available algorithms, neither of these are true. For
instance everyone's "favourite" distro and its derivatives (Debian)
does not include Caqmellia in a default installation and that won't be
quite so popular in Japan.
Surely people *writing* crypto software know better
*packaging* crypto software, what the Best Current Practice is.
Yes, but they're also concerned about backwards compatibility to an
extent, not to mention not taking decisions away from people regarding
their own threat models.
Upstream & distro might choose different defaults
because of a
balance between usability & security (especially if it's a
specialist distro), but in general I'd expect upstream to lean
heavily towards security.
Upstream also takes into account multiple device types and security
models, so for a long time the default key sizes also took into
account the physical limitations of key sizes on cards and card
readers. They couldn't handle 4K keys for a *long* time, but the
additional security advantages of keeping secret keys on the device
outweighed that for a lot of people.
Is gnupg upstream defaulting to weak settings?
No, but it isn't defaulting to the strongest possible settings either.
If so, why?
A combination of factors including the processing power limitations of
some devices (e.g. phones), the key size limitations of other devices
(e.g. cards/card readers), compatibility with legacy configurations,
defaulting to AES for symmetric encryption (it's not broken yet, but
some implementations leave a lot to be desired) and so on.
Just to avoid bikeshedding on the ML, or something?
Distributions could set more sensible defaults by
setting a basic
system wide gpg.conf to be copied to a user's directory if it didn't
exist, but the problem is that the first command for a lot of new
users is --gen-key and if the gpg.conf is not already in place when
the command is run then it won't affect the results.
If there's a host-wide default,
it shouldn't need to be copied into ~ to take effect.
No, there are the builtin defaults (effectively the same thing), but
there are a couple of samples in testing/openpgp/ in the source
directory. Pretty much most, if not all, of the command line flags
are the options anyway. At least their long form versions (i.e. not
the short -k, -r, -u, -a and so on, the others invoked with "--"
If it has to be copied in,
what happens when both /etc and ~ versions are edited?
Do the upstream improvements just get ignored for existing users?
A user's own gpg.conf takes precedence if the local installation
supports all the settings, but settings saved into a key itself will
override that. So if I change the order of my preferred algorithms to
place AES256 (back) to the preferred cipher in my gpg.conf that won't
affect my current key unless I also edit it, but it will affect the
preferences for a new key I generate.
So my key is set with cipher preferences placing TWOFISH and
CAMELLIA256 before AES256, but GPG will usually still select AES256
when others send me encrypted email because their systems usually
don't have either of the first two compiled in at all, let alone have
a preference list including them.
Compare with how OpenSSH built-in defaults are
/etc/ssh_config, which is in turn overriden by ~/.ssh/config.
Yeah, it's kind of similar in a number of ways, but gets a little more
complicated by the cipher selection process used by GPG. Especially
when encrypting a message to multiple keys as it tries to select the
most preferred symmetric cipher common to all the keys the message is
[BEGIN TANGENTIAL RANT]
[END TANGENTIAL RANT]
Yeah ... I don't think anyone has a solution for that ... except maybe
to set yourself a reminder (cronjob) to check it every N months.
I dunno if that applies to GnuPG because,
frankly, I've been obscenely lazy.
All coders are lazy, that's what produces most of the scripts and
smaller projects we produce: trying to make things quicker and easier.
Hell, I've even got one that checks coronial findings for certain
names and then tells me if I need to pour myself a doube-shot of
bourbon before I proceed.
> Also it
would be handy if there was a tool to check your GPG
> configuration and key setup for obvious mistakes.
An actively maintained "linter" that checked both config and the
to make sure they followed current best practice,
sounds like a great idea.
I am thinking something like lintian or perlcritic,
which not only says "this is wrong",
but also explains why it's wrong, &
suggests how to fix it.
Well, Werner got back to me on that and there are already plans for
some new interfaces to be included with the upcoming GPG 2.2 (which
follows straight on from 2.1) and you can look forward to an
announcement for an EOL for 2.0 at around the same time (about 2 years
from the announcement which should be a bit later this year).
Don't worry, we're keeping Classic for all the usual reasons. Anyway,
the new interfaces will at the very least check that keys conform to
the current (at the time) RFC requirements (e.g. that they must be
N-bits in length, include an encryption subkey, don't include
encryption with the certification key, etc.). Once that's done it can
be extended to include recommendations (i.e. the SHOULD parts of the
RFC) or whatever.
In the mean time, though, I think I might have to play with this other
little unadvertised gem I found on the git server. It seems that
Werner wrote a Stripe payment processor to take GPG donations and then
didn't tell anyone (well, no big announcement).