Mailing List Archive

jsmith9810--- via Gnupg-users wrote:
> Hello all,
>
> I have a private key protected by blowfish cipher that despite a random salt and several rounds of RIPEMD160 iterations is still considered "weak" by GnuPG and it refuses to do anything with it. When I try to import this key manually (--import), gpg throws a "weak encryption key" error and refuses to import it. ...which I find ironic, because it has no problem importing unprotected plain-text keys. Also, it's worth pointing out that GnuPG applies its default protection scheme to the private keys imported this way regardless of what encryption these keys used earlier - which means that the issue that it's complaining about will actually be resolved simply by importing this key.
>
> I still managed to force this key into GnuPG's private key store through the secring.gpg migration route which preserves the key in its openpgp-native format, but now gpg refuses any operation involving this private key - sign, encrypt, etc. It won't even let me change the password - which would actually make this issue go away. I tested with GnuPG 1.4.23 as well and it does not have a problem either importing or using this key.
>
> I am not looking for a solution as I can easily work around this problem by changing password using GnuPG 1.x prior to importing this key in GnuPG 2.x, but should this be logged as a product defect? This doesn't look like reasonable way to deal with these so-called "weak" encryption keys when importing these keys would actually address the issue at hand.
>
> Thanks!

The problem is that a private key protected by a weak cipher is still
potentially compromised if an attacker can get any copy of the key prior
to migrating it to a stronger cipher. In other words, if an attacker is
able to obtain your current key blob, the attacker can still compromise
your key by cracking that copy, even after you have migrated your copy
to a stronger wrapping.

If an attacker was interested in you, your key is lost and the best path
forwards is to revoke it and generate a new key. You could sign the new
key with the old one before revoking the old key.


-- Jacob


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

> The problem is that a private key protected by a weak cipher is still
> potentially compromised if an attacker can get any copy of the key prior
> to migrating it to a stronger cipher. In other words, if an attacker is
> able to obtain your current key blob, the attacker can still compromise
> your key by cracking that copy, even after you have migrated your copy
> to a stronger wrapping.
>
> If an attacker was interested in you, your key is lost and the best path
> forwards is to revoke it and generate a new key. You could sign the new
> key with the old one before revoking the old key.
>
>
> -- Jacob
>

A private key protected by weak blowfish cipher is by no means more at risk
compared to an unencrypted key, which GnuPG has no problem with.

Also, from what I've read about blowfish weak keys (and I admit I didn't spend
too much time on it), the attacks are unrealistic in that even though they
reduce the complexity compared to brute forcing a 128-bit key, it's still
near-impossible to retrieve the plain-text or the key itself within reasonable
amount of time. And I also recall reading that it requires a large amounts of
known plain-text and corresponding cipher-text data. In this case, it's a
unique key that's only used to encrypt a few hundred bytes of data. So the risk
of an attacker being able to just "crack" your private key based on the weakness
of the cipher key seems to be quite an overstatement.

Besides, shouldn't the assessment of the security of the key be better left to
the user? It would be totally reasonable to warn the user about the potential
risks and even make a recommendation to revoke this key. But not allowing them
to decrypt something that was previously encrypted with this key doesn't seem
justifiable even if the risks were as high as you stated.

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

jsmith9810@gmx.com wrote:
>> [...]
>
> A private key protected by weak blowfish cipher is by no means more at risk
> compared to an unencrypted key, which GnuPG has no problem with.
>

The difference is that you *know* an unencrypted key is lying around at
risk of compromise, and you knowingly chose to take that risk when you
chose to store the key unencrypted.

> Also, from what I've read about blowfish weak keys (and I admit I didn't spend
> too much time on it), the attacks are unrealistic in that even though they
> reduce the complexity compared to brute forcing a 128-bit key, it's still
> near-impossible to retrieve the plain-text or the key itself within reasonable
> amount of time. And I also recall reading that it requires a large amounts of
> known plain-text and corresponding cipher-text data. In this case, it's a
> unique key that's only used to encrypt a few hundred bytes of data. So the risk
> of an attacker being able to just "crack" your private key based on the weakness
> of the cipher key seems to be quite an overstatement.
>

I am assuming that there is some more severe problem with OpenPGP
Blowfish key wrapping, since the situation you describe would not
warrant the measures GPG has taken. (In other words, I am assuming that
the GPG developers know something here that we do not, and I believe
that to be a reasonable assumption.)

> Besides, shouldn't the assessment of the security of the key be better left to
> the user? It would be totally reasonable to warn the user about the potential
> risks and even make a recommendation to revoke this key. But not allowing them
> to decrypt something that was previously encrypted with this key doesn't seem
> justifiable even if the risks were as high as you stated.
>

