Re: Why is there no secret key?

[Peter Lebbing]

On 27/07/2020 22:53, Ayoub Misherghi wrote:
> With API I mean something like GPGME.

It seems to me that including options in gpg.conf that GPGME does not
expect people to put there might throw it out of whack.

> 1) It is preferable to have "--batch" on command line even in
> unattended operation; and not in the gpg.conf file?

Precisely when you do unattended operation should you have it on the
command line. And it should not be in your gpg.conf.

Why do you say "_even_ in unattended operation"?

> 2) --pinentry-mode when needed goes in gpg.conf

No, it makes more sense to specify this on the command line in the
instances you actually need this. However, I explained two methods[1] of
seeding the passphrase, neither of which uses --pinentry-mode.
--pinentry-mode is a great way to shoot oneself in the foot
security-wise.

> 3) --allow-loopback-pinentry when needed goes in gpg-agent.conf

It's already the default, if you want to disallow it you would specify
--no-allow-loopback-pinentry.

Please see the man page.

> Is it true that command line parameters only go to gpg and gpg-agent?

I don't really understand the question.

Usually, you only specify command line parameters to gpg. gpg might
launch a gpg-agent, or connect to an already running instance. There
are gpg command line parameters that influence the command line used to
launch gpg-agent, but in general, gpg's parameters do not propagate to
gpg-agent.

They each have their own set of parameters, documented in the man pages
gpg(1) and gpg-agent(1) respectively. GnuPG consists of more binaries,
but those two are the major ones.

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2020-July/063825.html

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there no secret key?

[Peter Lebbing]

On 27/07/2020 20:56, Ayoub Misherghi wrote:
> The same thing happens when I give the option --no-batch on the
> command line.

But that only passes --no-batch to gpg, not to gpg-agent. Werner said
you shouldn't put these options in your .conf-files. Please just include
--batch on the command line with the actual batch commands.

> The problem seems to have gone away when I moved the config option
> inentry-mode loopback
> 
> to the $HOME/.gnupg/gpg.conf from the $HOME/.ngupg/gpg-agent.conf

--pinentry-mode is a gpg option, not a gpg-agent option. The
loopback-related option to gpg-agent is --allow-loopback-pinentry.

> In the final version when development ends, I am going to have
> "no-batch" in the config because the final version works
> 
> non-interactively (and through the API.) That is why I have it in the
> config now.

Please just include --batch (I assume you mistyped when you wrote
--no-batch) on the command line with the actual batch commands.

Not sure what you mean by through the API.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there no secret key?

[Peter Lebbing]

On 27/07/2020 11:17, Werner Koch wrote:
> of the "batch" option.  This option should in general not be used for
> gpg-agent.

Which, by the way, is documented well in the man page gpg-agent(1):

   --batch
  Don't  invoke  a  pinentry or do any other thing requiring human
  interaction

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Deleting or renaming $HOME/.gnugpg

[Peter Lebbing]

Hi,

On 27/07/2020 07:03, Ayoub Misherghi via Gnupg-users wrote:
> Will this scenario work?

Yes, as long as you also kill the daemons so they restart with the new
situation:

$ gpgconf --kill all

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why is there no secret key?

[Peter Lebbing]

On 20/07/2020 20:25, Ayoub Misherghi via Gnupg-users wrote:
> gpg: decryption failed: No secret key

Are your gpg.conf and gpg-agent.conf (or let's just say any .conf-file
in your GnuPG home, ~/.gnupg) empty? Do you get a pinentry popup asking
for a passphrase?

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Newbie question.

[Peter Lebbing]

On 12/07/2020 20:01, Ayoub Misherghi wrote:
> Can you please suggest some good tutorial and reference material
> preferably free (probably mutually exclusive requirements) that will
> bring me up to your level or close to it please.

No, I think the available documentation is lacking in quality. And
on the other hand there's a lot of bad advice on websites. It's an
unfortunate situation, but few people enjoy writing good documentation.
It is a very laborious process.

Sorry I can't be of better assistance.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Newbie question.

[Peter Lebbing]

On 12/07/2020 17:45, Ayoub Misherghi wrote:
> Sorry for going off list and messing everybody up. Now I disserve
> punishment.

Heh :-). It's just that if I reply off-list, it only helps you, but if
it is on-list, other people can find it in a search engine when they're
facing something similar.

On 11/07/2020 21:07, Ayoub Misherghi wrote:
> My current intended usage is in non-interactive mode, completely.
> I can remove them from the gpg.conf but I would have to issue them
> every time. My understanding is that non-interactive mode requires
> those commands.

Well, in that case, you should supply --no-batch when you're using it
interactively; I'll show why further down.

My personal choice would be to have my scripts and programs supply the
--batch on invocation rather than put it in the config file, because you
only need to write that command invocation in the script once (as you're
writing the script), whereas you'll be writing the --no-batch every time
you /do/ use it from an interactive shell.

> I selected "expert" mode because I am using ED2599 incrpytion that is
> available only in this mode (I know, I am newbie)

You only need the --expert on commands creating or adding keys for that.
Once you have the key, you no longer need --expert to just use it.

> All the config lines I showed are in my user config.
> A few days ago, my set up, which is still in development phase,
> worked until my short lived gpg keys expired. I fell in deep * when
> I created new keys. It all worked, with the passphrase-file option and
> without, before I fell. Can you pull this dumb newbie out?

I think the combination that worked might have been

--8<---cut here---start->8---
pinentry-mode loopback
passphrase-file /home/ayoub/.gnupg/output.png
--8<---cut here---end--->8---

but once you commented out the passphrase-file entry, GnuPG had no way
to get the passphrase. Normally you should use the pinentry (so comment
out the pinentry-mode line as well), but you force it to use the
loopback pinentry-mode. gpg _could_ ask for your passphrase that way.
But, you also specify --batch. --batch tells GnuPG that the human is
currently unavailable and it needn't bother trying to interact with it.
So it has no way to get the passphrase and gives up.

It will ask you for the passphrase when you comment out --batch, but I
recommend also commenting out the --pinentry-mode line so it'll just
launch a pinentry like it wants to do.

Now about this configuration:

--8<---cut here---start->8---
pinentry-mode loopback
passphrase-file /home/ayoub/.gnupg/output.png
--8<---cut here---end--->8---

If this file is stored with the same access conditions as
~/.gnupg/private-keys-v1.d/, it serves no good purpose. You should then
just use a key without a passphrase. With a key without a passphrase, an
attacker would just need the file

~/.gnupg/private-keys-v1.d/[...].key

and they're good to go. With your passphrase-file, they need two files:

~/.gnupg/private-keys-v1.d/[...].key
~/.gnupg/output.png

and once again they're good to go, they have your private key. Why would
it be more difficult to get a hold of two files rather than one? Just
drop the passphrase, and all your problems magically disappear :-).

But given its name, I suppose output.png is generated by some unlocking
process. Suppose you did it like this before:

$ my-unlocker >~/.gnupg/output.png

You can actually unlock keys the way GnuPG intends to do that with:

$ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset 

You can find the keygrip for your keys with:

$ gpg --with-keygrip --list-secret-keys 

You do need it for every subkey you want to use like this separately,
and also, it does not verify whether the passphrase was correct. Also,
put

allow-preset-passphrase
max-cache-ttl 

in ~/.gnupg/gpg-agent.conf

and issue

$ gpgconf --kill gpg-agent

to reload.  is how long you want the passphrase to stay
available after gpg-preset-passphrase, and it defaults to a mere 2
hours. You could set it to 4294967295 to specify a lifetime of 136
years, i.e., infinitely for all practical purposes.

Watch out that my-unlocker doesn't leak the passphrase in any way. I
thought it was unhelfpul that you can't use the pinentry with
gpg-preset-passphrase and I proposed a hack more than two years ago:

https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059917.html

It's pretty hacky, but it does seem to work.

You could actually just unlock your key by using it once when you start
up your system, and then use the caching feature to keep it available
for non-interactive use for the rest of the time. Then you don't use
gpg-preset-passphrase, but put, e.g., this in your gpg-agent.conf

default-cache-ttl 4294967295
max-cache-ttl 4294967295

and unlock your key by doing one decryption:

$ echo Open Sesame | gpg -r develop1 -e | gpg -d

This 

Re: Newbie question.

[Peter Lebbing]

Hi,

On 11/07/2020 19:58, Ayoub Misherghi wrote:
> ayoub@vboxpwfl:~/sentry/trunk$ cat ~/.gnupg/gpg.conf
> batch
> pinentry-mode loopback

Ah yes. Those two options have no place in your gpg.conf. They are
options that you might want to specify as part of the command line on
occasion, but unless you have a very unusual setup they should not be
there. You should remove both. The pinentry-mode is probably what is
preventing you being asked for the passphrase.

> expert

I'd recommend dropping this as well.

> #--passphrase-file file
> #passphrase-file /home/ayoub/.gnupg/output.png

These commented out lines are probably why the pinentry-mode line was
there in the first place. Do you know why these lines, both the
uncommented and the commented ones, are in your gpg.conf?

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Newbie question.

[Peter Lebbing]

Hi!

On 10/07/2020 23:47, Ayoub Misherghi via Gnupg-users wrote:
> ayoub@vboxpwfl:~/testdir$ gpg --list-secret-keys

Could you do

$ gpg --with-subkey-fingerprint --list-secret-keys

and

$ gpg --version

please?

And do you get a popup asking for your passphrase or is what you post
all the interaction that you get? If that is where the problem lies,
it's good to know your operating system/distribution, your desktop
environment, and stuff like that.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: decrypt aes256 encrypted file without gpg-agent

[Peter Lebbing]

On 29/06/2020 18:38, Fourhundred Thecat wrote:
> I don't have gpg-agent installed, on this particular server, where I
> need to decrypt one file.

You could try installing sequioa-pgp[1], an alternative but also libre
OpenPGP implementation (still in its infancy). It requires a Rust build
environment to compile.

Or just bite the bullet and install gpg-agent. If you also need
unattended decryption, there are ways to programmatically pass the
passphrase to it. Although many people make security theater of their
unattended decryption methods, it requires thought to design unattended
decryption that isn't trivial to bypass once the attacker has read
access to storage, or perhaps some other form of access that is
definitely within scope of your threat model.

HTH,

Peter.

[1] https://gitlab.com/sequoia-pgp/sequoia

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Exchange between muiltiple OpenPGP implementations

[Peter Lebbing]

Hi,

On 31/05/2020 10:01, Patrick Brunschwig wrote:
> The only "problem" might be that you have different keys on different
> key rings. But this is not necessarily a problem - you use different
> keys for different purposes and you can import and export the keys
> between the tools if needed.

Does the new TB implementation support TOFU? If so, you lose your TOFU
historical data and identity assertions when you would export/import to
a different OpenPGP implementation. That'd be a shame. Maybe there's a
need for a standardised interchange format for that.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpgsplit/pgpdump replacement

[Peter Lebbing]

Hi,

On 28/05/2020 06:20, halfdog wrote:
> Using a signing key per source seems to be impractical here too as it
> would also require to transfer the whole file beforehand for signature
> verification.

What about solving your entire use-case with an explicit two-step
process:

There's an encrypted, signed OpenPGP file with just a cryptographically
secure random number. It is signed by a per-source signing key and
encrypted to the secure machine.

There's another file with symmetrically encrypted data using the tool of
preference (could be GnuPG with --symmetric encryption) which actually
contains the bulk of the data. The "passphrase" or encryption key is the
cryptographically secure random number from the OpenPGP file.

So every time you would now create a public-key encrypted file with the
historic data, you explicitly generate a fresh "session key". You
encrypt the data symmetrically with that key, and also public-key
encrypt and sign that "session key".

When you need to recover the historic data, the device sends only all
the public-key encrypted "session keys" to the secure machine. That
checks all these are signed by the device in the field, and if so,
returns all "session keys".

It's basically a duplication of the OpenPGP session key, and indeed,
internally you are using a session key to encrypt a "session key". So it
needs twice the randomness, which might be a problem on embedded
systems. But it prevents needing packet surgery and inspection, instead
just using default mechanisms.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Biometrics

[Peter Lebbing]

On 25/05/2020 09:47, Michał Górny wrote:
> ...and that's really a good thing they can do that instead of choosing
> a more painful way of getting your fingerprints.

How is that an advantage compared to passphrases? As soon as someone
threatens to go all XKCD 538 on you[1], just give them your passphrase.
No need to lend them your finger, either with or without you still
attached.

If this is your threat model, you need more than encryption or
biometrics.

... unless your whole comment was as serious as my comment about plastic
surgery of course :-) ...

More seriously, biometrics might be a nice deterrant to the casual
opportunistic curious peeker. It's quick, a finger swipe takes less time
and effort than a good passphrase. But it's not proper security in my
book.

Peter.

[1] https://xkcd.com/538/

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of Keys

[Peter Lebbing]

On 24/05/2020 21:39, Mark wrote:
> I know there are other options maybe even some that use
> biometrics to decrypt the database.

