[pkg-gnupg-maint] diverging from upstream defaults

[Daniel Kahn Gillmor]

On Fri 2017-09-08 18:24:53 +0200, Werner Koch wrote:
> On Fri,  8 Sep 2017 17:49, dkg at fifthhorseman.net said:
>
>> is who should have to make manual changes: people making backups who
>> have performance concerns, or people making backups who have security
>> concerns?
>
> Having more backups may also be a security advantage ;-)
>
> Okay. so use AES256, but lets do it this way:
>
> --8<---------------cut here---------------start------------->8---
> -#if GPG_USE_AES128
> +#if GPG_USE_AES256
> +# define DEFAULT_CIPHER_ALGO     CIPHER_ALGO_AES256
> +#elif GPG_USE_AES128
>  # define DEFAULT_CIPHER_ALGO     CIPHER_ALGO_AES
>  #elif GPG_USE_CAST5
> --8<---------------cut here---------------end--------------->8---

Done, and pushed to master as 73ff075204df09db5248170a049f06498cdbb7aa.



>> SHA-256 vs: SHA-512: There has been a heated debate in the OpenPGP WG on
> [...]
>> 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.
>
> Indeed that is a problem with ed25519 - but at least they can use cv25519.
>
> To avoid source code chnages, would a configure option be useful to
> switch the preferences?

that'd be great, but there are two different decisions here:

 a) DEFAULT_DIGEST_ALGO (--cert-digest-algo and --digest-algo both
    inherit it by default) -- should it be SHA256 or SHA512?

 b) order of the default preferences embedded in OpenPGP certificates
    (should it go "SHA512,SHA384,SHA256" or "SHA256,SHA384,SHA512"?)

i could see a few approaches:

 0) have the configure option select DEFAULT_DIGEST_ALGO (any algorithm), and either:

  0.1) just switch over the default preferences or

  0.2) make default preferences auto-detected on the basis of the
       performance of SHA512 vs. SHA256 on the build platform (might
       make life difficult for cross-compilation),

 1) have the configure option only switch between SHA256 and SHA512, and
    have it control both (a) and (b)

 2) have the configure option switch between SHA256 and SHA512 and make
    it auto-detect based on knowledge about the platform.

But all of this seems like quite a bit of source code changes -- and
varying the default preferences leaks something about the build
platform.

> It would be cool if Debian could suggest the use of a token.  Because I
> favor the Gnuk the ECC support would be important.  But right, we also
> need to get our job doe and make Gnuk easier avaialble.

Agreed -- one thing that would be an obvious win would be to ship the
gnuk firmware images in debian to make it easier to flash and upgrade.

let's follow up on this over on gnuk-users at lists.alioth.debian.org.

> [ s2k changes ]
>
> Then this looks like a configure option thing.  I mean at least a
> configure build option but it is also possible to add an additional
> gpg-agent.conf option, for example to reduce the built in default.

This sounds like two different issues:

 * configure option for default calibration time
   https://dev.gnupg.org/T3399

 * runtime option for gpg-agent
   https://dev.gnupg.org/T3400

Seem right?

     --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/3075b282/attachment.sig>