You are correct that the situation you describe does not reasonably
support completely rejecting the key. That is the reason I expect that
there is a problem serious enough that the key should be considered
compromised.


-- Jacob

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

Am Montag 22 M?rz 2021 23:32:14 schrieb Jacob Bachmeyer via Gnupg-users:
> I am assuming that there is some more severe problem with OpenPGP
> Blowfish key wrapping, since the situation you describe would not
> warrant the measures GPG has taken.

Not know details about this one: Sometimes stuff gets deprecated for cleanup
reasons and for long term prospects. Often you can find more details in the
code.

> (In other words, I am assuming that
> the GPG developers know something here that we do not, and I believe
> that to be a reasonable assumption.)

In my experience GnuPG developers (which I'd include myself) strongly like to
have everything in the open (to be verifiable). The only situation I can
image that we or others keep something back is for a limited time during the
course of a responsible disclosure, but this does not seem to be the case
here as the code is there.
(What also happens with software is that details are not explained.)

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

On Mon, 22 Mar 2021 17:43, jsmith9810--- said:

> I try to import this key manually (--import), gpg throws a "weak
> encryption key" error and refuses to import it. ...which I find

Can you please paste the exact error message and the output of
"gpgconf --show-versions"?


Shalom-Salam,

Werner

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

> > I try to import this key manually (--import), gpg throws a "weak
> > encryption key" error and refuses to import it. ...which I find
>
> Can you please paste the exact error message and the output of
> "gpgconf --show-versions"?
>
>
> Shalom-Salam,
>
> Werner
>

Sure. My gpgconf doesn't seem to have the "--show-versions" option.
It's the 2.2.19 release that currently ships with Ubuntu 20.04 (Focal), in case it helps.

$ gpgconf --show-versions
gpgconf: invalid option "--show-versions"

$ dpkg-query -l *gnupg*
ii gnupg 2.2.19-3ubuntu2.1 all GNU privacy guard - a free PGP replacement
ii gnupg-l10n 2.2.19-3ubuntu2.1 all GNU privacy guard - localization files
ii gnupg-utils 2.2.19-3ubuntu2.1 amd64 GNU privacy guard - utility programs

________________________________________________________________________________

Here's what I get when trying to import this key:

$ gpg --debug-level expert --import /tmp/weak-key.gpg
gpg: key AFD8C1044388D9EB/AFD8C1044388D9EB: error sending to agent: Weak encryption key
gpg: error reading '/tmp/weak-key.gpg': Weak encryption key
gpg: import from '/tmp/weak-key.gpg' failed: Weak encryption key
gpg: Total number processed: 0
gpg: imported: 1
gpg: secret keys read: 1

________________________________________________________________________________

If I do a force-import via secring.gpg migration to 2.x in openpgp-native format,
it's succeeds without error, the secret key is listed but none of the operations
that use this secret key work (including change-passphrase). I see the following
messages after keying in the passphrase in pinentry:

$ gpg --debug-level expert --decrypt secret.gpg
gpg: public key decryption failed: Weak encryption key
gpg: decryption failed: No secret key

$ gpg --debug-level expert --sign message.txt
gpg: signing failed: Weak encryption key

$ gpg --debug-level expert --edit-key 5DA34AB39C214001DB61D96FAFD8C1044388D9EB
gpg: key AFD8C1044388D9EB/AFD8C1044388D9EB: error changing passphrase: Weak encryption key

________________________________________________________________________________

Interestingly, when I tried searching the latest GnuPG code base (cloned from github)
for the "Weak encryption key" error message, nothing showed up.

$ "grep -iRl "Weak encryption key" gnupg
<no matches>

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

> Interestingly, when I tried searching the latest GnuPG code base (cloned from github)
> for the "Weak encryption key" error message, nothing showed up.
>
> $ "grep -iRl "Weak encryption key" gnupg
> <no matches>
>

It appears that the problem lies in libgcrypt, which refuses to set a key for this
cipher that's considered weak.

libgcrypt/cipher/blowfish.c

static gcry_err_code_t
do_bf_setkey (BLOWFISH_context *c, const byte *key, unsigned keylen)
...

/* Check for weak key. A weak key is a key in which a value in
the P-array (here c) occurs more than once per table. */
if (weak)
return GPG_ERR_WEAK_KEY;

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

On Dienstag, 23. M?rz 2021 14:31:00 CET jsmith9810--- via Gnupg-users wrote:
> Interestingly, when I tried searching the latest GnuPG code base (cloned
> from github) for the "Weak encryption key" error message, nothing showed
> up.
>
> $ "grep -iRl "Weak encryption key" gnupg
> <no matches>

It's defined in the separate libgpg-error library. It corresponds to the
symbol GPG_ERR_WEAK_KEY. This symbol occurs in libgcrypt (the low-level crypto
library of GnuPG), e.g. in blowfish.c, and in gnupg.

Regards,
Ingo

On Mon, 22 Mar 2021 17:32:14 -0500, Jacob Bachmeyer via Gnupg-users <gnupg-users@gnupg.org> wrote:
> The difference is that you *know* an unencrypted key is lying around at
> risk of compromise, and you knowingly chose to take that risk when you
> chose to store the key unencrypted.

Pardon my non-gpg-familiarity, but isn't a "weak key" completely
different from a (maybe) divulged key ?

AFAIK a weak key is a key that, when used, produces a result which is
easier to break than what the cipher promises. In other word, this
would be something specific to this very key, to the value of its
components being poorly chosen, and in no way related to how it was
stored/obfuscated itself.

IOW, isn't this specific key one of the identified blowfish weak keys
classes ?
https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
Also:
https://en.wikipedia.org/wiki/Weak_key

Meaning not only this key, but anything it signed and/or was encrypted
for (I did not check which one is affected), may be considered
compromised ?
--
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

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

Vincent Pelletier wrote:
> On Mon, 22 Mar 2021 17:32:14 -0500, Jacob Bachmeyer via Gnupg-users <gnupg-users@gnupg.org> wrote:
>
>> The difference is that you *know* an unencrypted key is lying around at
>> risk of compromise, and you knowingly chose to take that risk when you
>> chose to store the key unencrypted.
>>
>
> Pardon my non-gpg-familiarity, but isn't a "weak key" completely
> different from a (maybe) divulged key ?
>

There are two keys involved here: a PGP private key that is stored
encrypted under a symmetric key. It appears that that symmetric key has
been found to be weak. If an attacker can obtain the encrypted blob and
crack the symmetric encryption, the PGP key would be divulged.

> AFAIK a weak key is a key that, when used, produces a result which is
> easier to break than what the cipher promises. In other word, this
> would be something specific to this very key, to the value of its
> components being poorly chosen, and in no way related to how it was
> stored/obfuscated itself.
>

The weak key in this case is the symmetric cipher key used to encrypt
the PGP private key.

> IOW, isn't this specific key one of the identified blowfish weak keys
> classes ?
> https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
> Also:
> https://en.wikipedia.org/wiki/Weak_key
>
> Meaning not only this key, but anything it signed and/or was encrypted
> for (I did not check which one is affected), may be considered
> compromised ?
>

The risk is that an attacker may be able to crack the encryption on the
stored private key because it was encrypted with a weak key. Given that
PGP keys are very short, it is possible that Blowfish may be safe here,
even with a weak key. If this is the case, using an old version of GPG
to import the affected private key and change the passphrase should fix
the problem, since the symmetric key (and possibly algorithm) used to
store the private key will then change.

If Blowfish is not safe under these circumstances (weak key encrypting a
limited amount of data), then the PGP key in question should be presumed
compromised and should be replaced.


-- Jacob

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

On Tue, 23 Mar 2021 20:20:02 -0500, Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> There are two keys involved here: a PGP private key that is stored
> encrypted under a symmetric key. It appears that that symmetric key has
> been found to be weak. If an attacker can obtain the encrypted blob and
> crack the symmetric encryption, the PGP key would be divulged.

Oh, blowfish is the symetric one. My bad, I so,ehow thought it was the
asymmetric key which was weak.

As you say, it does not really change the conclusion, but thanks a lot
for the correction.

Regards,
--
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

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

> Sent: Tuesday, March 23, 2021 at 9:44 AM
> From: "Ingo Klöcker" <kloecker@kde.org>
>
> It's defined in the separate libgpg-error library. It corresponds to the
> symbol GPG_ERR_WEAK_KEY. This symbol occurs in libgcrypt (the low-level crypto
> library of GnuPG), e.g. in blowfish.c, and in gnupg.
>

Okay, I think I have figured out the reason for this behavior.
The libgcrypt library that's used by GnuPG had completely
disabled the use of weak keys for symmetric ciphers. I believe
it previously just issued a warning, but still allowed the use
of the weak keys. This is causing the setkey operation to fail
in GnuPG.

I also noticed that libgcrypt gas now introduced a mechanism
to allow the use of weak keys through a recent commit:
2020-02-02: 5beadf201312d0c649971b0c1d4c3827b434a0b5

So it's now possible to leverage this feature and support
importing of existing PGP keys protected with a weak symmetric
key, that were generated with the older version of GnuPG. If
there is an appetite to address this issue, I can create a task
in the tracker.

Thanks!

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