I am very wary of biometrics for authentication purposes. There are so
many examples where the vendor assured us it was working really well,
and researchers easily cracked the system by using a photo, or
photocopied fingerprints they lifted off a glass or even more funny from
the fingerprint reader itself.

That's for authentication, where only non-reproducability is vital. For
encryption, it's much worse, because you need a lot of entropy for that
to ward off offline attacks. And biometrics just doesn't have that much
entropy.

And both share that there is no recovery from compromise. If somebody
learns your passphrase, you change it, tracking down all backups and
changing them as well. That might be a little painful.

If somebody manages to copy your biometrics, you can't change them. You
could erase your fingerprints by taking a job processing pineapples on a
daily basis. And you could get plastic surgery for your face, but that
really puts the painful in "it's so painful to change your passphrase
everywhere"...

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of Keys

[Peter Lebbing]

On 24/05/2020 19:11, Mark wrote:
> I think if all the important files are stored in an encrypted
> container, they should be pretty secure.

Just watch out for the catch-22 of "I lost my hard drive, let me restore
from that encrypted container. Hmmm, my only backup of my private key is
inside a container encrypted to that private key..."

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of Keys

[Peter Lebbing]

On 24/05/2020 18:03, Peter Lebbing wrote:
>> % gpg -o public-keys.gpg  --export

Oh! That is perhaps not good enough :-). You need

$ gpg --export-options export-local-sigs -o public-keys.gpg --export

so you don't lose any non-exportable signatures. There's also
--export-options backup, which implies export-local-sigs. I just tested
that because I did not know. So I think for backup purposes this is the
best:

$ gpg --export-options backup -o public-keys.gpg --export

Check the manual for more --export-options.

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of Keys

[Peter Lebbing]

Hi,

On 24/05/2020 16:05, Felix Finch wrote:
> Out of curiosity ... how safe are these files as is, assuming the
> private key file has a good strong passphrase?

The safety of the private key purely depends on the strength of the
passphrase. Note that backups will have the passphrase that was set when
the backup was _made_. Changing the passphrase on your computer will not
change the passphrase in any older backups.

But there is more data in your GnuPG homedir that is not encrypted but
is privacy-sensitive. If you ever assign someone ownertrust, that will
be reflected there. It indicates how much you trust people to correctly
verify other people's identities and how well you trust them to keep
their private key private. Your brother-in-law might be offended by you
assigning him "NEVER TRUST", and your partner might not appreciate you
apparently having somewhat recently assigned positive trust to that ex
you swore you never saw anymore.

And then there is the history data for TOFU, which exposes some data
about when you verified signatures by other people or when you encrypted
something to someone. This data is there to help you analyse
trustworthiness about the third party in question when so prompted, but
it is also communication metadata about you.

These pieces of data might not exist for your particular configuration,
but they can exist.

> How hard is it to crack a good passphrase?

I think the definition of a good passphrase is that it is infeasible to
crack it. That makes it circular reasoning.

A well-executed "Correct Horse Battery Staple" passphrase or a long
enough diceware passphrase cannot be cracked. The problem is determining
whether you did it right or are misunderstanding some vital detail of
creating a good passphrase.

For instance, actually choosing "Correct Horse Battery Staple" is about
the worst thing you can do... :-)

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of Keys

[Peter Lebbing]

On 24/05/2020 14:52, Damien Goutte-Gattat via Gnupg-users wrote:
> No, it’s not.

Absolutely not ;-)

> For the private and public keys however, instead of saving the files
> directly I’d recommend exporting them from GnuPG:
> 
> % gpg -o private-keys.gpg --export-secret-keys
> % gpg -o public-keys.gpg  --export

Note, however, that the first of these two is interactive in that it
asks for your passphrase(s). This is because it needs to be re-encrypted
because the storage format is different.

So you could do the first one manually every time you add (or remove)
private keys or change a passphrase. Anything else, including changing
key preferences, key expiry, etcetera, is equally reflected in
public-keys.gpg from the second line. 

The second can be done regularly and automatically.

Do back up other stuff from that directory as well. It's important,
non-public data: your ownertrust declarations, TOFU bindings and
history.

You might want to omit the file random_seed. I forgot how important this
is these days. I believe it has gotten less important at some time.

But using Sherpa is probably a good bet.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Making a subkey a standalone Master key

[Peter Lebbing]

Another idea would be to deliberately destroy the encrypted primary key
material you upload to ProtonMail. I'd suggest setting the capabilities
of the primary key to just Certify, not Sign. It could very well be that
ProtonMail never tries to decrypt the encrypted primary private key
then, because it is never asked to do a certification. And since you can
only tell that the encrypted material has been destroyed once you
actually try to decrypt it, it would never notice and chug on happily
oblivious it has been lied to.

Oh, to answer the original question, you're looking for

$ gpg --expert --full-gen-key

and then option (13) Existing key.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How to decrypt a message while preserving the signature?

[Peter Lebbing]

Werner recently mentioned an undocumented command for this.[1]

On 27/08/2019 11:30, Werner Koch via Gnupg-users wrote: 
> You can extra the signature from the encrypted+signed data:
> 
>   gpg --unwrap -d -o SIG  
> and then run
> 
>   gpgv -o SIGNEDFILE SIG && echo verified!
> 
> --unwrap is not documented and has the minor problem that it also keeps the
> compression layer.  However, gpgv groks that compression layer and works
> as with a standard signature.  The signature is on SIGNEDFILE which gpgv
> outputs for you.

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2019-August/062619.html

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Smartcard operation

[Peter Lebbing]

On 17/09/2019 18:59, Stefan Claas via Gnupg-users wrote:
> I assume that in order to decrypt a message the secret key data must be
> unlocked and loaded for a very short time into the computers RAM, in order
> to perform the decryption, or am I wrong with my assumption?

OpenPGP messages encrypted to a public key are hybrid encryption: the
asymmetric (public/private) crypto is used to establish a per-message
shared secret. This shared secret is used by a symmetric encryption
algorithm to encrypt the actual data.

The smartcard does the asymmetric part of it all by itself, the computer
just asks it to decrypt something and gets the per-message shared secret
back from the card.

Then the PC will do the symmetric decryption of the actual data.

During regular use, knowledge about the private key contents never
leaves the smartcard, not for the briefest period.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ProtonMail and Anonymity

[Peter Lebbing]

Hello Stefan,

On 01/09/2019 14:14, Stefan Claas via Gnupg-users wrote:
> Also interesting.
> 
> https://eprint.iacr.org/2018/1121.pdf

If you post URL's to this mailing list, could you please provide a short
description of what can be found at the URL? This prevents the situation
that people should visit the URL to know if they want to visit the URL,
and helps a lot when searching the archives.

In this case, since it's a scientific paper, I think the following would
be a good way to share it (I used the BibTeX citation to quickly get all
the relevant fields). But at least include a short description, please.

Here:

A scientific paper by Nadim Kobeissi published in 2018 in the Cryptology
ePrint Archive, titled "An Analysis of the ProtonMail Cryptographic
Architecture":

https://eprint.iacr.org/2018/1121

Abstract:
ProtonMail is an online email service that claims to offer end-to-end
encryption such that "even [ProtonMail] cannot read and decrypt [user]
emails." The service, based in Switzerland, offers email access via
webmail and smartphone applications to over five million users as of
November 2018. In this work, we provide the first independent analysis
of ProtonMail's cryptographic architecture. We find that for the
majority of ProtonMail users, no end-to-end encryption guarantees have
ever been provided by the ProtonMail service and that the
"Zero-Knowledge Password Proofs" are negated by the service itself. We
also find and document weaknesses in ProtonMail's "Encrypt-to-Outside"
feature. We justify our findings against well-defined security goals and
conclude with recommendations.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Slightly OT - mobile OpenPGP usage

[Peter Lebbing]

On 28/08/2019 12:07, Peter Lebbing wrote:
> Whether a compromise is game over depends on your scenario.

Sorry, I meant, it depends on your definition of "game over", definitely
*not* on the scenario.

I think it is perfectly acceptable to say "compromise = game over", the
only way I see that could be wrong is if you have a different idea of
what game over means.

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Constantly restarting gpg-agent

[Peter Lebbing]

On 26/08/2019 01:26, Farhan Khan via Gnupg-users wrote:
> I use gnupg to sign my git commits, but after a few hours of use I
> have to restart gpg-agent. Before doing so, what I presume is
> gpg-agent asks me to re-enter my password on a random terminal (but it
> seems to drop characters and never works).

Ah yes, when I use the agent for SSH authentication and it picks the
wrong terminal, if on that terminal bash is active, they seem to race
for stdin. Some of the characters typed go to the pinentry, and some go
to bash. The characters for bash are echoed to the screen. It's a great
way to get part of your passphrase in .bash_history! :-D

But for gpg, this should not happen. gpg will pass the terminal and/or
the X display to the agent, which enables the agent to prompt on the
correct terminal.

You could try debugging the agent. If I add the following to my
.gnupg/gpg-agent.conf:

--8<---cut here---start->8---
debug ipc
log-file agent.log
--8<---cut here---end--->8---

and then issue "gpgconf --kill gpg-agent", the agent that will be
subsequently started will log inter-process communication to the file
agent.log in my homedir ($HOME, not $GNUPGHOME). There I can see a git
commit signing passing the needed information:

--8<---cut here---start->8---
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION 
ttytype=screen.xterm-256color
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION display=:0.0
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION 
xauthority=/home/peter/.Xauthority
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK
--8<---cut here---end--->8---

Is it perhaps possible that you run something which unsets environment
variables crucial to passing the TTY information to the agent? Have
a look at the debug log the moment you encounter the issue again, and
compare the conversation with an earlier one that did work.

> As a result, the git commit fails. I have to kill
> gpg-agent and restart it as "gpg-agent --daemon", which then works.

Killing the agent is fine. You shouldn't need to restart it; it is
autostarted and in fact it might interfere with the proper functioning
if you explicitly start it but with different options set than the
autostart would do.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Slightly OT - mobile OpenPGP usage

[Peter Lebbing]

On 28/08/2019 00:41, Chris Narkiewicz via Gnupg-users wrote:
> This is not true. Many crypto systems are designed to perform damage
> control and recovery in such cases.

Damage control in the case of GnuPG would be using a smartcard: while
you are using the smartcard, so can the attacker, but once you pull the
smartcard and no longer use the compromised system, the attacker no
longer has access to the key.

In this scenario it makes sense to have an offline primary key: while
the attacker can issue data signatures and decrypt your files, they
cannot change your key, e.g., add another signing subkey to be used
later when the smartcard is no longer available to the attacker.

Recovery... well, damage control already implied there was damage, and
recovery even more so. Stefan asked for a "best strategy for using
OpenPGP [...]". I did not interpret that as asking for how to limit
damage, but rather to avoid it.

Whether a compromise is game over depends on your scenario. However,
what is quite often asked for here is some way to use a compromised
system without compromising confidentiality of encryption or without
enabling an attacker to issue data signatures. These things cannot be
done on a system where the attacker has control over the whole computer
(root access, in *nix parlance, or hypervisor access). If you can show
me an example where the attacker has full access to a computer and a
user can still do decryption and issue signatures *on that computer*
while maintaining confidentiality and signature integrity, I'd love to
hear about it. However, I've heard many wrong solutions, so in actuality
I don't think I would love to hear about it, because it sounds like a
waste of time.

Here are two obviously wrong ones.

"Provide explicit confirmation of each signature issued by a smartcard
with an external button".

Attacker's solution: pretend something went wrong, and make the user do
the actions again. Nothing actually went wrong, the user issued two
signatures. Social engineering to the rescue. Or, demise.

When they're sending an e-mail, simply make it look like the mail client
crashed just after they confirmed the signature, for instance.

The confirmation button doesn't ensure signature integrity, it is
damage control.

"Provide explicit confirmation of decryption with smartcard".

Whenever user decrypts something, store the decryption key in a
database. When the user decrypts the same file twice, use the stored
decryption key and decrypt that interesting file the attacker wants to
read instead.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Slightly OT - mobile OpenPGP usage

[Peter Lebbing]

On 27/08/2019 21:50, Stefan Claas via Gnupg-users wrote:
> But what would be, when using computers at work or public places, then
> the best strategy for using OpenPGP, without carrying a Notebook or
> smartphone?

If a computer is compromised, this is game over for cryptography. Full
stop.

> There should be good solution available IMHO. :-)

BYOD :-)

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: how to recover secret key passphrase?

[Peter Lebbing]

On 20/08/2019 19:46, vedaal via Gnupg-users wrote:
> Try This:
> 
> [1] Open a new terminal command prompt window
> [2] Type  gpg -a --export-secret-key keyname

I think ilf is quite correct that you need to enter your passphrase to
do an export from the agent-managed store in private-keys-v1.d. The
encryption in the private key store is not the same as the encryption of
a transferable OpenPGP private key anymore, so it needs to be decrypted
and re-encrypted, which is why you're asked for your passphrase.

> This works in both GnuPG 1.x and 2.x 

I think it would have worked in 1.x and 2.0. But for 2.1+, it no longer
works, and

