[pkg-gnupg-maint] diverging from upstream defaults

[Daniel Kahn Gillmor]

On Fri 2017-09-08 08:57:55 +0200, Werner Koch wrote:
> What I read was : I [dkg] did not need to do this one [default s2k]
> because upstream [wk] already did this.
>
> That is definitely not the case.  Thus I took it as if upstream already
> chnaged all the things you listed.  Out of this only the AES
> *preferences* were changed by upstream.

I see, i think this was just confusion about the ordering of my comments
and the quoted text.  we agree on the underlying reality :)

> I think we already talked about AES128 vs AES256 in the past.  I do not
> see a reason to chnage the _default_ cipher.  This would anyway be a
> major change because it is only used with --symmetric and often
> (backups) performance is here an issue.

People who have these performance concerns can explicitly set the
default cipher if they have performance concerns, right?  the question
is who should have to make manual changes: people making backups who
have performance concerns, or people making backups who have security
concerns?

> SHA-256 vs: SHA-512: There has been a heated debate in the OpenPGP WG on
> this and the current state is that we use SHA-256 for the fingerprint to
> allow for a SHA-256 only implementation (even if that means ed25519
> can't be used).  Thus I won't take this upstream.

understood (though i think it's too bad!) presumably those folks who
don't have SHA-512 available to them are on extremely lightweight
devices (IoT), who would be the most likely use case for curve 25519, so
i have a hard time imagining who we're protecting with this, though.

> If you like, RSA3072 better feel free to use it and also push it to master.

thanks, i've done so, both for gpgsm and for gpg.

> For Debian, I would suggest to think about moving to ECC and - even
> better - require hardware tokens.

When you say "for debian" i think you mean "for debian developers" --
the keyring-maint team and DSA (the debian system administrators) have
had a few conversations about what it'll take to do the move to ecc, and
i don't think the infrastructure is fully ready yet.

As for requiring hardware tokens, there are other folks working on that
(anarcat has done a bunch of review/research recently) and i'm not yet
convinced that i'm willing to inflict the extra pain (delay, risk of
hardware loss, etc) as a mandatory for participation in debian.

I'm definitely interested in what we can do to help developers keep
their keys well-protected more generally, though.  I'd be happy to
explore that option space in a separate thread if you like.

> I am not sure about the 100ms vs. 300ms change for S2K.  300 ms is a
> noticable delay but 100ms is acceptable in a a UI.  Again the
> --symmetric encryption kicks in.  This is often used in automated
> settings and that may decrease troughput by a factor of 3!

hm, this is true, but i suppose it depends on what else is going on --
e.g. if a large amount of data is being encrypted, then then symmetric
encryption workload might be the throughput bottleneck.  but for small
data payloads, you're right that this will hurt throughput.  I hope
someone will speak up if they have that use case.

Regards,

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170908/5d2ef42b/attachment.sig>