Page MenuHome GnuPG

ftiede (ftiede)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 27 2017, 4:48 PM (365 w, 3 d)
Availability
Available

Recent Activity

Oct 25 2016

ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

Figuring out required iteration counts is not necessary as the only operation
performed while GNUPGHOME is still unwritable is decryption.

--passphrase-fd 0 with --pinentry-mode loopback does indeed work without the
agent but requires a potentially unsafe password entry to be programmed around
the call which is also probably not the best option. --pinentry-mode ask
requires the agent again.

Oct 25 2016, 7:52 PM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

gpgconf --create-socketdir made no difference, the agent still has to be started
manually, and honestly, even the gpgconf step is one step more than I think
absolutely necessary to make it work.

Oct 25 2016, 5:37 PM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

To be absolutely precise:

  1. Log in as a test user with an existing ~/.gnupg and some (empty) keyrings
  2. Lock write access to ~/.gnupg with 'chmod 0500 ~/.gnupg'
  3. Create /run/user/<id> as root, chown and chmod it to be owned by that user

with write permission.

  1. Run 'gpg -q -d <symmetrically encrypted file>' as that user (which is

precisely what needs to work at this point. - It does _not_ work

  1. Run 'gpg-agent --daemon' as that user.
  2. Retry step 4. - Now it _does_ work.

So: gpg-agent can figure out to put its socket into /run/user/$(id -u) and
subsequent calls to gpg will find the agent socket there. But calling gpg
without starting the agent manually does not perform this magic.

Oct 25 2016, 3:06 PM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

I've tried - unfortunately the gpg-binary doesn't try that on its own, so i
still have to extend the pre-fs-mount-magic happening during boot, but at least
it spares me thinking about how to tell the agent where to create its socket.
Modifying configs wouldn't be a good idea here, IMHO, as usually user-created
configs are there for a reason.

Oct 25 2016, 2:57 PM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

What about cases where a local (/root/.gnupg) config is required to decrypt the
files?
I honestly don't know about SmartCards and stuff, but doesn't setting GNUPGHOME
also hide other GnuPG configuration?

Oct 25 2016, 11:25 AM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

I'm working on a solution for this problem, but since gpg-agent does now ignore
--no-use-standard-socket, how do I tell the agent daemon on commandline where to
create its socket?

Oct 25 2016, 11:07 AM · gnupg, Feature Request

Oct 19 2016

ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

Ah, no. I don't _want_ to use pinentry, it's just what happens with GnuPG-2.0,
given that pinentry is installed and GnuPG is able to find it at that point. I
can very well live with the basic (blind) prompt from GnuPG-1.x (I think
pinentry's habit of displaying * characters for each passphrase character typed
is also _not_ an improvement). So, I'm using pinentry, because I don't have the
choice not to do so.

And, honestly, I find changing an application's behaviour such way it doesn't
work anymore like it did for years without even an option to get at least part
of the old behaviour back - I'm talking _only_ symmetric _de_cryption here, for
everything else I'm fine with the agent - is not really an "improvement".

I understand there has been considerable time invested in discussing and
evaluating options here, but this decision renders GnuPG worthless for a step of
security I've had and now I need to look up alternatives, with the tradeoff of
them being probably less thoroughly scrutinized, esp. in their implementation of
the cryptography part. Also not an "improvement".

Oct 19 2016, 5:13 PM · gnupg, Feature Request
ftiede added a comment to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.

pinentry is used to enter the passphrase, during bootup pinentry-curses is in
use, after the GUI has started, a graphical version is used.

The major problem is that the gpg-agent tries to write to the root filesystem
when gpg is called to supply the key-material to LUKS. This fails with modern
GnuPG, stable GnuPG doesn't have this issue.

I am using Gentoo Linux AMD64 stable as operating system which stabilised
gnupg-2.1.15 a few days ago for general use.
In my LUKS setup GnuPG is used to symmetrically encrypt/decrypt a file
consisting the random data which in turn is the key for the LUKS partition in
question. So GnuPG does the part of requiring a secret for a required file to
get to the data in question, like a PIN to a credit card, both are worthless
without the other.

The process is roughly this:
The kernel starts and init (no systemd) proceeds to one step prior to checking
all to-be-mounted filesystems.
Now one or more partitions are found to be LUKS-encrypted with gpg-encrypted
keyfiles.
For each partition with such a gpg-encrypted keyfile gpg is called to decrypt
the keyfile and pass it to cryptsetup.
After all partitions have either been decrypted, the regular filesystem checks
are performed and filesystems are mounted as specified by /etc/fstab.

The crucial part is that up to the last step in the process the root filesystem
is still read-only and the agent's default location for the socket
(/root/.gnupg) doesn't allow creation of the socket.

Since my disk encryption relies on being able to enter the keyfile's passphrase
prior to being able to write to the root filesystem, I'm currently stuck with
GnuPG-2.0, which doesn't need its agent (contrary to its man-page, btw).

Oct 19 2016, 3:23 PM · gnupg, Feature Request
ftiede set Version to 2.1.15 on T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount.
Oct 19 2016, 11:59 AM · gnupg, Feature Request
ftiede added projects to T2809: Agent required for symmetric operation causes encrypted partitions to fail to mount: Feature Request, gnupg.
Oct 19 2016, 11:59 AM · gnupg, Feature Request