> Don't use gpg-agent for this.

you actually really need the agent to access the private keys from GnuPG
2.1+.

So what ilf probably needs is something that can read the private keybox
format. That's where my advice falls short: I can't help with that.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key poisoning

[Peter Lebbing]

Hi MFPA,

> Would the attack work by just concatenating lots of identical
> signature packets onto a copy of the target key and sending the result
> to the keyserver?

I have no knowledge of the workings of the keyservers. But my guess is
that they would all be coalesced into the single signature that they are
(similarly to when a single new signature was uploaded to two different
SKS keyservers and these are coalesced on reconciliation).

It might be possible if you just change some bytes. I dunno.

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 




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: looking for assistance tracking down why i don't have the ability to run gpg from the command line

[Peter Lebbing]

Hello,

> ni@quark:~/.ssh$ ps aux | grep 22009
> ni7740  0.0  0.0   6076   892 pts/6S+   11:21   0:00 grep
> 22009
> ni   22009  2.0  0.2  89404 78536 ?RL   02:51  10:30 gpg
> --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8
> --enable-progress-filter --exit-on-status-write-error --display :0
> --logger-fd 108 --with-colons --list-keys --
> 4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F

That doesn't show which process is starting that gpg. I would start by
doing

$ ps fax | less

and then from within less type for instance

/22009

which will search for the line containing that PID. Then you can see its
ancestry (the f option makes a -f-orest of parent/child relations).

There are more ways to investigate, but this seems a good start.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

My mails to rjh bounce

[Peter Lebbing]

By the way, I keep intending to put this as a PS on a proper mail, but I
always forget.

All my mails to Rob keep bouncing. The first bounce was June 30th. I'm
not including the bounce message here on the off chance that there is
something non-public about Robs mail infrastructure :-). So Rob can find
it encrypted to him at [1].

All those bounced mails were also addressed to the mailing list, so he
got a chance to read them anyway...

Cheers,

Peter.

[1] 

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key poisoning

[Peter Lebbing]

On 15/08/2019 08:50, Robert J. Hansen wrote:
> Additionally, the bad guys can create new malicious certificates faster
> than the keyserver network can blacklist.

Plus, the attacker could just create a signature that looks likely to be
real (self-sig or existing third-party sig seems a good candidate). Only
when actually doing the cryptographic verification will it turn out to
be fake anyway. By that time the amount of processing GnuPG has done is
already enough for the denial of service.

I think the attacker only used cryptographically valid signatures
because it was easier to use existing tooling. There is no reason for
the poison to be cryptographically valid. It just has to be slightly
expensive to verify. GnuPG doesn't even get to the bit where the
signature is validated, since the signing key isn't on the keyring, and
still, we have this DoS.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Difficulty of fixing reconciliation

[Peter Lebbing]

On 14/08/2019 12:29, Vincent Breitmoser wrote:
>> The algorithm is designed to withstand very well funded actors,
>> oppressive regimes were what the designers were thinking of.
> 
> We are talking about a sand castle here that was kicked down by a kid. It's
> a bit bizarre to claim that it was built to withstand rockets.

I meant that statement purely and only with regard to deleting data that
had already been in the network, nothing more.

It seems to me that the impossibility of deletion was at the core of the
design of the reconciliation algorithm. To say that we should change the
algorithm to no longer do that seems like claiming we should build
rockets out of sand castles ;-).

> Given that the recon algorithm was designed as a PhD thesis, it seems like
> a safe bet that it was designed to solve the academic problem of set
> reconciliation between distributed systems with optimal message complexity.
> Funny story how it ended up becoming infrastructure for a security ecosystem.

These same statements apply to a *lot* of critical infrastructure in the
Information Technology domain. It's a wonder it usually works well (or
at least gives that appearance when you don't look too hard).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Difficulty of fixing reconciliation

[Peter Lebbing]

On 14/08/2019 12:09, Andrew Gallagher wrote:
> Indeed, but that condition is fundamentally incompatible with
> decentralised reconciliation - because deletion without permissions
> management is an open door, and permissions have to be enforced by an
> authority.

H the authority could just be the primary key that the
third-party signatures are over. I'm not talking about the current SKS
keyserver network, but some still-to-be-created federated synchronizing
service.

That authority could also authorize no longer sharing a particular third
party signature, I think. It might still circulate in the federated
network, but any time it rears its head again it could get ignored by
the revoked authorization (or more: authorization to revoke). "Ignoring"
might just mean not offering it to clients even though it's still part
of the federation for technical purposes.

There's a lot of chance for misunderstandings here. I started writing
something less ambiguous and stopped due to the amount of work :-).

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Difficulty of fixing reconciliation

[Peter Lebbing]

On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong.  It must be possible to delete errors.

In that case we need a different algorithm.

Which I had already been advocating, so you are preaching to the choir.
You can keep reiterating that you do not like the current algorithm, but
I already got that and I agree.

> Exactly!  That signature is poisoned, delete it.

Which is a denial of service, which I point out in the next paragraph of
the mail you replied to. I'll copy-paste it here with a double
indentation:

>> In neither case will the user get that signature that they actually
>> want, and which according to Murphy is actually near the end of where
>> GnuPG will be looking.

> The defense would try and avoid poisoning.  When a signature is
> poisoned, the defense has failed.

And that's again my very next paragraph:

>> I think the solution needs to be sought in a direction where GnuPG
>> doesn't have to look for valid data amidst a lot of invalid crap.
>> Because evaluating the invalid crap can always be made expensive, so
>> there should be other means to say "I'm not going to parse this, find
>> another way to get me the proper data where it's not buried in crap".

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: PGP Key Poisoner

[Peter Lebbing]

On 13/08/2019 17:11, Robert J. Hansen wrote:
>> I think the proper fix is to design an alternative to the SKS keyserver
>> network. The design choices in the reconciliation protocol don't work
>> out anymore, we shouldn't change the protocol but replace it.
> 
> I agree.

Ah, then the discussion about OCaml is a moot point by now and can be
disregarded until the moment someone proposes to write the replacement
in OCaml :-D

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"

[Peter Lebbing]

On 13/08/2019 13:56, Kristian Fiskerstrand wrote:
> As you correctly point out its really not that relevant for encryption
> subkeys. It does have security implementations for signing subkeys; see
> [cross-certification section] for some details on that.

But this issue has been fixed for so long that any CD's documenting the
fix will have since bit-rotted! It's ancient Information Technology
history!

To be exact, this has been a non-issue since GnuPG 1.4.8, released
2007-12-20, which defaulted to --require-cross-certification after the
cross certifications had percolated through the ecosystem in the years
leading up to that new default.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: PGP Key Poisoner

[Peter Lebbing]

On 12/08/2019 22:09, U'll Be King Of The Stars wrote:
> The things I missed are:
> 
> - how to check and clean a user's local keyring
> 
> - how to update the user's local configuration in ~/.gnupg

I generally felt there was a lack of concise, complete instructions for
users, after the event. I was missing several pieces of the puzzle
myself. Still, I suppose I could have tried to do this, so it's a bit
odd to be pointing out that this area was lacking when I could have
solved it partially myself. But here we are: I never saw a good concise
complete set of instructions and guidance, and I was a bit surprised
no one wrote it.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: PGP Key Poisoner

[Peter Lebbing]

I suspect we haven't seen this issue being done in the real world before
because it is not a useful attack in many scenarios. It's just a nasty
DoS that can be avoided by not using the SKS keyserver network. I'm
completely speculating, but I think that the people who really want to
learn something about their victim will use and have used completely
different attacks. This DoS isn't effective at what they want.

I don't know if that is the case, but I think it's a possibility.

This doesn't mean that this attack was harmless; far from it. I think it
has the potential to do a lot of harm to a lot of people. It just
possibly doesn't really accomplish the goals that, for instance,
oppressive regimes or black hats penetrating networks have. And since no
serious attacker used this weakness, by that virtue it might not be a
big problem. The good sides of the SKS keyserver network might outway
its flaws when the flaws are not the flaws that attackers will exploit
in practice.

Until little boys with matches come round and play at being responsible
security researchers without understanding how that actually works.

> People know there that there are issues for a decade with the software
> running on their servers and they don't understand the codebase to fix
> issues.

I don't think the bit about the OCaml code complexity was a good
argument in Rob's gist post.

I think the proper fix is to design an alternative to the SKS keyserver
network. The design choices in the reconciliation protocol don't work
out anymore, we shouldn't change the protocol but replace it.

Several alternatives for key distribution have actually been developed
for many years now. You can't say people are not actively working on
this problem, it's just not true. That they are actually looking in a
different solution space than what you want to see is their right.

> And when things later happen, like recently, they still run their
> servers.

Perhaps because there are still users who need it. GnuPG 2.2.17 already
led to a report[1] on the mailing list that they needed third-party
signatures from keyservers. I don't know if they need the SKS network,
but in general, there are users out there who can still use it.

But I obviously can't speak for anyone else.

> I wonder why those SKS key servers are so important to be still in
> service as of today since we have WKD, Hagrid, keybase, Mailvelope Key
> Server and Facebook?

Only people using the SKS keyserver network are affected by this issue.
You say you don't see a reason to use them. So don't. Tell your
correspondants to use different methods when they exchange keys with
you, and you'll never have to interact with the SKS keyserver network
again. Problem solved; for you. Others will take care of their own.

Also Facebook?

A lot of the alternatives to the SKS network have some issues regarding
either a form of trusted third party, or of anonymity. Every service has
its own trade-offs. And some stand out like a sore thumb. Again...
Facebook?! :-)

Cheers,

Peter.

[1] 

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Difficulty of fixing reconciliation

[Peter Lebbing]

On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote:
> More than a reasonable number of signatures makes no sense in
> practice, so I agree lists should somehow be "fixed" so as not to
> accept an unreasonable number of signatures (reasonable == 2??)

Others tell us: the synchronization protocol as it is cannot be fixed.
You reply: I agree it should - somehow - be fixed?

The sort and unhelpful answer of course is: read the first sentence
again, or disprove it mathematically just like the algorithm was
mathematically proven to work in the first place.

But I'll try to sketch it. I don't know the synchronization protocol.
What I do know: the design goals included resistance to oppressive
regimes interested in deleting anything from the network, so it was to
be designed so it was technically impossible to delete anything.

Furthermore, this is from memory, but when I read basic information
about the SKS reconciliation algorithm, I see the terms "monotonicity
requirement for progress" or something alike.

I don't know if this is how it works, but this is how it could work:

Somebody has worked years on an algorithm for their PhD thesis which
fulfills an important task, and through those years a lot of
mathematical proofs have been spent on proving that it does what was
asked of it. One of these demands was that it could provably never
delete data that had been available earlier.

In order to make this algorithm, the PhD student discovered that they
needed to have some properties hold at *every* single step: otherwise
they could not prove that the algorithm was correct.

So let's see a single step in the reconciliation process as the
reconciliation of a single piece of data that has been added to the
network. The PhD student found they needed a requirement they called the
monotonicity requirement. I don't know what it means precisely in this
case, but I can take a guess: if two hosts are reconciling, the
monotonicity requirement could mean that the data at either one of these
hosts

- gets data added and everything that was there stays
- the data it has stays exactly the same

Those are the only two cases that satisfy the monotonicity requirement.

Furthermore, the end goal is for all hosts to have the same dataset, so
let's define progress as that the hosts become more and more alike: when
the number of differences between the hosts has reduced, we have made
progress. Once completed, it has progressed to the point where the
number of differences is zero. As an aside, it has to be proven that we
eventually progress to that point where they are the same, otherwise
there could be a dataset that just keeps spinning, running the algorithm
endlessly. In fact, it's well possible that this is where the
monotonicity requirement plays a role.

Let's do this with your max 2.

Somebody uses SKS keyserver network host A to add two signatures, call
them A1 and A2 to the key in question, which did not have any signatures
yet. Host A accepts them, they fall within the limits.

Either this same person or someone else adds two signatures on SKS
server B on the same key, call them B1 and B2. Hosts A and B haven't
reconciled yet, so B sees no signatures on the key and accepts.

Now they reconcile.

They compare their datasets. They are not the same: we still need to
have progress to get to completion. Let's reconcile signature A1. Server
A offers server B signature A1. Wait a minute, the key already has
signatures B1 and B2. Server B cannot accept signature A1, it would
break the contract that there are ever only 2 signatures on the key.

Now we have a deadlock. There is no following step that would fulfill
the monotonicity requirement as well as make any progress. The only way
to fulfill the monotonicity requirement is when server A keeps the
signatures A1 and A2, and server B keeps B1 and B2. But the progression
has halted and the process never finishes.

Ah, you say, why don't you /swap/ B1 for A1? Well, there is no such
thing as swapping. Swapping is simply the deleting of B1 followed by the
addition of A1. And monotonicity says we can't delete anything.

Besides, any limit on the number of signatures is a Denial-of-Service.
In your case, if Alice, Bob and Carol all sign eachother's keys, there's
no more room for other signatures. And if Mallory creates two bogus keys
and signs all the keys of Alice, Bob and Carol, the three can't add any
real signatures anymore.

The algorithm is designed to withstand very well funded actors,
oppressive regimes were what the designers were thinking of. Obviously,
the algorithm does this regardless of who is trying to do something
otherwise, no matter whether it is a repressive regime or the legitimate
operators and designers of the system.

> The bug, however, is in the program that chokes on poisoned keys!

It seems to me there is (almost?) always a denial of service. Offline
systems have more trouble with this than online systems, and even
websites (online systems) have really 

Re: PGP Key Poisoner

[Peter Lebbing]

On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
> Why was is then not fixed a decade ago, like it was done with 2.2.17?

There is no fix for the SKS keyserver network, which explains why it
wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over
the last several years. DANE, WKD, Autocrypt, work on
keys.openpgp.org...

I thought this (there is no fix) was pretty solidly established by now
on this mailing list and elsewhere?

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 05/07/2019 11:15, Wiktor Kwapisiewicz via Gnupg-users wrote:
> I did a small experiment and it seems that your data is permanently
> preserved in sigchains of all people that follow you. Even if you
> delete your account.

Plus, the data is preserved in different places such as archive.org,
which I showed already in my earlier post:

https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas

That's a snapshot from 2 months ago, which will not go anywhere.

It kinda was my point posting that link ;-).

Peter.

PS: Before you blame archive.org: they respect robots exclusions and
wishes from individual site owners. It was keybase.io which allowed it
in the first place, although it may or may not have been a conscious
decision on their part.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 16:55, Werner Koch wrote:
> And well, self-sigs-only is a less intrusive change than changing
> import-minimal.  If it breaks something it can easily be reverted by the
> user - a change to the semantics of import-minimal can't be reverted by
> the user.

Ah, yes, I had completely not considered that area of impact.

> "self-sigs-only" also better expresses what it does.  If you have a
> better name, let us know.

No, I think it's a good name.

Thanks for making the rationale of the design clear!

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 18:37, Stefan Claas via Gnupg-users wrote:
> Why so upset?
> 
> I think I am allowed here to post my opinion and I do no "force"
> people.

You just said that if only you had the time and money, you would try to
take down the SKS network using a legal procedure. A procedure meant to
object to your data being available on the internet, while you clearly
don't have a problem with your data being available.

A year ago, you threatened to do precisely what has happened now: poison
Rob's OpenPGP key. You might even be the one that has done it, we can't
know.

That's not posting an opinion here. And it /is/ threatening to force
your way on other people.

This all is so bloody transparent that I don't see what your point is
yelling that the sky is green when clearly it's blue.

And apparently, I didn't check although it did ring a few bells, you
have in the past indicated you had wilfully fucked with other people's
OpenPGP keys to prove your point that it was possible. That's vandalism
in my book.

> EOD.

Neither of us gets to decide that for the other. BTW, you literally
asked a question ("Why so upset?").

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote:
> Mmmhhh...Peter, if I should do this it should serve as help guideline
> for users wishing to do the same.
> 
> Why?

Pfah. Stop rationalising. If this is your concern, create a website
where your offer your services to people wishing to do this and
advertise that website broadly. Then do it for the first person that
truly wants to have their data removed.

I asked why you felt entitled to force your opinion upon others. You say
nothing about that.

You just like to bully. That's your reason.

> Regarding my keybase presence, I can immediately close down my account
> and my data and the data from my followers is removed, cool eh?

https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas

Yes, really cool! And totally beside the point, because I brought up
keybase to illustrate my point that you do not want to invoke the GDPR
currently to remove your data. If you would currently want to remove
your data, you would have already closed your keybase account.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 16:59, Stefan Claas via Gnupg-users wrote:
> Or do SKS key servers dictate how GnuPG's submission / receiving
> protocol must work?

It's in the reconsiliation protocol and the very foundation of the
assumptions of the synchronizing keyserver network. GnuPG doesn't come
anywhere near this protocol, it's just a downstream casualty of the
implications of the system.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS and GnuPG related issues and possible workarounds

[Peter Lebbing]

On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote:
> If I had time and money I would hire a lawyer, would formulate a letter
> for SKS operators stating that I request the removal of my pub key data
> and would as EU citizen refer in this letter to our GDPR. 

Do you object to your data being available not only from the many public
archives of this mailing list but also from the SKS keyserver network?
If so: why? Don't you think many more people would use a web search to
find out about your name and e-mail address than use a keyserver search?
And why the hell does  exist then?!?!

Or is it not that you wish to invoke the GDPR for what it was meant for,
but rather you want to force the SKS keyserver network to go down,
forcing your world view upon the good people running the network? If so:
why do you feel entitled to do that?

I seem to remember you threatening, more than a year ago, to hose some
specific person's public key, who was it again, with bogus third-party
signatures.

I get the notion you're not what you'd call a "team player". "Bully"
seems to be a better description. I'm going to leave it at that, because
I don't want the list to go down the road I so desperately want to go
personally. I'll take some solace from having recently read some
stronger qualifications in a public post.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

dirmngr not picking up new config?

[Peter Lebbing]

On 03/07/2019 15:06, Werner Koch wrote:
> Check that you do not have a keyserver entry in your gpg.conf or
> Enigmail is calling gpg with that options.  The keyserver specified by
> gpg overrides whatever dirmngr has been configured to.
> 
>   debug ipc
>   log-file /some/file
> 
> in dirmngr.conf should shows what is going on.

There hasn't been a keyserver line in my gpg.conf in a long time; I
checked this before I created dirmngr.conf. And I was testing on the
command line, using --refresh-keys.

My guess is: dirmngr reloads existing configuration files but fails to
check for new ones.

Here's a reproduction:

--8<---cut here---start->8---
$ pwd
/home/peter
$ rm .gnupg/dirmngr.conf 
$ gpgconf --kill all
$ gpg --refresh-keys ac46efe6de500b3e
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key AC46EFE6DE500B3E: 2 signatures not checked due to missing keys
gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ cat >.gnupg/dirmngr.conf <" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ stat dirmngr.log
stat: cannot stat 'dirmngr.log': No such file or directory
$ gpgconf --kill dirmngr
$ gpg --refresh-keys ac46efe6de500b3e
gpg: refreshing 1 key from hkps://keys.openpgp.org/
gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ cat dirmngr.log
2019-07-03 16:30:01 dirmngr[13185.0] permanently loaded certificates: 0
2019-07-03 16:30:01 dirmngr[13185.0] runtime cached certificates: 0
2019-07-03 16:30:01 dirmngr[13185.6] handler for fd 6 started
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Home: /home/peter/.gnupg
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Config: 
/home/peter/.gnupg/dirmngr.conf
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK Dirmngr 2.1.18 at your 
service
2019-07-03 16:30:01 dirmngr[13185.6] connection from process 13184 (1000:1000)
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- GETINFO version
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> D 2.1.18
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KEYSERVER
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S KEYSERVER 
hkps://keys.openpgp.org/
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KS_GET -- 
0x8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E
2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 
'keys.openpgp.org' [already known]
2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 
'keys.openpgp.org' [already known]
2019-07-03 16:30:01 dirmngr[13185.6] number of system provided CAs: 152
2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S SOURCE 
https://keys.openpgp.org:443
2019-07-03 16:30:02 dirmngr[13185.6] DBG: (16329 bytes sent via D lines not 
shown)
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 <- BYE
2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK closing connection
2019-07-03 16:30:02 dirmngr[13185.6] handler for fd 6 terminated
--8<---cut here---end--->8---

Here's the stuff my Debian stable reports about my GnuPG:

--8<---cut here---start->8---
Package: gnupg
Version: 2.1.18-8~deb9u4

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 
'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.0.15 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.18-8~deb9u4
ii  libassuan0 2.4.3-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u4
ii  libgcrypt201.7.6-2+deb9u3
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-3
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnupg recommends:
ii  dirmngr 2.1.18-8~deb9u4
ii  gnupg-l10n  2.1.18-8~deb9u4

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information
--8<---cut here---end--->8---

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

On 03/07/2019 15:00, Roland wrote:
> And for Enigmail: your suggestion or In the terminal, to edit
> ~/.gnupg/dirmngr.conf so as to say "keyserver
> hkps://keys.openpgp.org/" or, if that file does not exist to create it
> as per your suggestion.

I don't think Enigmail respects dirmngr.conf, it just provides its own
set of keyservers. At least, if I delete them all from the Preferences
dialog of Enigmail, it prompts me to enter a keyserver, defaulting to
the literal text "undefined".

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

Hi,

On 03/07/2019 15:10, Werner Koch wrote:
> Yes, as I wrote: 0.2s compared to 50s.

I fear we're miscommunicating, so let me try to rephrase it again. Sorry
for my persistence, it's only because I think we're miscommunicating and
it would be good if that could be fixed.

If

--keyserver-options import-minimal

behaved like

--keyserver-options self-sigs-only,import-minimal

as I propose, why would it take longer than 0.2 s?

If there is no good use case for using

--keyserver-options self-sigs-only

instead of

--keyserver-options self-sigs-only,import-minimal

or for using

--keyserver-options import-minimal

instead of

--keyserver-options self-sigs-only,import-minimal

then the self-sigs-only behaviour can be folded into import-minimal,
avoiding creating yet another option in an already crowded option space.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

Hello,

On 03/07/2019 13:17, Werner Koch wrote:
> --keyserver-options recognizes all import options in addition to
> keyserver specific options.

But then import-minimal could be modified so it includes the behaviour
currently planned for self-sigs-only, and import-minimal could be made
the default for --keyserver-options, eliminating the need for another
option called self-sigs-only.

I don't think there is a need for the extra granularity:

1) --keyserver-options self-sigs-only retains all self-sigs

2) --keyserver-options import-minimal retains only the most recent
   self-sig

Is there a good use-case for the former? If the latter also filtered out
non-self-sigs in a very early stage like planned for self-sigs-only, in
addition to its current functionality in a later stage of import, it
would prevent the poison.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Local solutions: SKS Keyserver Network Under Attack

[Peter Lebbing]

Hello Roland,

> Hansen's and DKG's blog are only partly helpful. For example my Linux
> system seems to *not* have a  ~/.gnupg/dirmngr.conf file at all (one
> of those files recommended for editing). I.e. Nautilus cannot find it.

The usual case on Linux systems is that if a configuration file would
otherwise be empty or equal to the default (the two can be entirely
different things in general!), the configuration file simply does not
exist.

So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a
single line in it saying

keyserver hkps://keys.openpgp.org/

I encountered some strange behaviour here: I invoked

$ gpgconf --reload dirmngr

afterwards (otherwise dirmngr will not reconsider its now changed
configuration), and it *did not work*. It was still using the default.
It did work after I rebooted (I was not in the mood to fiddle more with
it and did the most heavy-handed thing that would work).

Also, Enigmail doesn't seem to use this configuration at all and instead
it is configured at

Enigmail -> Preferences -> Keyserver

I did verify using systemd's journal that the gpgconf --reload command
reached its intended goal: dirmngr said "re-reading config". It just
didn't have an effect for some odd reason. For people thinking about
this: no, I don't use Tor for keyservers, it's not related to dirmngr
refusing to change keyservers when on Tor.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 11:59, Peter Lebbing wrote:
> What is the difference in the end result between --keyserver-options
> self-sigs-only and --import-options import-minimal?

Ah, based on a new message I just read the penny dropped. self-sigs-only
can be made a default because it only applies to keyservers.
import-minimal cannot be made a default because it affects all other
methods of importing.

Hope that helps myself / Happy to help myself / HTHM,

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Peter Lebbing]

On 03/07/2019 09:13, Werner Koch via Gnupg-users wrote:
> The current state is that we keep only self-signatures and then then
> import again with import-clean (which is then basically identical to
> import-minimal).

What is the difference in the end result between --keyserver-options
self-sigs-only and --import-options import-minimal? I think the former
keeps all self sigs and the latter only the most recent valid self sig?
Is it perhaps possible to incorporate the desired functionality of
self-sigs-only into import-minimal, avoiding another extra option?
Perhaps the extra granularity of self-sigs-only is not a useful feature
for users, and poisoned keys should just be imported by import-minimal
which could automatically imply the current functionality of
self-sigs-only.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Some thoughts on the future of OpenPGP and GnuPG

[Peter Lebbing]

On 01/07/2019 23:36, Stefan Claas via Gnupg-users wrote:
> I think *flame on* Werner does not need to change anything,
> because he is in the lucky position do get financed by
> the big boys, so I see no need for him to start doing something
> new like many others (with no financial support) do.

Oh, for the love of...

https://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke

Seriously, ... . I'm going to exercise some restraint here and not write
anything else, because I can't find words to do it politely.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Your Thoughts

[Peter Lebbing]

On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote:
> Null modem transfer of your messages?  Yikes.  To me that’s the issue
> with PGP in general as it relates to secure communications

None of any of the alternatives to OpenPGP you mention solve the issue
that a secure offline system sets out to solve. They are orthogonal
issues.

