Split GPG: Enable Hidden Recipients

[Eric Duncan]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

QubesOS R3.2 - up to date.

It seems it was a conscience decision to explicitly block hidden recipients from the 

Split GPG feature.

I have configured Split GPG and immediately hit this road block that qubes-gpg-client 

does not support hidden recipients in any form.

This is true for any encrypting or decrypting functionality.

    $ qubes-gpg-client -esa -R KEYID

    qubes-gpg-client: invalid option -- 'R'

^- most other switches are enabled, but -R was not.  lowercase -r works, to include the KEYID.

    $ qubes-gpg-client < pgp-encoded-text-addressed-to-hidden-recipient.asc

    gpg: encrypted with RSA key, ID 00000000

    gpg: decryption failed: No secret key

^- this would indicate that it only tries one key, the 00000000

I also tried the qubes-gpg-client-wrapper with the same results.

Could we open a discussion to possibly supporting this in the future?

I'd imagine it was a decision to require a specific KEYID to decrypt-from/encrypt-to possibly 

because of the way the qubes utils were written within the "vault" VM?  So

instead of iterating over all -K keys with secrets, it instead explicitly tries to access that

one KEYID to encrypt/decrypt.

Could we instead, on the server/vault VM side:

* look for KEYID 00000000 (which indicates a hidden recipient)

* query for all keys with secrets (-K)

* iterate over each, trying each key until decoding succeeds

This is how CLI and Thunderbird worked with multiple pgp keys local to that VM, before

I setup Split GPG.

Thanks!

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAllvezoACgkQ1HXhRIZm

5iZ56g//cKb8UyfAgSztJBAPuT5dfVpxs2uiYsDWcakRkdUmfRHVnN1TAJSmzplu

5FItsQn7vV2/h4C84da8gel9AHGu9mo3eMWfSb4LFQ/spsW7/6F1kMifajrJnZ7x

uMmqd3fCZ1XNcmExGjTlLSqXk4mLymuSd1RKWWp7sanl/IFCAaNqlXXyQPx4bkVp

EHbsdCJCj411h4DkjFR2AA6MtQZWT5brjHmotr/Jm4yTuV9fLGGiTeMk9M6v/Ubq

VP9tseLm47xdYZBFPLqElz04fCs9ByQ0Wl7/7/r7a7bVB8nV7yA0M0vh5JhIkKky

3OvTAvKdHkSC/EGIGgBCp/B3PreFWTPKIC9RYJhdpKy4vm6xokO2o5fN03nYpCCP

Sgk9F/zSgChy7mzIFFsopWXMQEI5/JWkCO7uM9UwF/NugEttLVUPOpThGEMAP/oZ

G0cg4Bhz1MbhWD2/6w0hCtnaeOT2xN8N3TxAy+0dcXO7uB4rhRFCKoZ0mHBDIpZQ

4zUSTwWXAW0029QEbSb9FaQTjtXHPfmThc3sIu+7g+nU97LAmQBD/OUu+jNnKVb0

1qQGOFHDE+6Tk4gUl11sBWCL3aG5ROHOOSabqzZagD1X9/VEIYfiqA+TIQI2lCfA

N7JWCK0Huhr08uEC93VKwho1DGB9ihM8zx5NtL7lrxg9Vt2uCqk=

=mEwI

-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jul 19, 2017 at 08:31:42AM -0700, Eric Duncan wrote:
> QubesOS R3.2 - up to date.
>
> It seems it was a conscience decision to explicitly block hidden recipients
> from the
> Split GPG feature.

Actually, not. It's a bug.

> I have configured Split GPG and immediately hit this road block that
> qubes-gpg-client
> does not support hidden recipients in any form.
>
> This is true for any encrypting or decrypting functionality.
>
> $ qubes-gpg-client -esa -R KEYID
> qubes-gpg-client: invalid option -- 'R'
>
> ^- most other switches are enabled, but -R was not. lowercase -r works, to
> include the KEYID.

