Re: Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 03/12/16 18:21, MFPA wrote:
> If the recipients are hidden, doesn't GnuPG first try the key set
> with --default-key, followed by any keys set with --try-secret-key?

Hey, I didn't know that! Thanks!

> That is sufficient for your smartcard and known-hidden-key examples,
> but not for Caro's situation.

The smartcard case seems to work anyway, in a test it seems to be tried
only after the on-disk keys.

It is indeed sufficient for the known-hidden-key example, but not for
the case with known recipients. I just tried, if there are two secret
keys that are encrypted to and they are named, it will try them in
order, no matter --default-key. Perhaps --default-key could be extended
to always try that first?

> And I don't think --try-secret-key can be followed by
> --skip-hidden-recipients to mean "try this/these key(s) and if they
> won't decrypt it, give up on hidden recipients".

I think in fact --default-key is enough... I just tried with GnuPG 2.1,
and it only tried that secret key. Any additional keys need to be added
via --try-secret-key or --try-all-secrets. So it seems to complete solve
the hidden recipient problem, only the known multiple recipients problem
remains.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Implications of a common private keys directory in 2.1

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Saturday 3 December 2016 at 2:35:09 PM, in
, Peter
Lebbing wrote:-


> An option --only-try-secret  would solve both
> (your software
> would know which to try for a given nym account), but
> such an option is
> not available. You could try to make the case that
> such an option would
> be a good idea to implement. It would serve more
> scenarios than just
> yours. For instance, people with smartcards could use
> it when a message
> is also encrypted to an on-disk key, when they can't
> or don't want to
> insert their smartcard. And if somebody knows which
> key is the hidden
> recipient, but has multiple secret keys, it would
> save them declining
> all the dialogs for the keys that aren't the recipient.

If the recipients are hidden, doesn't GnuPG first try the key set with
- --default-key, followed by any keys set with --try-secret-key? That is
sufficient for your smartcard and known-hidden-key examples, but not
for Caro's situation. And I don't think --try-secret-key can be
followed by --skip-hidden-recipients to mean "try this/these key(s)
and if they won't decrypt it, give up on hidden recipients".


- --
Best regards

MFPA  

Only dead fish go with the flow
-BEGIN PGP SIGNATURE-

iL4EARYKAGYFAlhC/zNfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3
MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSWUQEAirYk4e7jhPN6SMo2LaMOof8A
efmDpGFFhAcT06ognGQBAL+PfFELjcOKnuFrWI+kiHTKOdoffBDMddy1VDhaTdEJ
iQF8BAEBCgBmBQJYQv9BXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwT0sIALLFwBD+2X00uYv6TxX6lcez
kv88jkOdlYZJ0iAKnKmwYXESi++iT9tvCyX4acJ6mytLxG/aGoGYTcyan68MaAMT
O2e88RYlPZyA6ZQD1TkJy6Xr5OdBngJcc35SOq/3Ay09hLyVEV/26Ue1FDY5bdS3
8u39+oQYf3cGQcu4ZRaWbphePqnXK00jlFqtqkvqrxig3gGGgvfeeImVpMY/d16D
UZbg+xJO4JezjR2UJqQxvnqDECW+BE32k67iFVwE8JazQcsZUSHBxWIiSuw8WeKP
rAzKinXU3RUkqQykqB6PkCaLqKxqyRPWleTsWv0PlWjlwWY7agZd5Ws1b4Cq/CY=
=w7RF
-END PGP SIGNATURE-


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

Re: gpgme 1.8 build failure (again)

[Robert J. Hansen]

> I am not sure whether this was helpful but I wrote

That was the one I needed.  :)  For some reason, something in the GPGME
build requires _DARWIN_C_SOURCE to be set.

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

Re: Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 25/11/16 00:03, Carola Grunwald wrote:
> Let's just say I hold two nym accounts at different nym servers
> 
> https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers

Right, you're also hiding the proxy server. So if the proxy used the
same public key for multiple nym accounts, that would link them up as
all using the same proxy. That makes sense, I didn't know you were also
hiding the proxy you're building.