Alternatives to OpenPGP have the same need or lack of need of a secure
offline system as OpenPGP itself. The only difference I can think of
would be in the number of messages disclosed or the range of signatures
that could be faked by a compromise, not the base premise of disclosure
and impersonation.

You might well reasonably object to the UX of OpenPGP. Just not on the
ground that there are people who think about offline secure systems,
that makes no sense to me. The two are unrelated. The only relation I
can think of is that people who think about deploying offline secure
systems probably aren't quickly scared off by an overly complicated
system ;-).

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Peter Lebbing]

On 01/07/2019 11:54, Robert J. Hansen wrote:
> [...]

I think this mail sums up the most important points about this whole
ordeal very well. I completely, wholeheartedly agree. I encourage
everyone to re-read it and internalise it.

The only point not touched upon in this specific mail, I think, is why
people who say that the damage that has been done is not of consequence,
are wrong.

It seems to me that rjh's and dkg's keys will be in many public keyrings
and in many (key) signature chains, and thus have the potential to cause
major problems for many people all around the world when they refresh
their keys. I'd say the consequences of poisoning precisely these
well-connected keys are pretty major. People who depend upon OpenPGP
will find their software is hung and timing out, even when they're not
trying to do anything with these specific public keys: often it's enough
the poison is on the keyring, as far as I can tell. Lacking the
knowledge to fix this, they will no longer be able to check signatures,
and probably be unable to read encrypted messages altogether.

For me, that'd be a nuisance.

For some people, it may have very large real-life consequences.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SKS Keyserver Network Under Attack

[Peter Lebbing]

> "Look, this one guy who just got mugged? [...]

I had to read it twice to distill what I think Mirimir meant, but I
think they meant that if you blacklist/blackhole all affected
certificates, you remove the incentive for the attackers to poison more
certificates since the poison can't spread to the people fetching keys.
Thus stopping the attackers.

I concluded that Mirimir perhaps forgot about that this creates a second
attack model, where you can block keys from being on the keyserver. This
seems like a new problem that means this stopgap measure is probably not
the one we want, since it still provides the incentive for attackers to
poison keys.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ProtonMail and Anonymity

[Peter Lebbing]

On 06/05/2019 16:39, Stefan Claas wrote:
> Maybe I should set-up squid on a VPS and let people register from there,
> while keeping no log files. :-D

The only purpose of that would be to specifically subvert the intentions
and processes of ProtonMail. They have designed a system which chooses
policy based on the source IP (including a different policy for Tor exit
nodes), and you try to subvert this policy selection, and possibly give
a route for spammers to register on the system.

If you don't like their policies, don't use them. Don't try to work
around the policies they impose on the use of their service. You don't
have a right to the use of their services under your conditions.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ProtonMail and Anonymity

[Peter Lebbing]

On 06/05/2019 14:53, Jeff Allen wrote:
> It would be more trivial not to hash the number and say you did.

I think it's a worthwhile thing to point out that they state "because
hash functions are one-way functions, it is impossible to derive your
phone number [...]" without reservations, but that this is a false sense
of security. It is a very limited part of the complete picture, which is
that a Dutch mobile phone number has only 8 varying digits, meaning an
entropy of less than 27 bits, cryptographically laughable. And that an
adversary might not even be interested in reversing the hash at all, but
just to verify that the phone number of their target has been used to
set up a ProtonMail account.

With passphrase hashing, the passphrase should be secret. There's
nothing secret about a phone number or e-mail address. That completely
changes the picture.

For me, it's not so much that I question their methods, it's that I
question their claims. Blanketly stating "it is impossible to derive
your phone number" sounds like security theater to me, and they should
be aware of that if they are the least bit competent. That doesn't sit
well.

I don't expect most of their clients to see through this theater. It is
their job to be open and honest about the consequences of their methods,
so their clients can make an informed choice whether they will go
through with it or not.

My 2 cents,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ProtonMail and Anonymity

[Peter Lebbing]

Hello Stephan,

Something completely different.

What is that link with the binary data in your OP?

I did not click it because I don't know what binary data I'd be handing
to that site. But I see this text on the front page of that site:

> You can also earn FREE TELE TOKENS from our bounty or airdrop programs
> or our referral bonus

I get the ugly feeling this is a referral link. That every time someone
clicks that link of yours, or perhaps only after they use some
functionality there, you get a "referral bonus".

If this is a referral link, I would consider that *extremely* bad form
of you. Made all the worse by you not explaining immediately that it
/is/ a referral link.

Could you please explain what the purpose of the data is? (Even with a
good explanation, I'd consider it basic hygiene to never click such
links, since the explanation cannot be verified).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How to prevent passphrase-caching from within a gpgme-based Python script?

[Peter Lebbing]

On 16/04/2019 23:23, Ángel wrote:
> Of course, you could instead run gpg-agent from python and set
> GPG_AGENT_INFO there. The gpg python package is calling gpg under the
> hood, so it should pick the GPG_AGENT_INFO variable from the
> environment.

GPG_AGENT_INFO is obsolete and unused in GnuPG 2.1+ (and GnuPG 2.0 is
obsolete itself :-). So I'm afraid that won't work.

The agent and the homedir are tightly coupled. If you want to do
something special to the agent, I think you're going to have to go the
undesirable route of a separate homedir...

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[Peter Lebbing]

On 13/04/2019 14:34, Peter Lebbing wrote:
> Either reload the agent (this will make it forget all passphrases)

Of course I should have made that explicit. You reload the agent by:

$ gpgconf --reload gpg-agent

I should mention this before you start figuring out a way to send it
SIGHUP (which btw would also work fine, it's just that you need a PID
then).

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-preset-passphrase installation and usage

[Peter Lebbing]

Hello!

On 13/04/2019 12:42, Walia, Gaurav (333G) via Gnupg-users wrote:
>   * gpg --version
>   o gpg (GnuPG) 2.0.22

This version is a full six years old. Not only is 2.0.22 unsupported,
the whole 2.0 branch has been end-of-life for a good bit more than a
year now.

How come you're using something ancient that upstream doesn't support
and which has known defects? Is this a distribution-supported version?
If there is no security support from any party, I think you should
switch to a supported version.

>   * Setup gpg-preset-passphrase
>   o gpg-preset-passphrase --preset 
> 8910891089108910891089108910891089108910
>   * Now when you login to that key and enter the passphrase It should cache 
> it until you issue the following command to remove it.
>   o gpg-preset-passphrase —forget 8910891089108910891089108910891089108910

No, that's not how gpg-preset-passphrase works. You supply the
passphrase on the invocation of gpg-preset-passphrase. And you use the
keygrip, not the fingerprint. You can find the keygrip with the
--with-keygrip option when listing the key.

You would supply the passphrase on stdin of gpg-preset-passphrase,
probably from some utility that got it from the operator. Or with the -P
command line option directly, but this makes it visible for any user on
the system through the process list.

There is no feedback if either keygrip or passphrase is wrong. The net
result is simply you'll get a pinentry pop up when you try to use the
key.

And it will only cache it up to max-cache-ttl as mentioned in the man
page for gpg-preset-passphrase, so you probably want to not remove that
option from gpg-agent.conf.

Alternatively, you could just set default-cache-ttl to whatever value
you desire and completely forego gpg-preset-passphrase. Because it
sounds like you are okay with just supplying the passphrase on the first
invocation, it seems?

gpgconf tells us that the data type of the TTL options is uint32, so you
can make a TTL of 136 years. I notice you use a NASA e-mail address.
This TTL might be a problem on an unmanned spacecraft, but somehow I'll
expect your use case is covered ;-). (Plus, max-cache-ttl always limits
it to the 136 years anyway)

If you did not use gpg-preset-passphrase to preset the passphrase, you
can't use gpg-preset-passphrase --forget to clear it again. Either
reload the agent (this will make it forget all passphrases), or issue:

$ gpg-connect-agent 'clear_passphrase --mode=normal KEYGRIP' /bye

I'm not sure whether that last method is future-proof or might change in
some new version. In other words, I don't know if it's part of the API
or an implementation detail.

I did these things on the distribution-provided GnuPG on Debian
stretch/stable. So it's possible that it works differently on different
versions.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Documentation for agent and scdaemon interaction (Assuan protocol)

[Peter Lebbing]

On 12/04/2019 04:57, Matheus Afonso Martins Moreira wrote:
> Is this gpg-agent command not documented?

For direct interaction with the agent and scdaemon, my first
documentation source is always the inline help. Only when I need more
than that will I look for more sources.

Talking to scdaemon is done by prefixing your command with "SCD ".

--8<---cut here---start->8---
$ gpg-connect-agent 
> help
# NOP
# CANCEL
[...]
# KEYTOCARD [--force]
OK
> help keyinfo
# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
[...]
# 
# More information may be added in the future.
OK
> scd help
# NOP
# CANCEL
[...]
# KILLSCD
OK
> scd help learn
# LEARN [--force] [--keypairinfo]
[...]
#   
# Note, that this function may even be used on a locked card.
OK
> /bye
--8<---cut here---end--->8---

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Generating revocation certificate

[Peter Lebbing]

On 12/04/2019 01:32, Ángel wrote:
> The alias will only be expanded on an interactive shell

Thanks for this piece of information! I'm rather cautious when it comes
to these shell modes of operation. I think I'm understanding it
reasonably well now, but have been surprised about behaviour in the
past.

I note the Bash Reference Manual says:

| For almost every purpose, shell functions are preferred over aliases.

This use-case sounds like the "almost" bit :-).

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How do I delete secret subkeys correctly?

[Peter Lebbing]

On 11/04/2019 16:06, Matheus Afonso Martins Moreira wrote:
> Public key list confirmed deletion of the subkeys from my public key
> but the secret key list still included all my revoked subkeys.

Could you provide an example? I find this rather surprising, that -K
would ever list more than -k.

> The public key packets were promptly redownloaded and reintegrated
> into the keyring when I searched for my user ID.

Yes, that is expected behaviour. You can't delete stuff from the
keyserver, and everything that is valid will be incorporated into your
copy when you fetch it.

> I don't understand why --edit-keys would work now,

I cannot reproduce this on Debian stable with 2.1.18. I think you might
be misinterpreting the result, so I've built a step by step "lack of
reproduction" with comments.

What might be misleading: you say you are dealing with revoked subkeys.
Unless you specify "--list-options show-unusable-subkeys", you might not
see those in the keylistings even though they are there.

--8<---cut here---start->8---
$ gpg --with-keygrip -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
  8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
  Keygrip = 97A3F4843F1B7669524F066472CFA935F23D7574
uid   [  undef ] Testkey
ssb   rsa3072 2019-04-11 [E] [expires: 2021-04-10]
  Keygrip = 6D610FB78404E0C80954BB993E3410ED9FA463A6
--8<---cut here---end--->8---

The gpg binary only deals with public keys in the keyring directly.
Secret keys are delegated to gpg-agent, and gpg-agent works with
keygrips only, so to take a closer look we need the keygrip. Note that
the subkey above starts with the word "ssb" without a suffix, indicating
this is an available key. If the secret part were not available, it
would say "ssb#". So we expect that if we query the gpg-agent directly,
it will hold that key.

--8<---cut here---start->8---
$ gpg-connect-agent 
> keyinfo 6D610FB78404E0C80954BB993E3410ED9FA463A6
S KEYINFO 6D610FB78404E0C80954BB993E3410ED9FA463A6 D - - - P - - -
OK
> /bye
--8<---cut here---end--->8---

It does. I'm exporting the public key now to be able to do something
similar to "fetching from the keyserver".

--8<---cut here---start->8---
$ gpg -o test.gpg --export 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
File 'test.gpg' exists. Overwrite? (y/N) y
--8<---cut here---end--->8---

Let's delete that pesky subkey with delkey.

--8<---cut here---start->8---
$ gpg --edit-key 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa3072/0D72EEEAA1274AE5
 created: 2019-04-11  expires: 2021-04-10  usage: SC  
 trust: never validity: undefined
ssb  rsa3072/E7ED2961F743E804
 created: 2019-04-11  expires: 2021-04-10  usage: E   
[  undef ] (1). Testkey

gpg> key 1

sec  rsa3072/0D72EEEAA1274AE5
 created: 2019-04-11  expires: 2021-04-10  usage: SC  
 trust: never validity: undefined
ssb* rsa3072/E7ED2961F743E804
 created: 2019-04-11  expires: 2021-04-10  usage: E   
[  undef ] (1). Testkey

gpg> delkey
Do you really want to delete this key? (y/N) y

sec  rsa3072/0D72EEEAA1274AE5
 created: 2019-04-11  expires: 2021-04-10  usage: SC  
 trust: never validity: undefined
[  undef ] (1). Testkey

gpg> save
--8<---cut here---end--->8---

I'm immediately suspicious. If it would have deleted the secret part,
I'd have expected a popup from gpg-agent asking me if I was sure about
that. I got no popup. Let's see whether we still have the secret key
available (with the keygrip).

--8<---cut here---start->8---
$ gpg-connect-agent
> keyinfo 6D610FB78404E0C80954BB993E3410ED9FA463A6
S KEYINFO 6D610FB78404E0C80954BB993E3410ED9FA463A6 D - - - P - - -
OK
> /bye
--8<---cut here---end--->8---

Yep, the secret key material is still in our GnuPG homedir. Let's look
at gpg -K and then re-import the public stuff.

--8<---cut here---start->8---
$ gpg -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
  8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
uid   [  undef ] Testkey

$ gpg --import test.gpg 
gpg: key 0D72EEEAA1274AE5: "Testkey" 1 new signature
gpg: key 0D72EEEAA1274AE5: "Testkey" 1 new subkey
gpg: Total number processed: 1
gpg:new subkeys: 1
gpg: new signatures: 1
$ gpg -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
  

Re: Generating revocation certificate

[Peter Lebbing]

On 11/04/2019 02:37, Ángel wrote:
> Why should I need to remember to manually add that .'2' every time?

Because, as I said, it might silently corrupt the functioning of a
utility that expects "gpg" to be 1.4 and not 2.1. There are quite a lot
of utilities out there that parse the output of the gpg command in a way
that is not sufficiently robust. The different output generated by 2.1
might cause such a utility to misinterpret it, and silently accept an
invalid signature. The purpose of calling gpg to verify a signature was
surely to reject invalid signatures, so you might expose yourself to
attackers that way.

Depending on how the utility calls "gpg", it might be affected by your
alias and end up calling "gpg2".

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How do I delete secret subkeys correctly?

[Peter Lebbing]

On 10/04/2019 17:24, Peter Lebbing wrote:
> gpg> delkey

Sorry, my fatigued head was being silly. That's for deleting the public
part, not the secret part. I don't think I know the way to delete the
secret part when you just want to delete some subkey.

Sorry,

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 <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How do I delete secret subkeys correctly?

[Peter Lebbing]

On 10/04/2019 15:25, Matheus Afonso Martins Moreira wrote:
> If not, what is the correct way to do this?

$ gpg --edit-key [KEYID]
gpg> key N
gpg> delkey

Where N is the number of the subkey you want to delete; they are
numbered 1 for the first one listed and so on. It will indicate with a
"*" next to the "ssb" line which one(s) you have selected. Deselect by
another "key N"; it's a toggle.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Please ignore: Storing key on multiple smartcards

[Peter Lebbing]

Sorry for the noise. This message was intended to go to gnupg-devel, but
I screwed up. Please ignore it.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Storing key on multiple smartcards

[Peter Lebbing]

I agree that GnuPG would benefit from preferring keys that are
available, both in the sense of different subkeys and different
smartcards with copies of the same subkey, in the sense you describe.
But let me pick out one detail you mentioned that is a different issue.

On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote:
> Currently "keytocard" replaces the keygrip with a shadow key (which I
> don't think works pretty intuitively in case of multiple smart cards,
> as it requires users to manually back up the subkey beforehand to
> transfer the same key to multiple cards)

It's less difficult than that. After a "keytocard", simply exit the
--edit-key interaction without saving, and the key will still be
on disk as well. So use "quit" or Ctrl-D rather than "save", and
confirm that you wish to exit without saving changes.

Not really intuitive, but less bothersome than backups and restores. I
think maybe "keytocard" should have an option to just leave it on disk
as well. And then you can just insert all your smartcards you want the
key on and "keytocard" them one after the other without exiting the
--edit-key menu.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Generating revocation certificate

[Peter Lebbing]

Hi André,

On 06/04/2019 21:21, André Ockers wrote:
> which would probably be a bad idea, wouldn't it?

Quite! :-)

Your operating system probably still requires GnuPG 1.4, so you can't
remove it. But you can solemnly pledge not to use it... I wouldn't mess
with the "gpg" binary, though. Don't use some method to prevent your
access to it, or you might silently corrupt some utility that you use
under your user account that expects it to be 1.4.

This was all quite an ordeal for Debian to get right, there are a lot of
subtleties to deal with. I really think your best bet is to get that "2"
suffix in your muscle memory for when you use the command line.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Generating revocation certificate

[Peter Lebbing]

On 06/04/2019 18:50, Jean-David Beyer via Gnupg-users wrote:
> Mine's bigger than yours (older, too):
> 
> $ gpg --version
> gpg (GnuPG) 2.0.14

Yeah, and it's probably high time to put gramps out to pasture as
well... ;-) That's a seriously old, unsupported version.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Generating revocation certificate

[Peter Lebbing]

On 06/04/2019 20:24, André Ockers wrote:
>>> gpg: secret key "7CD3FBC8F6005ED5" not found: eof
> I'm using (up to date) Trisquel
> 
> $ gpg --version
> gpg (GnuPG) 1.4.20
> 
> $ gpg2 --version
> gpg (GnuPG) 2.1.11
> libgcrypt 1.6.5

The error message is really unclear, but the problem probably is that
you should have used "gpg2" instead of "gpg", consistently. So just
leave "gpg" behind and only use "gpg2" ever. Well, until an updated
Trisquel drops the old 1.4 and both refer to the same version.

GnuPG 1.4 and 2.1+ do not mix well in certain scenarios. You probably
encountered one.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: FW: yubikey public key

[Peter Lebbing]

Hi Jennifer,

On 04/04/2019 16:16, Mead, Jennifer wrote:
> What other folks are struggling with (just guessing this is the issue)
> is that when they dump the public key (to move to another server and
> add to the authorized_keys file) they get a different style output
> than I do.  I get a string that ends with cardno: and they
> get a regular key (bigger and without card reference).

I think what you are looking for is

$ ssh-add -L

which will dump all the public keys known to the SSH agent. If properly
set up, your SSH agent will be gpg-agent, unless I misunderstand your
scenario.

The others are probably looking at an OpenPGP public key rather than an
SSH public key (again, a guess).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: card-sized 4 Kbit RSA Smartcard recommendation with 3 slots

[Peter Lebbing]

On 04/04/2019 14:06, Thomas Glanzmann wrote:
> I'm looking for a recommendation for a cardsized 4 kbit RSA smartcard
> with 3 keyslots

Well, the ZeitControl card, which was the first OpenPGP Card on the
market, is now at version 3.3 which would seem to support what you ask
for.[1] I have no personal experience, I do have v2.0 cards (and v1.1).

I don't expect 4k RSA to be very snappy, though. You might want to
reconsider your choice of algorithm and/or length.

> At the moment I use yubikey but I aquired a laptop with a smartcard
> reader that I would like to use in order to free up an USB slot.

Be warned that there are many cardreaders that will not work with larger
keys (where "larger" can already mean 2k) or even work reliably at all
with free software. So your mileage may vary a lot.

HTH,

Peter.

[1] 


-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How to tell gpg not to start gpg-agent on a remote machines when using gpg agent forwarding

[Peter Lebbing]

On 04/04/2019 14:03, Thomas Glanzmann wrote:
> Is there a configuration option that I can specify so that gpg gives
> up is there is no socket or no agent behind a socket instead of
> starting a new agent?

From the man page:

| --no-autostart
|   Do not start the gpg-agent or the dirmngr if it has not yet been
|   started and its service is required.  This option is mostly use‐
|   ful on machines where the connection to gpg-agent has been redi‐
|   rected to another machines.   If  dirmngr  is  required  on  the
|   remote  machine,  it  may  be  started  manually  using  gpgconf
|   --launch dirmngr.

If you want to put this in the gpg.conf configuration file, drop the two
leading dashes (this is generally the case).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Please start a new thread

[Peter Lebbing]

Hello Shweta,

Seeing how you did not start a new thread, I get the feeling we "scared
you off" from posting. That is really unfortunate, and not our intention
at all. I'm sorry if you felt intimidated by the response you got.

It's rather unusual, but I took the liberty of posting your question to
the mailing list again, but now not by replying to an existing mailing
list post but addressing a mail to . And
subsequently answering the question to the extent I could.

Let me conclude by copying the part of the list information page[1] that
pertains to basic rules of conduct. The rules are there to make
communication easier; for instance, if you don't trim your quotes it
becomes an effort just to read the flow of the conversation. People who
might otherwise have insightful stuff to add might have given up
reading. And if someone searches the list archive to find if someone
else was already helped with the same problem they're having, it should
be possible to quickly navigate through large amounts of conversation.
That is also why it's important to have one thread deal with one subject
only (or a set of closely related subjects at least :-).

> The topic of this is list is help and discussion among users of GnuPG.
> This includes questions on how to script GnuPG, how to create or sign
> keys and general discussion on encryption and digital signatures as
> long as it somehow pertains to GnuPG. 
>
> The contents of all messages sent to this mailing list is assumed to
> be in the public domain but posted code snippets or patches are under
> their respective license. Do not post any material which may not be
> published. Take care before posting; retracting a post is in general
> not possible. Please write only in English, *avoid* *top* *posting*
> *and* *strip* *quotes* to the necessary minimum. 
>
> Some kinds of postings will not be accepted: e.g. large ones, mails
> without the list name in the To: or CC: header and HTML mails. Your
> mail client does have an option to send plain text only messages; try
> this if you don't get your posting through or notice it in the
> archive.

HTH,

Peter.

[1] https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
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 




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Stop popup which asks for the passphrase

[Peter Lebbing]

Hello Shweta,

> gpg --batch --passphrase-fd n and it stops popup which asks for the
> passphrase. but when I run this command on window server 12 it's not
> working its always show popup for the passphrase.

It is not clear to me which versions of GnuPG you are using. Using a
recent version, but on Linux, I cannot reproduce that this command
works, so I agree with Windows there.

What works for me is:

$ gpg --batch --pinentry-mode loopback --passphrase-fd n [...]

(obviously filling in a number for n, and continuing with more options
and a command for gpg).

With older versions of gpg-agent, it might be necessary to specify the
following in ~/.gnupg/gpg-agent.conf (rather, its location on your OS of
choice):

allow-loopback-pinentry

but this is the default now.

As a full working example, this works for me:

$ echo Hi | gpg --batch -o test.gpg -u 1819B624D400781C8988105EC97A5BCE0BFBF628 
--passphrase-fd 3 --pinentry-mode loopback -s 3<



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Stop popup which asks for the passphrase

[Peter Lebbing]

I'm reposting a question[1] asked by Shweta Tyagi in a different thread,
so it is in its own thread. I feel Shweta might have chosen to seek
their answer elsewhere after they only got unhelpful responses there,
and I'd like to rectify that.

Shweta asked:

Hi All,

I am using the following command

gpg --batch --passphrase-fd n and it stops popup which asks for the
passphrase. but when I run this command on window server 12 it's not
working its always show popup for the passphrase. can someone please
help me how can I stop popup on window server 12.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2019-March/061789.html

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Please start a new thread

[Peter Lebbing]

Hi Shweta,

On 26/03/2019 12:30, Shweta Tyagi wrote:
> How can start a new thread? Please advise.

Start a new e-mail (rather than replying to one), and address it to
. That will start a new thread.

Oh, I forgot this the previous time, but some mailing list members
might appreciate it if you send a plain-text e-mail rather than one that
has plain text as well as HTML content. If you don't know how to, I
think it is acceptable to send them as you do now (not entirely sure
about how strict that policy is).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Please start a new thread

[Peter Lebbing]

Hi,

On 26/03/2019 12:20, Shweta Tyagi wrote:
> gpg --batch --passphrase-fd n and it stops popup which asks for the
> passphrase

Please start a new thread with your question, it is something completely
different than the thread you replied to.

Thanks,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 26/03/2019 09:16, Werner Koch wrote:
> This lists all keys allowed for ssh with its keygrip (1234. and the
> corresponding ssh fingerprint (SHA256:PTJI).  Details as usual by using
> 'help keyinfo'.

Right, yes, the comment lines in sshcontrol are also really helpful for
keys in sshcontrol.

I should have been more explicit about my weird edge case.

I use OpenPGP cards with a key in the authentication slot which is not
part of any OpenPGP certificate, and is not in sshcontrol. gpg-agent is
fine with this: if I have the card inserted, it will be offered as an
authentication key to SSH servers. If I don't have the card inserted, it
is not offered. This in contrast to the case where you were to add it to
sshcontrol: then it would /ask/ for the card to be inserted if the
server accepts the key. If it is not in sshcontrol, it will not be
offered for SSH authentication.

In this particular case, it is actually very easy to pick the correct
SSH public key, because gpg-agent will add the comment "cardno:XXX",
where XXX is the serial number of the card, to the public key when you
do ssh-add -l or -L.

It is more difficult to find the keygrip, though. While participating in
this thread, I worked from the assumption that the key, for whatever
reason, was not in sshcontrol, to catch edge cases such as this. I don't
know whether there are other edge cases than this specific one where SSH
keys are not in sshcontrol, though. This might be the only one.

The use case I considered is this: I have a card I use on two PC's, but
one of the PC's also has an on-disk SSH key. Some SSH accounts will only
accept the card for authentication, but there are accounts which accept
either key. If I'm on the machine with the on-disk key and my card is
not inserted, it will pick the on-disk key. If I'm on the PC without
the on-disk key, I cannot log in to that account without inserting the
card.

If the card were in sshcontrol, and it were offered before the on-disk
key, I would be prompted to insert the card. But this would be
unnecessary, since I have an on-disk key that will do the job just as
well.

But I have to say I no longer actually use this scenario :-). I did in
the past, though.

What would actually help in this use case, might be to have
--card-status accept a --with-keygrip option. Then you have the
"cardno:XXX" comment in ssh-add to pick the public key or its
fingerprint, and --card-status to find the keygrip.

> (I don't like the base64 encoding becuase it is hard to visual compare,
> but that is how it is)

Yes, I totally agree. And when matching stuff together like we do in
this thread, we don't actually use any cryptographic properties of the
fingerprint, there is no adversary. So MD5 might be easier on the eyes,
but it has the disadvantage that the user needs to be /aware/ that they
can get the same fingerprint format from ssh-keygen, ssh-add and
gpg-agent.  If they just see one format here and another there, they
might very well not realise they can be made to match.

So I'm inclined to think the default should be to output it in the same
format in both tools.

Plus, when it's purely for identification purposes, you can skip reading
more letters of the base64 encoding once you've identified the right
key.

> I fixed that for 2.2.15 so that the above option is considered.
> Further, it is also possible to use

Neat! Thanks!

> p.s.  Eventually someone(tm) should write a GUI tool to list and manage
> all kind of private keys in GnuPG.  For example to list all users of a
> certain private key.

:-)

Sorry for the long mail. I didn't see a lot of opportunity to shorten it
without losing clarity. If I were to introduce a misunderstanding, it
will only take even more time to sort out.

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 25/03/2019 15:45, Werner Koch wrote:
> That is on purpose: gpg-agent stores the key permanently and thus it
> makes no sense to add and remove it regularly.

It might also be "slightly annoying" to remove key material which is
also in use for other purposes :-). You remove an SSH key, and suddenly
an OpenPGP subkey is also missing...

But something more user friendly to match SSH fingerprint and keygrip
could be beneficial. I'm not sure what that would look like and neither
do I think it is high on the priority list.

For one thing, OpenSSH seems to prefer SHA256 SSH fingerprints over the
old MD5 ones now.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 23/03/2019 13:39, Brian Exelbierd wrote:
> How did you import this key?

If your OpenSSH private key is .ssh/id_ed25519, and you are running
gpg-agent as your SSH agent, it's a matter of:

$ ssh-add ~/.ssh/id_ed25519

Any comment on the private key that was already there (presumably
through ssh-keygen's -C option) will be saved in private-keys-v1.d.

I don't use monkeysphere, I just maintain all authorized_keys files by
hand. While I do have files with the public keys, often I'll just use
ssh-add -L to get the public key I need to put in there.

The point where stuff gets interesting is deleting SSH keys. For that I
would use the method I outlined in this thread to get at the keygrip,
because ssh-add -d doesn't work with gpg-agent. Well, not with the
version in Debian stretch anyway, I reserve the right to be ignorant
about features added since then.

> Should I open a feature request on this, or have you already done so?

I don't care enough to open a feature request. The development team's
time is limited after all.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 17/03/2019 13:17, Brian Exelbierd wrote:
> Having done no code examination, I feel like this is where the
> identity information for subkeys comes into play.  I presume the SSH
> request would pass the value of the identity file to the gpg-agent.
> This is probably 100% wrong though/

30% wrong? It actually is "the wire encoding of the public key", so key
material rather than a filename. Your comment made a click in my mind
though. I've solved it.

Put this in .ssh/config:
--8<---cut here---start->8---
Host your-server.com
IdentitiesOnly yes
IdentityFile ~/.ssh/testkey7.pub
--8<---cut here---end--->8---

Where testkey7.pub is a file containing the *public* key. Usually you
would use a private key here, but OpenSSH is just as happy with a public
key as long as the agent can do the private operation.

> Also, as an aside.  It appears that subkeys do not prompt for the key
> passphrase.  Instead I just get an allow/deny dialog or no dialog at
> all if I don't force confirm.

The passphrase is cached. The duration can be controlled through
default-cache-ttl-ssh and max-cache-ttl-ssh in ~/.gnupg/gpg-agent.conf
or on a per-key basis in sshcontrol. It is possible to turn off caching
for SSH keys completely. See "man gpg-agent".

> Distracting myself with GPG/SSH while doing taxes is a bad idea and
> leads to bad internet hygiene :D

Hehehe :-D

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 17/03/2019 12:45, Brian Exelbierd wrote:
> There is no longer an identityfile to use in the .ssh/config file
> which means all auth keys are tried with all hosts.  I have multiple
> auth keys and the hosts give up after 2 or 3 failures.  How can I get
> the right key served to the right host since SSH doesn't know how to
> ask for it anymore ...

Ooohhh. I would have hoped the OpenSSH server's MaxAuthTries would only
count failed signatures, not failed key matches. But I can reproduce
this problem.

Picking an auth key is a two-step process. First the client offers
different public keys until the server says it accepts one. Only then is
authentication tried with the key that was just negotiated. But indeed,
MaxAuthTries counts every *offer* as an auth try and cuts out after 6 in
the default configuration.

--8<---cut here---start->8---
$ ssh -v [...]
[...]
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/peter/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /home/peter/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Just a comment
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 1
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 2
debug1: Authentications that can continue: publickey
debug1: Offering ED25519 public key: Testkey 3
Received disconnect from ::1 port 22:2: Too many authentication failures
Authentication failed.
--8<---cut here---end--->8---

I don't know a satisfactory solution to this.

Peter.

PS: Could you please trim your quotes when you reply on the mailing
list?

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

Hi,

On 16/03/2019 14:22, Dirk Gottschalk wrote:
> In the output from --export-ssh-key is also a comment field. This
> fieldd, in my case shows: openpgp:0xF852DAEE

Yes, but it is only added by the --export-ssh-key command and has a
fixed form. Instead, for my keys, which by the way are not part of an
OpenPGP certificate and therefore can't be used with --export-ssh-key,
they are stored with the private key. The comment got there because they
were originally OpenSSH keys with that comment, and the comment got
retained on import into the agent. I could have put any comment
whatsoever in it and it would have been stored by the agent and shown on
any invocation of ssh-add -{l,L}.

--8<---cut here---start->8---
$ ssh-add -l
[...]
256 SHA256:xb01Ehdlix7o5oLN0YUEkhr70yZDXXCNXcMoNS48PB0 Just a comment (ED25519)
--8<---cut here---end--->8---

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 




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

On 16/03/2019 11:11, Wolfgang Traylor wrote:
> $ gpg2 --export-ssh-key 

Actually, if you want a specific subkey, you need to append a ! to the
key ID (probably need to quote it as well for the shell, \! ).
Otherwise, GnuPG will use key selection rules to take the latest
authentication subkey from the certificate selected.

It's a fine and simple method. The advantage of my method is it will
also work with keys that aren't part of an OpenPGP key :-). Plus it's
more fun.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Identifying one of multiple authentication subkeys

[Peter Lebbing]

Hi Brian,

On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi,
> Either way, I am unsure how to identify which subkey is which SSH key.

Provided the auth keys are in your .gnupg/sshcontrol file, the following
will help:

--8<---cut here---start->8---
$ ssh-add -L | head -1 >firstkey

$ ssh-keygen -l -E md5 -f firstkey 
2048 MD5:69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 
/home/peter/.ssh/id_rsa (RSA)

$ gpg-connect-agent 
> help keyinfo
# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
# 
# Return information about the key specified by the KEYGRIP.  If the
# key is not available GPG_ERR_NOT_FOUND is returned.  If the option
# --list is given the keygrip is ignored and information about all
# available keys are returned.  If --ssh-list is given information
# about all keys listed in the sshcontrol are returned.  With --with-ssh
# information from sshcontrol is always added to the info. Unless --data
# is given, the information is returned as a status line using the format:
# 
#   KEYINFO   
# 
# KEYGRIP is the keygrip.
# 
# TYPE is describes the type of the key:
# 'D' - Regular key stored on disk,
# 'T' - Key is stored on a smartcard (token),
# 'X' - Unknown type,
# '-' - Key is missing.
# 
# SERIALNO is an ASCII string with the serial number of the
#  smartcard.  If the serial number is not known a single
#  dash '-' is used instead.
# 
# IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
#   is not known a dash is used instead.
# 
# CACHED is 1 if the passphrase for the key was found in the key cache.
#If not, a '-' is used instead.
# 
# PROTECTION describes the key protection type:
# 'P' - The key is protected with a passphrase,
# 'C' - The key is not protected,
# '-' - Unknown protection.
# 
# FPR returns the formatted ssh-style fingerprint of the key.  It is only
# printed if the option --ssh-fpr has been used.  It defaults to '-'.
# 
# TTL is the TTL in seconds for that key or '-' if n/a.
# 
# FLAGS is a word consisting of one-letter flags:
#   'D' - The key has been disabled,
#   'S' - The key is listed in sshcontrol (requires --with-ssh),
#   'c' - Use of the key needs to be confirmed,
#   '-' - No flags given.
# 
# More information may be added in the future.
OK
> keyinfo --ssh-list --ssh-fpr
S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S
S KEYINFO 64711FCE432F5387CCDD5E466513387B63096989 D - - - P 
c1:34:c6:23:f7:d5:64:fb:49:7a:d3:53:db:d1:87:64 - S
OK
> 
--8<---cut here---end--->8---

ssh-add was used to export the first key in the agent to a file.
ssh-keygen can produce an MD5 fingerprint for that file for you.

You can match the MD5 fingerprint to the 7th field of KEYINFO. Then the
1st field will give you the keygrip of that SSH key.

If your auth keys are for some reason not in sshcontrol, you could use

--8<---cut here---start->8---
$ gpg-connect-agent 'KEYINFO --list --ssh-fpr' /bye | fgrep 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96
S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 
69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - -
--8<---cut here---end--->8---

because it wouldn't be much fun wading through all your keys if you have
a lot of key material, and that command without the grep will list it all.

(By the way, as you can see in the ssh-keygen output, my key actually
has a comment field in the gpg-agent. It was imported from an on-disk
OpenSSH file, that's where it came from. I don't know a way to have a
comment field for a key generated with gpg, although I could probably
hack it in in the private key store. Let's not do that.)

HTH,

Peter.

PS: I see no reason why you shouldn't have multiple auth subkeys, unlike
John Doe.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

(OT) Formatting mails to this list

[Peter Lebbing]

On 15/03/2019 20:26, Daniel wrote:
> If I may ask you again how your input was meant dear Peter, I should
> add code inline in the future like so(?):
> 
> --8<---cut here---start->8---
> dm@dm-ThinkPad-X240:/boot$ sudo apt-get autoremove 
> linux-image-3.13.0-96-generic
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages will be REMOVED:
>   linux-image-3.13.0-96-generic linux-image-extra-3.13.0-96-generic
>   linux-signed-image-3.13.0-96-generic
> 0 upgraded, 0 newly installed, 3 to remove and 4 not upgraded.
> After this operation, 195 MB disk space will be freed.
> Do you want to continue? [Y/n] 
> --8<---cut here---end--->8---

Yes, that's exactly what I meant :-). That makes it easier on the eyes
to distinguish where prose is and where shell output is.

And when you reply to e-mails, please strip qoutes to the minimum
necessary to provide context. It's a mailing list, so anyone wanting to
read what the previous e-mail said can simply do so in the original
mail. Quoting is only to provide context what you are replying to.

Thanks!

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Newbie: Installing Build Dependencies to gnupg-2.2.13 update from gnupg 2.0.22 on Ubuntu 14.04 LTS failed

[Peter Lebbing]

On 13/03/2019 14:21, David wrote:
> If someone posts hundreds of kilobytes or more, I agree,
> but in this case I argue the opposite, for these reasons.

I fully agree. In fact, I much prefer someone include a lot of
information and maybe include too much than that the person trying to
help has to ask for more information. The one thing that would have made
the mail even better was if shell output was put between markers like
this:

--8<---cut here---start->8---
Terminal contents
--8<---cut here---end--->8---

Some mail clients auto-format this, which makes the e-mail more
readable, but even without special formatting it helps a /lot/ with the
flow.

> 4) it avoids running pastebin javascript.

In fact, Werner refuses to look at pastes on sites that require
JavaScript. That means you lose out on the expertise of the person who
knows the most about GnuPG! :-)

7) This is an FSF mailing list. Solely relying on libre services is much
preferred in any case. Suggesting people use non-free software quickly
ends up in the "not allowed here" territory!

Back on topic, I /do/ completely agree with Oscar Carlsson that it is
rather futile to compile stuff for an OS that will be unsupported in a
few weeks. Running an unsupported OS should not be done in almost every
instance. Running security software like GnuPG on an unsupported OS is
an enormous red flag and defeats the purpose of GnuPG IMNSHO.

My 2 cents,

Peter.

PS: I found it ironic that the person admonishing someone to be concise
was the one who forgot to trim the quotes per list rules :-P. This is
tongue in cheek and should not be taken seriously.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Help with SSH and GPG subkey for authentication