And also --hidden-recipient works...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZcpl1AAoJENuP0xzK19cs290H/0dmPcgGvvTBex7aM4APoL6n
wKXL+1lvxnJeFIDgmx10VcwI4oGyYDNbt3q64sW1v58CmObLEnfCfoD65UsEW0xm
yMebTYyS4uf+ckez2jppzYbjgVCNJ1sWz+8UgE/dkCvA09EkX52UQm7MHXSw2Oc/
1tOOu5oPER9aINg87kJPFKCO7D/o5bgT94stRSGw8qdnYKG57NaSQOaGn5Ib1H3b
ZCdfyBMUTrBuIuBpZvFyPSMXzLXU7F/G5bPZ2C0QX/2mHTd9xud9wMq/cSiRxKms
QMsHatPzHFjCs7K7J7IDO3VQEGmn6i9XRUg2C73aT/sISoUxFZT+JJj7ItTEww0=
=lxKs
-----END PGP SIGNATURE-----

[Eric Duncan]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

On Fri, Jul 21, 2017 at 8:16 PM Marek Marczykowski-Górecki wrote:

> 

> >On Wed, Jul 19, 2017 at 08:31:42AM -0700, Eric Duncan wrote:

> > This is true for any encrypting or decrypting functionality.

> >

> >     $ qubes-gpg-client -esa -R KEYID

> >     qubes-gpg-client: invalid option -- 'R'

> >

> > ^- most other switches are enabled, but -R was not.  

> > lowercase -r works, to include the KEYID.

> 

> And also --hidden-recipient works...

> 

Ok, a bug that Encrypting only works with long 

form (--hidden-recipient) and not short form (-R).

But... You cannot decrypt a message with hidden recipients 

as my original message outlined (repeated below):

    $ qubes-gpg-client < addressed-to-hidden-recipient.asc

    gpg: encrypted with RSA key, ID 00000000

    gpg: decryption failed: No secret key

Perhaps there's a special parameter we should be passing to

decrypt a message with hidden recipients?  

Proposed solution:

Could we instead, on the server/vault VM side:

 * look for KEYID 00000000 (indicates a hidden recipient)

 * query for all keys with secrets (-K)

 * iterate over each, trying each key until decoding succeeds

I suspect that the utilities only look for a single key, 

which defaults to 00000000 when there is none, and tries to

lookup that KEYID 00000000 only.

Other software, like gpg2 itself and Thunderbird, will

iterate over all -K keys (as long as you don't set any

specific one in ~/.gnupg/gpg.conf).

Thanks,

Eric

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAll0l9sACgkQ1HXhRIZm

5iaO1Q/+KHrGQ0rkb0DwdWc27hXPv5SWWBgUIsYnWDEmTERWsICIbGFN1rWPy28y

+mhbhwhLeoYbZbkVJf8evoKU7OOVfUcPi8czC7Vad6TjWg1TLDrHj+XR7YzPga7d

ViBeST0EZPPErFNobGnsNY6ik+c9TF5BOfe+0St/vFJ5doYtAOV4Ddy8Jo8QI4/9

FkJH9M2ePzawxhMwA5k253CI6uEUbZv/A+bkFX+LMaGYp13EFOUBqe9K7XHJMk6d

fb4D49wEk2xA7ICEbbw+3rXFV0MH2AMrs2Mmx5oXWssTlOg6gD/Wt5FpL6oq3n5M

LcaOCbDMWOgKKrjwaHHV1rmUclO7Gh6VORo/dQ3ju8vN97nAAy44dXNDdibCCaph

AewZ07YWrY6DM4ibYyhbX5ZGr0IWyHdEzWmBHnuq6tSA+KL3WZ0F6/5SmV4j2sIB

6k4RtxRpXayFONU1xUkglxcEUAmgufvBT1bLg51tJIa6B1N4PsFLLxZUw1oDWlQ6

1nsP6G7NNN9PFCAwwgbv+sHQkj7IzhSJh5ikeOp1H+tXg8835i7XeGme9jEHDKWS

IqyTxl4f0o76KQve7aK6GcCZsXry+CZgWetVx93L48EdNxWIgkFCCaSP5Npl4BR3

