Mailing List Archive: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key)

Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key)

Feb 19, 2022, 6:50 AM

Post #1 of 6 (510 views)

On Fri, 18 Feb 2022 13:08, Daniel Colquitt said:

> Is the suggestion the gpg does not respect these flags when applying
> symmetric encryption to keys?

gpg does not encrypt private keys. This is done by gpg-agent. The
method how the keys are protected internally are out of scope for
OpenPGP. See gnupg/agent/keyformat.txt for the specification of the
internal format.

However, for allowing gpg to export a private key in the OpenPGP
specified format, gpg-agent applies the encryption. For this S2K mode 3
with AES128 and SHA1 is used. The iteration count is the standard count
as figured out by gpg-agent - unless the gpg-agent option s2k-count is
used. See these gpg-agent options:

--s2k-calibration milliseconds

Change the default calibration time to milliseconds. The given
value is capped at 60 seconds; a value of 0 resets to the
compiled-in default. This option is re-read on a SIGHUP (or gpgconf
--reload gpg-agent) and the S2K count is then re-calibrated.

--s2k-count n

Specify the iteration count used to protect the passphrase. This
option can be used to override the auto-calibration done by default.
The auto-calibration computes a count which requires by default
100ms to mangle a given passphrase. See also --s2k-calibration.

To view the actually used iteration count and the milliseconds
required for an S2K operation use:

gpg-connect-agent 'GETINFO s2k_count' /bye
gpg-connect-agent 'GETINFO s2k_time' /bye

To view the auto-calibrated count use:

gpg-connect-agent 'GETINFO s2k_count_cal' /bye

Remember that the OpenPGP specified protection format has some minor
flaws and it is suggested not to rely on this this protection alone.
Use the standard OpenPGP symmetric encryption layer on top.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Re: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key) [ In reply to ]

gnupg-users at gnupg

Feb 19, 2022, 8:02 AM

Post #2 of 6 (510 views)

Permalink

> On 19 Feb 2022, at 14:52, Werner Koch <wk@gnupg.org> wrote:
>
> gpg does not encrypt private keys. This is done by gpg-agent. The
> method how the keys are protected internally are out of scope for
> OpenPGP. See gnupg/agent/keyformat.txt for the specification of the
> internal format.

Apologies for conflating gpg and gpg-agent. I also appreciate that the protection of keys is not part of the OpenPGP specification.

> However, for allowing gpg to export a private key in the OpenPGP
> specified format, gpg-agent applies the encryption. For this S2K mode 3
> with AES128 and SHA1 is used.

Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years. Hence, my question about specifying alternative algorithms for the internal storage and exporting of private keys.

I now understand that it is not possible for the user to alter the encryption algorithm used by gpg-agent to secure private keys. Perhaps it would be a good idea to say this explicitly in a documentation? I appreciate that the manual does not say explicitly that this is possible, it certainly gives that impression.

Anyway, thank you for your help.

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

Re: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key) [ In reply to ]

gnupg-users at gnupg

Feb 19, 2022, 12:52 PM

Post #3 of 6 (510 views)

Permalink

Whoever told you SHA-1 is broken was gravely in error. There are certain areas of the cryptographic space where it is no longer recommended. There are others where it's strong as a rock.
As part of an iterated key derivation function, SHA-1 is still believed safe. There's no reason to shy away from it, or AES128.
(Forgive my terseness, please, writing this from my phone.)
On Feb 19, 2022 11:02 AM, Daniel Colquitt via Gnupg-users <gnupg-users@gnupg.org> wrote:


> On 19 Feb 2022, at 14:52, Werner Koch <wk@gnupg.org> wrote:
> 
> gpg does not encrypt private keys. This is done by gpg-agent. The
> method how the keys are protected internally are out of scope for
> OpenPGP. See gnupg/agent/keyformat.txt for the specification of the
> internal format.

Apologies for conflating gpg and gpg-agent. I also appreciate that the protection of keys is not part of the OpenPGP specification. 