[Peter Lebbing]

On 23/02/2019 12:43, Chris Coutinho wrote:
> I'm not exactly sure what the difference is between that and a fingerprint

A key's fingerprint is something specific to OpenPGP. It includes
OpenPGP-specific information and formats. As such, it is undefined for
an OpenSSH key or a CMS (X.509) key; it simply doesn't exist.

A keygrip is a short representation of an asymmetric keypair's actual
public key material. For example, it is the same for an RSA key whether
that key is used for an OpenPGP key, an OpenSSH key or a CMS key.
gpg-agent works with keygrips because it provides services to all of
OpenPGP, SSH and CMS. And it allows you to use the same material in
multiple formats that way, such as with the Authentication subkey.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Using Yubikey only to encrypt/sign

[Peter Lebbing]

On 18/02/2019 22:39, Farhan Khan via Gnupg-users wrote:
> $ gpg --list-secret-keys farhan@farhan.codes
> sec>  rsa2048 2019-02-18 [SCEA] [expires: 2021-02-17]

Ah, well, there's your problem.

You should not use your primary key for encryption; they invented
subkeys for that.

And with the smartcard, you come into the uncomfortable situation that
the smartcard will decline to decrypt with what it knows is a signature
key, and likewise decline to sign with what it knows is an encryption
key. But both those usages are this key, and there will only be one stub
in GnuPG, which will refer to either a smartcard signature key or a
smartcard encryption key, but not both.

The most straightforward solution is to create an RSA primary key that
does certification and signatures (usage: SC), and an RSA subkey that
does encryption (usage: E). My --full-gen-key calls this option "RSA and
RSA (default)".

You can then upload those keys to the correct slots in the smartcard (it
will decline to pick the wrong slot). But if you wish to use the on-disk
keys after that, and the smartcard somewhere else, you should "Quit
without save", because as you have experienced, it will *delete* the
on-disk key when you "Save and quit" and only use the smartcard key from
then on.

As an aside, I'll note that you could also create a primary key that can
only certify, and a separate subkey that does signatures. That way, you
can have only subkeys on your smartcard, and compromise of the system
you use the smartcard on will only allow the attacker to issue
signatures on documents, but not edit your key or issue signatures on
other /keys/. But this might not be necessary for you, it depends on
what threat model you envision.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey keytocard: "Bad secret key"

[Peter Lebbing]

On 18/02/2019 06:51, Farhan Khan via Gnupg-users wrote:
> This was it, loading a 2048-bit key works just fine
> Thanks Andrew!

First of all, I think it's a much better idea to generate a 2048-bit key
anyway, so it worked out okay.

But the problem is interesting. Before --card-edit gained its key-attr
command, GnuPG would do the correct key-attr stuff automatically to
switch to the desired key length. Maybe it has stopped doing that now,
and you need to do:

$ gpg --card-edit
[...]
gpg> key-attr

to select the desired key length before keytocard.

At the moment, I don't have a version with key-attr at hand to quickly
test myself.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Configuring Linux system mail submission

[Peter Lebbing]

Hi André,

On 16/02/2019 10:34, André Ockers wrote:
>> /etc/mailname: hostname.digitalbrains.com (the actual fully qualified
>> domain name of the local host)
> 
> So what do you do here if you have an emailadress, like
> an...@ockers.eu
> at an email service provider, let's say
> serviceprovider.nl?
> Would that be ockers.eu or serviceprovider.nl in /etc/mailname?

The more domain names, the merrier!

There is no single right answer. These names are used to build e-mail
addresses when you don't specify a fully valid e-mail address when you
send the mail; both for the sender and the recipient addresses. As I
indicated in the previous mail, I think you should avoid the situation
where nullmailer will build e-mail adresses on a domain you don't
control yourself, to prevent annoying people who happen to have the
address that nullmailer builds.

This all simply does not apply to caff, and caff is our intended goal.
But configuring nullmailer might also cause daemons on your computer to
try and start sending e-mails, and that is where it does apply.

I've gone through several iterations of this e-mail. The thing is,
there is no single right answer. There are multiple wrong answers. And
my system is configured differently than yours, so I can't just say
"this works for me", since I know for a fact it will not work for you.
I'm sorry if I'm confusing you. I'm doing my best, but I'm simply not
sure of the *best* solution in this case.

So I hope that this is the best outcome:

First, let's see what your computer thinks it is called. Invoke this:

$ hostname --fqdn

It will give you the domain name of the computer. Let's say this
happened:

$ hostname --fqdn
mario.itsa.me

Then let's put this in the files:

/etc/mailname: mario.itsa.me
/etc/nullmailer/adminaddr: an...@ockers.eu
/etc/nullmailer/defaultdomain: itsa.me
/etc/nullmailer/idhost: ockers.eu

This will cause any e-mails addressed to some-username@mario,
some-usern...@mario.itsa.me and some-username@localhost to end up being
delivered to an...@ockers.eu. They might not succeed, though, because
your e-mail provider might very well reject the sender of the mail. You
should probably check every now and then whether there is anything stuck
in /var/spool/nullmailer/queue.  You can delete any files there and it
will stop trying to deliver that e-mail. You do need to be root to
delete them.

Note that Postfix would probably not do better at delivering those
e-mails. It could be configured to do so, but by default it would not.

And the idhost line prevents the name mario.itsa.me from ending up in
the e-mail headers (specifically, the Message-ID line). It mirrors your
current e-mail setup, which I could see in your e-mail headers. Some
people don't like names from their internal network leaking out to the
big bad internet. But it might still happen in other places.

>> /etc/nullmailer/remotes: mail.digitalbrains.com smtp --port=587 --starttls 
>> --user=peter-nullmailer --pass=[...]
>>
>> That last one is the really important one. It uses the SMTP submission
>> port, STARTTLS, and in my case a password that has been chosen to not
>> require quotes. But you can use quotes to just use your provider account
>> password.
> 
> Would that be
> mail.serviceprovider.nl smtp --port=587 --starttls
> --user=andre-nullmailer --pass=...
> or
> mail.ockers.eu smtp --port=587 --starttls --user=andre-nullmailer --pass=...
> in /etc/nullmailer/remotes?

This is the same as when configuring your e-mail client. If your e-mail
service provider has given you the following outgoing mail server
settings:

Outgoing mail server: smtp.serviceprovider.nl
User name: some-usern...@serviceprovider.nl
Password: lalala

Then the line becomes

/etc/nullmailer/remotes: smtp.serviceprovider.nl smtp --port=587 --starttls 
--user=some-usern...@serviceprovider.nl --pass=lalala

Some providers will use a full e-mail address as user name, others just
the bit before the @.

You could take a look in your e-mail client software (which clearly
works) and see what it has there for outgoing mail server settings. That
probably will not show you the password right away.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Configuring Linux system mail submission

[Peter Lebbing]

Hi André,

On 10/02/2019 15:36, André Ockers wrote:
> Following documentation [1], I checked that I have Postfix installed and
> now I'm here [2]

I had feared it would break down at the mail configuration stage :-). I
have mail servers running with a hand-managed config file with Exim 4,
but I know nothing about Postfix. However, for mail submission, I use
nullmailer myself. It can only do mail submission, but is much easier to
manage than a full mail system (in my opinion).

So I don't know if you installed Postfix for this purpose or actually
use it for a real mail server, but if you can switch to nullmailer that
would allow me to easily help you, probably.

Personally, I run nullmailer on all systems that are not running a
full-fledged mail server, and they connect to my edge mail server for
mail submission. You can just use any SMTP-supporting provider for the
latter.

When installing nullmailer on Debian, it will ask you interactively for
entries for files in /etc and /etc/nullmailer. Mine look like this:

/etc/mailname: hostname.digitalbrains.com (the actual fully qualified
domain name of the local host)

/etc/nullmailer/adminaddr: empty file

/etc/nullmailer/defaultdomain: digitalbrains.com

/etc/nullmailer/remotes: mail.digitalbrains.com smtp --port=587 --starttls 
--user=peter-nullmailer --pass=[...]

That last one is the really important one. It uses the SMTP submission
port, STARTTLS, and in my case a password that has been chosen to not
require quotes. But you can use quotes to just use your provider account
password.

I believe /etc/mailname is primarily used to build the sender address
and build recipient addresses that specify no host, i.e., something like
. /etc/nullmailer/defaultdomain is used for not fully qualified
hosts, i.e., if I write  it will qualify the hostname
butters with that domain name. It's not that important for this purpose.

There is one more detail to get right. Because this will actually make
the mail originate from the user  in
this example and a username of peter. This is probably not what you
want, you want  if you're me. If this is always
what you want when sending mail through the system mailer, you could
make sure the following environment variables are set for this user:

MAILUSER=p.lebbing
MAILHOST=provider.nl

If you're anxious about changing environment variables that have
influence over programs other than nullmailer, you can use
NULLMAILER_USER and NULLMAILER_HOST instead.

But for me, the  is actually an e-mail
address that will be accepted on the right side of my firewall, and is
used for system messages from, e.g., cron. It is not the address I want
for caff, though. But caff does the right thing already by specifying
the e-mail address you want in ~/.caffrc:

$CONFIG{'email'} = 'p.lebb...@provider.nl';

This will automatically set both the envelope sender and From: to that
address.

One remark: the hostname from /etc/mailname is used to build 
the Message-Id: header. If you'd like to hide that, you could set:

/etc/nullmailer/idhost: provider.nl

I think that mirrors Thunderbird's behaviour, taking a peek in my "Sent"
folder.

You could also arguably just set /etc/mailname to provider.nl and drop
the MAILHOST env variable in the process, but I'd feel slightly anxious
over accidentally building mail addresses of other customers of my
provider as if they were the sender, so I wouldn't do that. Imagine your
webserver started sending mails from  accidentally
that way, or ... these might annoy your provider. And
it gets worse with a regular user account, let's call her Anna. She
might not control .

I think that covers it. You can try stuff from the command line to see
what it becomes without actually sending with:

$ nullmailer-inject -nv http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Keysigning party: after the event challenges

[Peter Lebbing]

Hello André,

On 09/02/2019 09:06, André Ockers wrote:
> - 171 official keysigning party participants, of who 107 showed up to my
> awareness;

This is going to be a pain to do manually. But you don't have to! As the
FOSDEM keysigning party page[1] notes, "You may find caff a helpful tool."
(last sentence of the page, not counting the footer).

If you open your ksp-fosdem2019.txt file and put "x" in every checkbox
you have checked on your paper list, you can feed this text file with
checkmarks directly to caff and it will import the keys for you *and*
verify their fingerprints! It will only consider entries with checkmarks
for both "Fingerprint OK" and "ID OK", so only when the participant has
acknowledged their fingerprint matches and you have marked that you find
their identification papers match.

The FOSDEM KSP offers a keyring with all the keys from the party. You
can feed that to caff as well and it won't even need to fetch the keys
from a keyserver (which might not have all keys).

My suggestion is to look for "caff" and documentation and try that
before you verify 107 fingerprints manually :-). If you still hit
problems, report back here and we can take a further look.

> - 5 participants have a key on the keyserver in a for Enigmail
> downloadable state;

That sounds odd, there might be something malfunctioning. But if you use
caff, you don't need Enigmail. And if you use the supplied keyring from
the party, you don't need to use a keyserver at all.

HTH,

Peter.

[1] https://fosdem.org/2019/keysigning/

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: OpenPGP on paper

[Peter Lebbing]

On 01/02/2019 17:37, Stefan Claas wrote:
> Tesseract did not do a good job, to many errors.

Just an idea: OCR'ing a special OCR font like the two classics I
mentioned will go a lot better if the OCR engine *knows* it is looking
at that font. They designed the glyphs to be dissimilar. I don't know if
there are any free software OCR engines that can restrict themselves to
a specific font, I'm just reasoning about it without domain knowledge.

Also, if you choose an encoding that avoids similar glyphs like one and
ell, zero and oh, etcetera, your miss rate should go down.

> Then i googled a bit and ... Google can do it.

That doesn't seem useful for secret letters. And I don't think you'll
get an offline engine which has been trained like theirs from them.

HTH,

Peter.

PS: Could you removed the (was: ...) bit from the subject in replies? I
think I'll stop doing that type of formatting from now on. I saw it
being used quite some time back and when it works it's okay, so I
followed suit. But it's not working that well anymore.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

OpenPGP on paper (was: Where can I find some papers to read on mail (and envelope) security?)

[Peter Lebbing]

(Changed the subject because we went off-topic on an off-topic thread
and in doing so went back on-topic for the mailing list! :-)

On 30/01/2019 20:44, Stefan Claas wrote:
> But which one ... ;-) I may check this again with a friend.

Well there are the classical options:



Debian provides free fonts like that as packages fonts-ocr-a and
fonts-ocr-b, which come from:

and


> The new jabcode (color barcode) from Germany's Fraunhofer Institute
> is pretty cool

Oh, nice. My bank uses something similar (you get a device with a camera
you point at your webbrowser screen), but this is an open standard,
that's much better.

Cheers,

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users