16rr64nvfJXM4MetcvG/oZU3Ybk+pdhIrVmML1j6nko56bb/2hA=

=qhGP

-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Jul 23, 2017 at 12:36:39PM +0000, Eric Duncan wrote:
> On Fri, Jul 21, 2017 at 8:16 PM Marek Marczykowski-Górecki wrote:
> >
> > >On Wed, Jul 19, 2017 at 08:31:42AM -0700, Eric Duncan wrote:
> > > This is true for any encrypting or decrypting functionality.
> > >
> > > $ qubes-gpg-client -esa -R KEYID
> > > qubes-gpg-client: invalid option -- 'R'
> > >
> > > ^- most other switches are enabled, but -R was not.
> > > lowercase -r works, to include the KEYID.
> >
> > And also --hidden-recipient works...
> >
>
> Ok, a bug that Encrypting only works with long
> form (--hidden-recipient) and not short form (-R).
>
>
> But... You cannot decrypt a message with hidden recipients
> as my original message outlined (repeated below):
>
> $ qubes-gpg-client < addressed-to-hidden-recipient.asc
> gpg: encrypted with RSA key, ID 00000000
> gpg: decryption failed: No secret key
>
> Perhaps there's a special parameter we should be passing to
> decrypt a message with hidden recipients?
>
> Proposed solution:
>
> Could we instead, on the server/vault VM side:
>
> * look for KEYID 00000000 (indicates a hidden recipient)
> * query for all keys with secrets (-K)
> * iterate over each, trying each key until decoding succeeds

In theory --try-all-secrets does exactly this, but apparently it is
broken (in addition to be rejected by split gpg):

http://compgroups.net/comp.security.pgp.discuss/gnupg-unable-to-decrypt-my-own-mess/3027666

On the other hand, --try-secret-key do work with plain gpg2. It is
filtered out by split gpg too (can be allowed, same as -R), but for now
putting "try-secret-key xxxxx" into .gnupg/gpg.conf in vault VM does the
trick.

> I suspect that the utilities only look for a single key,
> which defaults to 00000000 when there is none, and tries to
> lookup that KEYID 00000000 only.
>
> Other software, like gpg2 itself and Thunderbird, will
> iterate over all -K keys (as long as you don't set any
> specific one in ~/.gnupg/gpg.conf).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZdeiEAAoJENuP0xzK19csU3UH/0rcwPawcjmwnvF09X3znFVD
5Ndd4a9CdVrOL+0uBOFdy6EZli7Zz784cjsWDmnEjO/6C5boUBl6tA6Oy9nwglfg
+SUBb0ocxSaMhHapgvae3GL4whADxIXOUI0S7b6MyP2nJCLWzTka6w/4FDyU+8KG
LsfaqoIsGth18nCp06TxaBGtn+FC+M3MmD9EERITZZ7cDoDeYYzbcfDnzROiug1a
da7HOCQ0Tj8yuHs3tzaDLnnByf78VUjz2GDvvLKiXW7EZtIcIbRKPWCN359WMTt5
vs0dYxe/dwGbA96o9m2Hvp900+1pwx13paqBAfEO7bvTv9QtaatWgu3xMXVxWb8=
=yA0p
-----END PGP SIGNATURE-----

[Eric Duncan]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Thank you!  "try-secret-key XXXX" added to ~/.gnupg/gpg.conf did work for 

all of my private keys (it finds various ones).

I reviewed the code and it the server code does not seem to care about the 

keyid.

I have forked and changed the code to allow -R and --try-secret-key on

the CLI, along with --try-all-secrets and --skip-hidden-recipients.

https://github.com/eduncan911/qubes-app-linux-split-gpg/pull/1

I am not a C++ expert though and not sure how to compile and test this

without messing up my current installation.  

Is there a way I can just build the qubes-pgp-client binary and 

place that in my vault?  (backing up my current one first)

Thank you!

Eric

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAll2jykACgkQ1HXhRIZm

5iaH8A//Y009pSgSTvxs4KEy1G7PkQSnLjy9/B4m9kgCjDgWkDT3vGAdnuhsoFBE