> However, for allowing gpg to export a private key in the OpenPGP
> specified format, gpg-agent applies the encryption. For this S2K mode 3
> with AES128 and SHA1 is used. 

Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years. Hence, my question about specifying alternative algorithms for the internal storage and exporting of private keys.

I now understand that it is not possible for the user to alter the encryption algorithm used by gpg-agent to secure private keys. Perhaps it would be a good idea to say this explicitly in a documentation? I appreciate that the manual does not say explicitly that this is possible, it certainly gives that impression.

Anyway, thank you for your help.

Dan
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key) [ In reply to ]

gnupg-users at gnupg

Feb 19, 2022, 6:07 PM

Post #4 of 6 (510 views)

Permalink

Daniel Colquitt via Gnupg-users wrote:
> Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years.

Has it really been that long? ... No, it has not been: a free-start
collision was found on the SHA-1 compression function in 2015, less than
7 years ago.

As far as I know, a single collision pair ("SHAttered") has been
produced, using about 9 months on a very large cluster, against the full
SHA-1. There is no comparison here to MD5, for example. Further, only
collisions have been demonstrated so far, and if Mallory producing a
colliding private key is a concern for you, you have bigger problems,
like Mallory having provided your private key in the first place!

It is also worth noting that SHA-1 is (as far as I know) only used as a
fancy checksum here to guard against data corruption. If Mallory even
has access to potentially replace your private key, you have bigger
problems than potential weaknesses of the checksum on that key.

-- Jacob

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

RE: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key) [ In reply to ]

gnupg-users at gnupg

Feb 20, 2022, 12:30 AM

Post #5 of 6 (510 views)

Permalink

> Has it really been that long? ... No, it has not been: a free-start
collision was
> found on the SHA-1 compression function in 2015, less than
> 7 years ago.
>
> As far as I know, a single collision pair ("SHAttered") has been produced,
> using about 9 months on a very large cluster, against the full SHA-1.
There is
> no comparison here to MD5, for example.

I used "broken" in the formal cryptographic sense - finding collisions
faster than brute force. Although SHAttered was the first public collision,
attacks capable of finding collisions far quicker than brute force have been
known since 2005<https://eprint.iacr.org/2007/474>

> Further, only collisions have been
> demonstrated so far, and if Mallory producing a colliding private key is a
> concern for you, you have bigger problems, like Mallory having provided
> your private key in the first place!
>
> It is also worth noting that SHA-1 is (as far as I know) only used as a
fancy
> checksum here to guard against data corruption. If Mallory even has
access
> to potentially replace your private key, you have bigger problems than
> potential weaknesses of the checksum on that key.

I agree with you, and Robert Hansen above, insofar as there is no practical
weakness in using SHA-1 as part of a key derivation algorithm. However, I
would argue that there is a serious problem with using SHA-1 to verify
digital signatures - but that is a matter for OpenPGP rather than GnuPG.

Nevertheless it does seem imprudent to use a formally broken hash function
by default, whilst silently ignoring options that users would reasonably
expect to change the algorithms used.

Dan

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

Re: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key) [ In reply to ]

bernhard at intevation

Feb 24, 2022, 1:56 AM

Post #6 of 6 (509 views)

Permalink

Am Sonntag 20 Februar 2022 09:30:36 schrieb Daniel Colquitt via Gnupg-users:
> I agree with you, and Robert Hansen above, insofar as there is no practical
> weakness in using SHA-1 as part of a key derivation algorithm.

(for protecting exported private keys)

> Nevertheless it does seem imprudent to use a formally broken hash function
> by default, whilst silently ignoring options that users would reasonably
> expect to change the algorithms used.

The point, as I understand it, is compatibility.
Exporting and importing a private OpenPGP key is expected to work for many
implementations and over several software revisions and years. So adhereing
to a standard (OpenPGP in this case) seems a good choice.

You can use additional protection layers, as Werner suggested.
This seems also reasonable from a usability point of view as exporting,
transfering and importing of private OpenPGP keys is a rare process.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Mailing List Archive

Attached Files:

Attached Files: