Maniphest T2038

Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE only when using lengthy passphrases
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	SlipperyCow
	Jul 11 2015, 6:45 AM

Description

Hi Folks,

This issue likely only impacts a small percentage of the user base, but I would
like to understand what changed to cause this error to occur. I also noticed a
similar problem in Issue 1954 - but that appears to be from a Gnome user.

I'm a Gentoo Hardened guy, but I run plenty of other OSes on native HDDs
or under KVM, which is how I discovered this issue:

Enigmail/pinentry-qt/qt4/gtk (pinentry-X, below) fails on Fedora 22 with
KDE when using lengthy passphrases.

The exact text of the pinentry-X failure error is: Passphrase too long (try 2 of 3)

If you re-enter the correct passphrase again (try 2), the user is never
given try 3, and the encryption/sending of the message fails.

I've been using Enigmail for years and manage many email accounts. I
prefer to use very lengthy passphrases to protect each of my GnuPG
Keys. I define a lengthy passphrase as one which exceeds 100
characters, or ~600+ Bits.

Since I need to manage many long and complex passphrases, I use KeePass2
and its Auto-Type feature.

So here is what I know:

Lengthy passphrases work flawlessly on Gentoo Hardened with KDE and

Enigmail 1.8.2 pulled from TBird's Add-Ons, since Enigmail is not
available in the Hardened repos.

As you can see on Hardened, I've got pinentry-qt4 set:

eselect pinentry list
Available pinentry binary implementations:

  [1]   pinentry-gtk-2
  [2]   pinentry-qt4 *
  [3]   pinentry-curses

Lengthy passphrases work flawlessly on Debian 8 (Jessie) with KDE

and Enigmail 1.7.2 installed from the Deb repos. IIRC, Deb 8 calls
pinentry-qt by default.

Standard length passphrases (and I know that passphrases less than 200 Bits)

work flawlessly on Fedora 22 with KDE and Enigmail 1.8.2 installed from the Fed
22 repos. On Fed 22, GnuPG 2.1.5 and 1.4.19 are installed by default.
The pinentry-qt4 version is 0.9.2.

Lengthy passphrases fail on Fed 22 with KDE and Enigmail 1.8.2

installed from the Fed 22 repos. This failure occurs under pinentry-qt,
pinentry-qt4, or pinentry-gtk.

I know gnupg Key passphrases have no practical length limitation.

IIRC, I've read that a gunpg passphrase can exceed several exabytes
in length!

On Fed 22, I've got a very simple config setup:

My gpg.conf has exactly 2 uncommented lines: one for the default
keyserver, and the other for my default key.

My gpg-agent.conf is very similar to my Deb and Gentoo files:

default-cache-ttl 600
max-cache-ttl 6000

When left to default on Fed 22, pinentry-qt is called, and fails.
However, if you add:

pinentry-program /usr/bin/pinentry-qt4

to gpg-agent.conf, the same failure occurs (and also with gtk).

Using 'no-grab' on Fed 22 also generates it own set of very bad security
copypasta problems, even though no-grab works well on Deb and Gentoo. However,
that is a separate issue. Just using a right-click Keepass Auto-type,
with no-grab disabled is sufficient on Fed 22.

I have already made the Enigmail dev aware of this aware of this issue,

and his input was:

'Thanks for the heads up. However what you report is clearly an issue
with GnuPG / gpg-agent and pinentry. Enigmail has no role in this game
other than telling GnuPG to perform a particular action (and possibly
with a particular key). Enigmail does not get to see the passphrase at
all; querying of the passphrase is done by gpg-agent, and that would be
the culprit for the bug.'

In summary, I wanted to bring this lengthy passphrase failure issue to
your attention as it will impact some percentage of your user base
(although probably a small percentage). However, those impacted are
also more likely to be among gnupg's power users.

I don't know what changed to cause this problem, but it seems unlikely
to have anything to do with Enigmail or Pinentry since I know the current
versions of those programs handle lengthy passphrases perfectly on other OSes.

If you need more information from me, or have things you want me to test,
just let me know.

Thank You for all the work you do to keep us safe!

Details

Version: 2.1.5

Related Objects

Mentioned In: T3254: Decide which password limit to use and consistently use that limitation
Mentioned Here: rG348a6ebb6352: agent: Raise the maximum password length. Don't hard code it.
T2048: KGpg Fails to Autostart on Fedora 22 with KDE Despite 'Start KGpg automatically at login' Being Selected

Event Timeline

SlipperyCow set Version to GnuPG 2.1.5.Jul 11 2015, 6:45 AM

SlipperyCow added projects: gnupg, Bug Report.

SlipperyCow added a subscriber: SlipperyCow.

Thanks for your detailed bug report. If I've understood correctly, the long
password problem only occurs on Fedora 22 and not on other systems that you've
tried.

Can you please provide me with a bit more information. Please take enigmail
out of the loop by running:

  echo | gpg -s >/dev/null

and

  echo | gpg2 -s >/dev/null

(assuming gpg and gpg2 are different binaries, which is normally the case).

Then, please tell me the OS, the version of gpg (gpg --version), the version of
pinentry (pinentry --version) and whether you got the error. I'm primarily
interested in Fedora 22, since this is where you observe the error.

Thanks for your help.

I just tried using the Fedora 22 live cd, but it causes a kernel panic when
booting under qemu. I don't know what the problem is and don't have time right
now to debug it or install a full Fedora system. As such, I'd appreciate any
help that you can give. Thanks!

SlipperyCow renamed this task from Pinentry Failng with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE when using lengthy passphrases to Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE when using lengthy passphrases.Jul 16 2015, 4:16 AM

SlipperyCow renamed this task from Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE when using lengthy passphrases to Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE *only* when using lengthy passphrases.Jul 16 2015, 4:40 AM

Hi Neal,

First, thanks for your follow-up. I believe you have understood the problem I
described correctly.

All this information was generated while using Fedora 22.

Per your requests:

I needed to change echo | gpg -s >/dev/null to echo | gpg -su KeyID >/dev/null
to force the use of a Key with a long passphrase.

The result of that test is a success, and in this case I was using a passphrase
which is greater than 700 Bits. Direct copypasta (not Auto-Type) from Keepass
into the terminal, works.

Furthermore, I know gpg is working correctly with long passphrases because, as a
generic example, I can sign and encrypt a file with KeyID#23 for user KeyID#37
and then, decrypt that file with KeyID#37. Therefore, a command like this also
succeeds:

gpg -seu KeyID#23 -r KeyID#37 foo.txt

Both KeyIDs are protected by long passphrases.

Now, moving onto gpg2. As above, I needed to modify echo | gpg2 -s >/dev/null to
echo | gpg2 -su KeyID >/dev/null to force the use of a Key with a long passphrase.

The command, echo | gpg2 -su KeyID >/dev/null, fails on Fedora 22 using pinentry-qt4
in the exact way I originally described. When the command is entered, the pinentry
pop-up, passphrase entry window is generated on your display.

In this case, you must use Keepass's right-click, Auto-Type option/command
(copypasta fails) for the pertinent Key. When Auto-Type completes typing
the 700+ Bit passphrase, tabs (once), and then 'hits' Enter, the error generated in
the pop-up window is:

Passphrase too long (try 2 of 3)

If you try to use Auto-Type a second time, the pop-up disappears, but nothing
happens (a 'visually silent' fail, if you will).

However, following each of these Auto-Type entry failures, the command line
now shows something pinentry does not:

gpg: signing failed: No passphrase given
gpg: signing failed: No passphrase given

This is quite an interesting error message, given that I watched the passphrase
being Auto-Typed, and entered, twice. Again, I've been using Auto-Type for years.

Neal, you also asked for these bits. On my Fedora 22 box, I have:

gpg --version: gpg (GnuPG) 1.4.19
gpg2 --version: gpg (GnuPG) 2.1.5 + libgcrypt 1.6.3
pinentry --version: pinentry-qt4 (pinentry) 0.9.2

Hopefully, this helps you narrow down where, and how, this failure is occurring.

As always, let me know if you need something else.

P.S. I'll fire an email to you with my Public Key in case you have any minor,
or quick, requests. However, of course, I'll need to change OSes first, because
I cannot encrypt any emails with Keys protected by long passphrases on Fed 22! ;-)

One more question: on the other systems that do work with long passphrases, are
you also using 2.1.5? Thanks.

Hi Neal,

On Gentoo Hardened, 2.0.26 + libgcrypt 1.5.4 is installed.

On Debian 8, 2.0.26 + libgcrypt 1.6.3 is installed.

GnuPG works on both of those operating systems when using long passphrases.

Did something change in the 2.1.5 code that impacted, or restricted, acceptable
passphrase length?

Thanks!

Hi,

At Thu, 16 Jul 2015 11:52:04 +0000,
SlipperyCow via BTS wrote:

SlipperyCow <slipperycow@privatdemail.net> added the comment:

Hi Neal,

On Gentoo Hardened, 2.0.26 + libgcrypt 1.5.4 is installed.

On Debian 8, 2.0.26 + libgcrypt 1.6.3 is installed.

GnuPG works on both of those operating systems when using long passphrases.

Did something change in the 2.1.5 code that impacted, or restricted, acceptable
passphrase length?

It sounds like it is a bug in 2.1.x. I'll investigate. I hope it is
obvious that the bug is not intentional.

Neal

Hi Neal,

Glad to learn you will be investigating.

Yes, it does seem obvious that intentionally rolling out 2.1-x with less
capability than 2.0-x makes little sense.

BTW: If you remove my email address from your most recent post, from a privacy
perspective, I won't mind. ;P

Cheers

Hi Neal,

While I'm not keen on intentionally causing you (or others) to have to perform
extra work, you might want to have a quick look at another issue potentially
involving 2.1.15 (only), and which I just filed:

T2048

My guess is that they are unrelated failures, which is why I created the new issue.

I only mention this other issue in case the ultimate root cause is, or turns out
to be, inextricably linked, or intertwined, with this Issue2038.

As always, kindest regards.

Hi,

I just tried:

  echo | gpg2 -s > /dev/null

using an 80 character password. This correctly signed the message. I used
GnuPG from git and pinentry from git. I configured gpg-agent to use
pinentry-qt4. So unfortunately, I can't reproduce the problem (yet).

Neal

To be clear: pinentry passes the passphrase back to GPG Agent using Assuan.
Assuan has a line limit length of 1000 characters. This means that passwords
upto 998 characters should be okay. Can you please tell me how many characters
long your password is? Thanks!

Neal: Pinentry-qt Uses a hardcoded magic Number of 256 characters
(pinentrydialog.cpp:140)

So with pinentry-qt you can't enter longer passphrases. I don't know why. Maybe
we want to change that?

The Assuan protocol limits the length to 998 characters. But, sure,
we can up the limit.

FWIW, I don't think the password in question exceeds either the
theoretical limit or the current practical limit. The bug must be
someplace else.

I do not see a reason to support useless long passphrases.

Normal humans are not able to remember such a long passphrase. If you want to
use a really stong passphrase you have to use a generated anyway. A generated
passphrase however has an easy to compute entropy and thus a 256 byte limit is
more than sufficent for a 32 byte (=256 bit) key.

neal: We can't easily lift the 998 byte limit. Also note that a passphrase
character might in theorie be up to 6 byte.

Werner: I think there is a bit of confusion. The suggestion is not to up the
998 character lmiit, but the pinentry-qt limit of 256. Rereading my note that
was probably not clear.

Also, the long password that SlipperyCow is talking about is about 100 characters.

Despite that the use of these 100 characters is not a proper way to protect a
private key, they may exceed the 255 characters if most of them are non-ASCII
and non-Latin-1. Most characters of the latter are endoded with just 2 bytes in
UTF-8.