I think it would be better to implement the proxy on the client machine,
instead of on a server machine. That way, all secrets stay on the client
machine, and you could still use regular e-mail clients, just with an
IMAP server at the localhost. This seems *so* much better than a server
which can decrypt all client data! But let's take for granted that you
want to do it as you want to do it, on a server.

I doubt you would run into any trouble just using a separate homedir per
user account. I don't think agents take a lot of resources. When the
user logs out, you make the agent quit as well. You could remove its
socket; it will notice and quit within a short while. There's also the
Assuan command KILLAGENT which does what it says on the tin. I don't
know what interface to GnuPG you were planning to use, but I would
strongly suggest GPGME; it's the official way of programmatically using
GnuPG. That said, I don't know if GPGME offers a way to issue the
KILLAGENT command.

A separate homedir per user means you get the separation you wanted.

I don't see the purpose of using the password of the user account for
encrypting the private key, though. It doesn't seem to add security and
does seem to add problems. If you're worried about seizure of the data
at rest, you could use a single server-wide passphrase to encrypt all
private keys used by GnuPG. You could use disk encryption, that seems
like an easy way out and would protect other sensitive data as well. Or
you could use a specialized pinentry implementation, that always returns
the same passphrase, which could be seeded when the server boots up.
Pinentries are easy to write.

If you really want to cut down on the number of running agents, I'd
first discuss this with the GnuPG developers. Is the agent well suited
to serve dozens, hundreds of private keys? If the design never accounted
for this possiblity, it might be horribly inefficient or expose
unexpected issues.

(You could take the middle road and serve, say, 32 clients per agent.)

However, that still presents a serious issue with private key ownership,
both in the case of multiple recipients and with --throw-keyids, which
you would not have with an agent per user.

GPGME tells you which private key was used to decrypt the message.
However, if there are multiple recipients on the same proxy and they
share an agent, GnuPG will only use the first one that succeeds. If your
proxy software would inspect the recipient and only allow the owner of
the indicated key to read the message, the other recipients wouldn't be
able to read the message, because the agent never needed to use their
key in the first place. Argh.

For hidden recipients, it would be a serious resource hog to try all
keys, and would additionally have the same problem with multiple recipients.

An option --only-try-secret  would solve both (your software
would know which to try for a given nym account), but such an option is
not available. You could try to make the case that such an option would
be a good idea to implement. It would serve more scenarios than just
yours. For instance, people with smartcards could use it when a message
is also encrypted to an on-disk key, when they can't or don't want to
insert their smartcard. And if somebody knows which key is the hidden
recipient, but has multiple secret keys, it would save them declining
all the dialogs for the keys that aren't the recipient.

You are worried about all other kinds of key management issues. I don't
think that is really so worrisome. You could simply zap the revocation
certificate already on creation, or periodically zap the contents of the
openpgp-revocs.d dir altogether, I don't think they serve much of a
purpose in your scenario. And once a user account is deleted, simply
delete the accompanying secret key (--delete-secret-keys, not
--delete-secret-and-public-key).

As long as you don't meddle with multiple public keyrings, this is just
fine. You might say multiple keyrings "without doubt have stood the test
of time in GnuPG 1.4", but I suspect this test of time is precisely what
has shown the people actually maintaining this feature that it is
riddled with hard issues.

While we're touching on that subject, if you go the single agent route,
you could just hold all public keys in one keyring. I think it's built
to be big. GnuPG 2.1 is a lot more efficient with large keyrings than
previous versions. And public data is public data, right? No need to
wall it off.

That does leave deletion of public keys, but you could do reference
counting in 

Re: private subkey not found

[zep]

Hello Werner,

Thanks for your reply

> That does not look like the standard output of gpg 2.1.15 - Please
> remove the keyid-format option from your gpg.conf.

Here is the output you requested:

sec#  rsa4096 2016-11-19 [C] [expires: 2021-11-18]
  some_hex_value
uid   [ultimate] zep 
ssb>  rsa4096 2016-11-19 [S] [expires: 2021-11-18]
ssb>  rsa4096 2016-11-19 [E] [expires: 2021-11-18]
ssb>  rsa4096 2016-11-19 [A] [expires: 2021-11-18]

sec   rsa4096 2015-04-07 [SCA] [expires: 2020-04-05]
  some_other_hex_value
uid   [ultimate] zep 
ssb   rsa4096 2015-04-07 [E] [expires: 2020-04-05]


I have two different keysets:

One offline master key and three subkeys for zep
 which are stored on a nitrokey.

Then I have one master key and one subkey for zep ,
which are not stored on a smartcard.

> Are all keyfiles in ~/.gnupg/private-keys-v1.d/ readable ?  Check the
> permissions.

Indeed, my master private key for other_m...@provider.tlp in
~/.gnupg/private-keys-v1.d/ is only a symlink to the real key, which is
on an LUKS encrypted USB drive.

I moved the symlink out of the way, and checked again using
gpg-connect-agent, keyinfo --list:

> keyinfo --list
S KEYINFO some_hex T some_hex OPENPGP.2 - - - - -

S KEYINFO some_hex D - - - P - - -

S KEYINFO some_hex T some_hex OPENPGP.2 - - - - -

S KEYINFO some_hex T some_hex OPENPGP.1 - - - - -

S KEYINFO some_hex T some_hex OPENPGP.1 - - - - -

S KEYINFO some_hex D - - - P - - -

S KEYINFO some_hex T some_hex OPENPGP.3 - - - - -

ERR 67108952 Invalid name 

Signing, Encrypting and Decryption using the first keyset (on the
nitrokey) does work. But decryption using the subkey of the second
keyset does not work.

Is it possible to have two keysets each having the same name, but a
different email address ?

E.g.

zep 
zep 

Thanks,

Cheers, zep

On 11/30/2016 10:44 AM, Werner Koch wrote:
> On Tue, 29 Nov 2016 21:19, zepmas...@gmx.net said:
> 
>> sec   rsa4096/0xABCDEFGH 2015-04-07 [SCA] [expires: 2020-04-05]
>>   Key fingerprint = ABCD ABCD ABCD 
> 
> That does not look like the standard output of gpg 2.1.15 - Please
> remove the keyid-format option from your gpg.conf.
> 
>> gpg-connect-agent
>>> keyinfo --list
>> S KEYINFO "some hex string" D - - - P - - -
>> ERR 67108891 Not found 
> 
> Are all keyfiles in ~/.gnupg/private-keys-v1.d/ readable ?  Check the
> permissions.
> 
> 
> Shalom-Salam,
> 
>Werner
> 

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

Re: Proof for a creation date

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Friday 2 December 2016 at 1:46:00 PM, in
, Stephan Beck
wrote:-



> gpg's signature timestamp (on a given file) would NOT
> be a real proof of
> a document being allegedly signed at that specific
> date or (prior to a
> determined date).


Maybe use a digital timestamping service, such as
?

Or publish an encrypted (or not) copy in the small ads of a newspaper.

- --
Best regards

MFPA  

An idealist is a person who helps other people to be prosperous
-BEGIN PGP SIGNATURE-

iL4EARYKAGYFAlhCy71fFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3
MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSHtQEA8/8Lrit4l+I1qgxnCWSov6ai
dF/2/9n31AmG4/0k5HsA/30W1f52Ae3Dmx6B5Gt0DYIXgLDTit8mISD2GvFvHdgN
iQF8BAEBCgBmBQJYQsvOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNlYIALPOm8l1bgXq1Gn9nuXahN+m
oTKHJMegDoGsYhjDou8YSHHPj998evdAAhsg6yeZwNmq37FRYIyrqx2aMsmQy6qx
lKMyCA0OFDgetFfKS/C/jGkkY0YyZvv5z8mecokmnc82C5T3HpfmzGAazheh+Nm0
SHAp34rkTUL+8zukKbTpnMXhFItlrflThEc4ZoLIj+df7XD3ajWuMgwnf1vEgQY+
CRHCurgWYkVSAEuyqf7ehKhumCfawELbGmfYWQXWpiUfQ9rbRigRQ+OkG/Aw5Ggo
w2HjJI23aAy9ZZRm8T01KYQXR7+0Uy9hyzU+dS1lTZfETtHFdsbHPYqKSyfgzm8=
=7mgK
-END PGP SIGNATURE-


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