diverging from upstream defaults

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Sep 15 01:46:23 CEST 2017

On Wed 2017-09-13 20:42:06 +0200, Vincent Breitmoser wrote:
> Picking up on the s2k default:
>>> I am not sure about the 100ms vs. 300ms change for S2K.
>> I hope someone will speak up if they have that use case.
> I don't have "that" use case, but it's probably worth mentioning that
> moving a 100ms-adjusted key from a desktop machine to a smartphone can
> already be problematic even with 100ms. Particularly if the desktop
> machine is relatively newer than the phone, the difference in speed can
> become a factor 10 or more.

The workflow for importing a secret key to a new device should include
an import step that adjusts the cryptographic protection on the key to
match something sensible for that device (and to verify that the user
actually can unlock the key in the first place).

if the one-time import of a secret key to a new device costs 5 seconds
instead of 500ms, i'm not particularly troubled by that change.

If some piece of software imports a key without either:

 * a checking that the user can control the key, or
 * that the cryptographic protection for the key makes sense for the

then i don't think the problem is with gpg-agent's key-stretching
calibration, is it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170914/353afdff/attachment.sig>

More information about the Gnupg-devel mailing list