vBT1xIKJ0d4+d6GRfJNkcYppXKJJPTULS/3UbFmKy7ojHNDg4nAu/KLtbVYA89Ka

SfBdSzOPI3ZPnmnKmRsXr7mtFCiTK5Gx/4Fp69y5uvFwqgqWHp+d5Zbm7sLpk9AK

lcHdjLLxN5b1JaYCwSxtGvc+eMqnpK3lv2ajUFCJqCh6FpUL8Nt+NAvYWrHmMwLX

+GezXmq6wmlf+zj4GTlDwSM8tidBoaWUHdHruLgLVvpsRY9XgcB02RNBeHuq/tdr

IYTeV+kiN9A2udNdm/1PkngmuZjegcK4Y+wYcfUAWzzuT+4uADwbHISsT2h8dKXX

W56fwuotw5LLj5q4TRyPmDtXCSJGCh+/oD1bx6h+u3pclKL3D93fTMiCcuwyJtNs

r0tIDUezC4WUMmzKE97ylOwRqAEv5kDZ8JobFRjJTUzHL2kmfGpjz7DalIfevCuB

ksKRp5MXt01BmqjFDQjm7w/fSjB5Jn/JbZFQusbhmiLUm4x8LZCRi1yhWz9cc1B3

yke/bisKEupvRldXw2hXn1yHqLPrZLaiifOy103wrB8S7gt0Axu/wqObXCDiTwPV

XkfEtz8R4TzuJGsciAnv7DYIOp30jQdgILWEAo74AHHbXOjfiSY=

=ZBfm

-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Mon, Jul 24, 2017 at 8:22 PM, Eric Duncan <edunc...@gmail.com> wrote:
> I am not a C++ expert though and not sure how to compile and test this
> without messing up my current installation.
>
> Is there a way I can just build the qubes-pgp-client binary and
> place that in my vault? (backing up my current one first)

You can use qubes-builder [1] to `make app-linux-split-gpg`, which
will produce proper packages (in
qubes-builder/qubes-src/app-linux-split-gpg/pkgs/fc*/x86_64/*.rpm)
which you can install in whichever VM you'd like and test with. This
guarantees that exactly the changes you expect are the changes you are
indeed testing.

[1]: https://www.qubes-os.org/doc/qubes-builder/

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jul 24, 2017 at 05:22:31PM -0700, Eric Duncan wrote:
> Thank you! "try-secret-key XXXX" added to ~/.gnupg/gpg.conf did work for
> all of my private keys (it finds various ones).
>
> I reviewed the code and it the server code does not seem to care about the
> keyid.
>
> I have forked and changed the code to allow -R and --try-secret-key on
> the CLI, along with --try-all-secrets and --skip-hidden-recipients.
>
> https://github.com/eduncan911/qubes-app-linux-split-gpg/pull/1

I think a race condition have happened:
https://github.com/QubesOS/qubes-app-linux-split-gpg/pull/10

> I am not a C++ expert though and not sure how to compile and test this
> without messing up my current installation.
>
> Is there a way I can just build the qubes-pgp-client binary and
> place that in my vault? (backing up my current one first)
>
> Thank you!
> Eric
>
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZdqyZAAoJENuP0xzK19csQNIH/0YzaUEr3MjeZAx72NS1KIvt
JOyV/v1Y7juS+hTtfnBSiwt8nLrGGOZbc8EogCW7q2K/xFIV4XDzTrfjnziZQGrs
j26j1z6yC39tDa1zBDlB1eoN8P1nUhY2BGakxHGh2iEjAFG+xQAJ4NyO9YYSFQ9L
N9gCAHh48o//12px87SeZuBHN3wIyb1555FI4UE/3k2ha9yselt4bA0IrQeh/vXd
fMXO0QaJf7HrJrBPljlMNd2999eRgHKoN4A1D7giLAmwd3Tydkgl+kr3FMKsBexX
w47kSlJZbGeDfDuzzYDs5YaksFuKx+Vb8ECydhAYjQv4A/yj3s9u5SbwrD3MhXo=
=vJ1t
-----END PGP SIGNATURE-----