At Fri, 31 Jul 2015 10:27:04 +0000,
Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

Despite that the use of these 100 characters is not a proper way to protect a
private key, they may exceed the 255 characters if most of them are non-ASCII
and non-Latin-1. Most characters of the latter are endoded with just 2 bytes in
UTF-8.

This reply doesn't contain a call for action. What are you concretely
recommending?

Also, I'm not sure why you think 100 characters is too many. Let's
say you want 128-bits of entropy and are using the diceware word list.
There about 12.5 of entropy per word, so you need 10 words. If each
word is about 7 characters long and we space separate the words,
that's about 80 characters. A more readable word list might contain
fewer words, say a 1000, but have the same average length raising the
character count to 100. These passwords are perfectly reasonable,
AFAIK. Do you disagree?

Because the majority of humans are not able to remember such a passphrase and
thus most will use some passphrase manager to remember that. In that case you
can use a full-entropy key directly (cf. T2038 (wk on Jul 30 2015, 07:59 AM / Roundup)).

agent/findkey.c:unprotect (for instance) imposes a password limit of 99 bytes
(pi->max_length = 100). I've raised this limit to 255 bytes in commit 348a6eb.
I'd appreciate it if you could test this and confirm that this fix is
sufficient. Note: we are not going to raise the limit about 256 bytes.

If you can't manage to fit 128-bits of entropy in 256 bytes, then you need to
fix your passphrase generation scheme.

neal added a project: Restricted Project.Aug 24 2015, 4:18 PM

Fixed in 2.1.8.

• werner closed this task as Resolved.Sep 21 2015, 8:50 AM

• werner claimed this task.

Hi Werner,

Fixed in 2.1.8 INDEED!!

I know this to be true as the 'Passphrase too long' error still appears when
running gpg2 on a fully updated Fed 22 system. The latest GnuPG(2) package in
Fedora's repos is: gnupg2-2.1.7-1.fc22.x86_64. When that package is installed:

gpg2 --version

of course, reports: gpg (GnuPG) 2.1.7.

As I originally noted in this bug report, this 'Passphrase too long' error only
appears on my Fedora 22 systems. Therefore, Fed 22 is the operating system I
used to install the required libraries and then compile 2.1.8 from its source
code.

Following appropriate modifications to my ~/.bash_profile

gpg2 --version

now correctly reports: gpg (GnuPG) 2.1.8

Now when running TBird, Enigmail and Keepass2, gpg2 and pinetry-qt4 can now
accept very lengthy passphrases, flawlessly!

I don't know what the maximum passphrase insertion length limit is from a
Keepass2 Auto-Type perspective, but I am happy to report that GnuPG 2.1.8 can
easily handle Keepass2 generated passphrases significantly longer than 750 Bits.

Absolutely great work done here Werner!

Thank you very much Werner and Neal. I very much appreciate your sustained
attention to this now SOLVED matter.

BTW: If either of you have further input, or queries, on the passphrase entropy
topic, I would be happy to discuss these matters with Dominik Reichl who is the
developer behind Keepass - and all of it variants. I have contacted Dominik on
several Keepass issues. He is both highly intelligent and responsive.

Given that Keepass has a large user base across many operating systems, perhaps
a frank discussion, and optimization, of lengthy GnuPG passphrases in general
would be beneficial to a large population of security minded Windows and Linux
users.

Thanks for reporting back and thanks to Neal for cleaning up the passphrase limits.

Please continue a discussion about KeePass at gnupg-users.

• werner closed this task as Resolved.Sep 28 2015, 11:17 AM

• werner mentioned this in T3254: Decide which password limit to use and consistently use that limitation.Jul 5 2017, 11:45 AM

Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE *only* when using lengthy passphrasesClosed, ResolvedPublicActions

Description

Details

Related Objects

Event Timeline

Pinentry Failing with 'Passphrase too long (try 2 of 3)' on Fedora 22 with KDE only when using lengthy passphrases
Closed, ResolvedPublic
Actions