Re: Finding all files encrypted with a certain key

[raf via Gnupg-users]

On Wed, Oct 25, 2023 at 09:38:55PM -0500, Jacob Bachmeyer via Gnupg-users 
 wrote:

> raf via Gnupg-users wrote:
> > [...]
> > While testing these, I just noticed that /usr/bin/file
> > on my macOS-10.14 laptop shows a different keyid to
> > what libmagic shows. That's bizarre.
> > 
> > For some encrypted files of mine, /usr/bin/file (v5.33)
> > shows 3A0FC449 817C22BA but libmagic/rh shows 49C40F3A
> > BA227C81 for the same files. A more recent version of
> > file (v5.45) installed via macports shows the same as
> > libmagic/rh. So choose your version of file(1) wisely. :-)
> 
> You have an endianness-mismatch issue somewhere.  The octets are reversed in
> each 32-bit group between the samples.
> 
> -- Jacob

Well spotted! Thanks. The actual endianness wouldn't have changed,
but file's presentation of it much have been fixed (to match
gpg output) between those versions.

cheers,
raf


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

Re: Finding all files encrypted with a certain key

[raf via Gnupg-users]

On Thu, Oct 26, 2023 at 11:29:38AM +0800, "Felix E. Klee"  
wrote:

> On Wed, Oct 25, 2023 at 9:23 PM Werner Koch  wrote:
> > > gpg: decryption failed: No secret key
> > >
> > > I wonder how to get rid of that.
> >
> > grep -v on stderr ;-).
> 
> Thanks, I was thinking about that. But I think simply using find, as
> suggested by Andrew and raf, is sufficient and simple.

rh intead of find+n*(sh+file+grep) is even simpler (but I'm biased). :-)

> > I think it is time to make things like this easier. Actually
> > re-encrypt support has been on our feature list for many years.
> 
> That would be fancy. Personally, I’m happy with a bit of shell
> scripting. My use case is rather simple, and I don’t need to do
> re-encryption very often.

Yeah. I think gpg -d ... | gpg -e -r ... is simple enough. I use that
(in a "recrypt" python script) for annual key rollover re-encryptions
of many database backups.

cheers,
raf


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

Re: Finding all files encrypted with a certain key

[raf via Gnupg-users]

On Wed, Oct 25, 2023 at 11:01:30AM +0800, "Felix E. Klee"  
wrote:

> On Tue, Oct 24, 2023 at 5:12?PM Andrew Gallagher 
> wrote:
> > GNU `file` will print the encryption key ID:
> 
> Interesting. I wonder if there is any disadvantage of using `file` over
> Werner's proposal.

I don't think so. The version you are quoting didn't
use find(1) as well, so it doesn't search recursively,
but apart from that, using file would be simpler (no
decryption, and no need to think about pinentry, and no
need to access keys). If the files you are searching
for are gigabytes in size, and there are many of them,
decrypting them to find the key would be too slow,
unless I've misunderstood something. file would read
much less of each file. No, gpg would die with SIGPIPE
as soon as awk terminates, so they probably read a
similar amount. And they both use multiple additional
processes for each candidate file (either sh+file+grep
or sh+gpg+awk).

cheers,
raf


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

Re: Finding all files encrypted with a certain key

[raf via Gnupg-users]

On Tue, Oct 24, 2023 at 11:38:52AM +0800, "Felix E. Klee"  
wrote:

> For the purpose of re-encryption with a new key, I’d like to find all
> files that are encrypted with my key BEF6EFD38FE8DCA0. All encrypted
> files, independent of key, have the extension `.gpg`.
> 
> How do I do that for a massive directory tree?

With my rawhide (rh) program (github.com/raforg/rawhide) you can do
it with something like this:

 rh /path '"*.gpg" && "*PGP*encrypted*BEF6EFD3 8FE8DCA0*".what'

That looks under /path for files whose names end in .gpg and
whose file(1) output would contain the given glob pattern,
but no file(1) processes are created. The output of file(1)
for an encrypted file looks something like:

 file.gpg: PGP RSA encrypted session key - keyid: 49C40F3A BA227C81 RSA 
(Encrypt or Sign) 4096b .

It can also be done with find(1) of course, but it's a
little slower because it needs additional processes for
each encrypted file:

 find /path -name '*.gpg' \
  -execdir /bin/sh -c 'file {} | grep -q "PGP.*encrypted.*BEF6EFD3 8FE8DCA0"' 
\; \
  -print

But the extra time is probably immaterial when followed
by re-encryption.

While testing these, I just noticed that /usr/bin/file
on my macOS-10.14 laptop shows a different keyid to
what libmagic shows. That's bizarre.

For some encrypted files of mine, /usr/bin/file (v5.33)
shows 3A0FC449 817C22BA but libmagic/rh shows 49C40F3A
BA227C81 for the same files. A more recent version of
file (v5.45) installed via macports shows the same as
libmagic/rh. So choose your version of file(1) wisely. :-)

Also, in case you need to re-encrypt regularly, I
recommend assigning some label to the key and putting
it in the filename (e.g. blah.gpg.key23). Then you
don't need to look inside the file, and if it takes a
long time to re-encrypt lots of files, you can easily
see how it's progressing.

cheers,
raf


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

Re: Management of background services with systemd

[raf via Gnupg-users]

On Wed, Mar 01, 2023 at 09:24:35PM -0500, Michael Richardson 
 wrote:

> 
> David Joaquín Shourabi Porcel  wrote:
> > I am researching GnuPG for my employer. We will stick with the old
> > release series 2.2 at first, because few Linux distributions package
> > 2.3 or 2.4 yet. However, I'm studying newer versions and recent
> > developments to ease our future upgrades. In doing so, a question has
> > arisen: should background services like the agent not be managed with
> > systemd?
> 
> Please no.
> 
> It's bad enough as it is when you have multiple personalities you are trying
> to support (signing as me, vs signing code with an offline key)... having
> systemd (the userland one) popping off new copies would be horrible.
> 
> Combined with SSH access to the machine, and the passphrase/pin popup shows
> up in the wrong place.
> 
> (And many of us do not trust systemd and do not run it on important machines)

Having systemd control gpg-agent can be a huge problem
even with a single personality. If you want a user to
login via ssh to start an agent to temporarily store a
passphrase, and then the same user logs in separately
via ssh to make use of it, systemd treats them as
different user sessions, each with their own gpg-agent,
and the second one has no access to the passphrase
setup for it by the first one. Presumably, this isn't a
problem for most use cases, but it really spoiled
things for me.

cheers,
raf


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

Re: mutt locking

[raf via Gnupg-users]

On Tue, Oct 25, 2022 at 05:16:10PM +0200, Bernhard Reiter 
 wrote:

> Am Freitag 23 September 2022 18:19:42 schrieb Louis Holbrook via Gnupg-users:
> > - I would like to use pinentry-tty during my normal gpg cli operations.
> > - I am fine with using pinentry-curses in the mutt context
> >
> > Is there a way to do this?
> 
> FWIW: Probably not, as the pinentry is a configuration of gpg-agent.
> In theory you could start a new gpg-agent with a different configuration 
> option, but pinentry-curses really so bad? :)
> 
> Bernhard

I find it to be really bad when used from within gvim.
The display doesn't work at all (for me), and most of
the time, I end up with a runaway process afterwards
consuming all the CPU which I have to kill manually. I
think pinentry-tty is the only pinentry program that
works in all of the environments that I need it to.

It might be possible to configure gpg-agent to use a
local script as the pinentry program, and that script
distinguishes between use in mutt and everything else
(perhaps by setting an environment variable whenever
mutt is launched), and then execs the preferred
pinentry program for each environment.

cheers,
raf


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

Re: Questions re auto-key-locate

[raf via Gnupg-users]

On Tue, Feb 15, 2022 at 12:32:50PM -0800, "Dan Mahoney (Gushi) via Gnupg-users" 
 wrote:

> Hey all,
> 
> A long time ago I wrote a doc on a blog about putting PGP keys in the DNS,
> which has been linked to quite a bit.  I also recoded make-dns-cert as a
> shell script so that people who want to do this but don't have access to the
> make-dns-cert tool (which is not built by default on some OS packages) had
> an option to do this.
> 
> At the day job, we have a script that we use to push gpg-signed releases to
> our FTP server, and as part of that job, it verifies the signatures on the
> tarball, and will try to auto-key-locate those keys if it can't find them.
> 
> Since the debacle a few years ago with the SKS keyserver denial-of-service
> attack, the keyservers are kind of a non-starter.  And because GPG searches
> for keys on a tarball by keyid, not by user@domain, a keyserver is the only
> real retrieval method available to look up a key by keyid, which is now a
> non-starter.
> 
> Worse still, if you know a key exists via something like DANE (dayjob makes
> DNS software, we like the idea of it being available via DANE), there's no
> way to do gpg --search via DANE, only via a keyserver.
> 
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.
> 
> -Dan
> 
> (PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate a
> key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt."  It
> should probably say RFC7929 rather than referring to an I-D.)
> 
> -- 
> 
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> FB:  fb.com/DanielMahoneyIV
> LI:   linkedin.com/in/gushi
> Site:  http://www.gushi.org
> ---

Hi,

Recently, I asked for dane to be added to --auto-key-retrieve
when dane was in the auto-key-locate list (https://dev.gnupg.org/T5586),
but the outcome was: "Wontfix: DANE has been an experimental thing
and is imho dead".

I think that experiment might have taken place at a time when DNSSEC
was too much effort to implement. That's not longer the case, so maybe
the experiment should be allowed to continue.

But maybe it is dead. I don't really need it. My only interest was that
I'd written software that manages dane records (including openpgpkey),
but I don't know if anyone else is using that feature. Probably not.

cheers,
raf


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

Re: [Announce] A New Future for GnuPG

[raf via Gnupg-users]

On Mon, Jan 03, 2022 at 08:19:26AM +0100, Werner Koch via Gnupg-users 
 wrote:

> Hello and a Happy Gnu Year!

Happy Gnu Year indeed!

Congratulations on the marvellous news,
and many thanks for all that you do.

cheers,
raf


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

Re: User id's without person's name, only email

[raf via Gnupg-users]

On Wed, Nov 17, 2021 at 04:40:46PM +0200, Teemu Likonen  wrote:

> * 2021-11-16 17:06:02+, Andrew Gallagher via Gnupg-users wrote:
> 
> > The "Real Name" and "Comment" portions of the userID are mere
> > conventions and, if you have an address book, entirely redundant.
> 
> Thanks. That is rather technical point of view and correct in that
> sense. In my opinion it is a bit too nerdy because real names are
> convenient for other people.

Real names aren't that useful. They're hardly unique,
even/especially within a single family.

In Australia, voting is mandatory (yay! for now).
Someone I know once received a letter from the
gorvernment asking why they didn't vote, and at the
same time, their father, who had with the same name and
address, received a letter asking why they voted twice
(or maybe it was the other way around). :-)

cheers,
raf


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

Re: v2.3 of gnupg for automation?

[raf via Gnupg-users]

On Wed, Oct 27, 2021 at 09:33:16AM +0200, Werner Koch via Gnupg-users 
 wrote:

> On Tue, 26 Oct 2021 18:21, Robert J. Hansen said:
> 
> > That's true, and is correct.  If you're passing a passphrase via the
> > command line, that passphrase becomes visible to anyone with the
> > privileges to get a list of processes and arguments.  At that point the
> > passphrase really isn't providing much in the way of security.
> 
> I fully agree.
> 
> If, for whatever reasons, a passphrase is required the suggested
> workaround is to add
> 
>   --pinentry-mode=loopback
> 
> to the gpg invocation.
> 
> Salam-Shalom,
> 
>Werner

But be warned, loopback doesn't handle password retries after a failure.
If it did, it would be great. But for automation, that shouldn't matter.

cheers,
raf


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

Re: how to add a passphrase to a keypair

[raf via Gnupg-users]

On Sun, Oct 03, 2021 at 01:40:03PM +1100, raf  wrote:

> On Sat, Oct 02, 2021 at 07:12:45PM -0400, Jack via Gnupg-users 
>  wrote:
> 
> > Is it possible to add a passphrase to a secret key originally created
> > without one?  If so, please tell me how.  I'll be happy with either
> > instructions or pointer to the fine manual I either missed or misread.
> > 
> > I have tried lots of variations.  Attempts using gpg-agent fail because
> > pinentry (I've tried text and gui versions) refuses to accept a blank
> > passphrase.  Variants using --passphrase or --passphrase-fd don't work
> > because they only allow passing one passphrase, and I need to provide the
> > old one and the new one.  I've also tried --export-secret-key, which also
> > fails with "error receiving key from agent: No passphrase given - skipped"
> > when using --passphrase-fd.
> > 
> > I do have a copy of gpg-1.4.23 available, but simply copying .gnupg to a new
> > user and using the old gpg doesn't help because gpg1 doesn't see the secret
> > keys from gpg2, and I haven't been able to export them.
> > 
> > Is there a way to do this, or is revoking the old key and creating new keys
> > from scratch the only solution?
> > 
> > Thanks for any information.
> > 
> > Jack
> 
> Try these instructions for changing the passphrase:
> 
>   https://www.cyberciti.biz/faq/linux-unix-gpg-change-passphrase-command/
>   
> https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Changing_your_Passphrase
> 
>   gpg --edit-key Your-Key-ID-Here
>   gpg> passwd
>   gpg> save

Also, don't use gpg1. I'm guessing that either the key
was created with gpg2, or was created with gpg1 but
then ~/.gnupg was subsequently converted for use with
gpg2 (since you say "gpg1 doesn't see the secret keys
from gpg2"). If either is the case, keep using gpg2.

Also, if you are getting the error "No passphrase
given", I could be wrong, but that might suggest that
the secret key is already encrypted. Are you sure that
there is no existing passphrase? If so, ignore this.

cheers,
raf


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

Re: how to add a passphrase to a keypair

[raf via Gnupg-users]

On Sat, Oct 02, 2021 at 07:12:45PM -0400, Jack via Gnupg-users 
 wrote:

> Is it possible to add a passphrase to a secret key originally created
> without one?  If so, please tell me how.  I'll be happy with either
> instructions or pointer to the fine manual I either missed or misread.
> 
> I have tried lots of variations.  Attempts using gpg-agent fail because
> pinentry (I've tried text and gui versions) refuses to accept a blank
> passphrase.  Variants using --passphrase or --passphrase-fd don't work
> because they only allow passing one passphrase, and I need to provide the
> old one and the new one.  I've also tried --export-secret-key, which also
> fails with "error receiving key from agent: No passphrase given - skipped"
> when using --passphrase-fd.
> 
> I do have a copy of gpg-1.4.23 available, but simply copying .gnupg to a new
> user and using the old gpg doesn't help because gpg1 doesn't see the secret
> keys from gpg2, and I haven't been able to export them.
> 
> Is there a way to do this, or is revoking the old key and creating new keys
> from scratch the only solution?
> 
> Thanks for any information.
> 
> Jack

Try these instructions for changing the passphrase:

  https://www.cyberciti.biz/faq/linux-unix-gpg-change-passphrase-command/
  
https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Changing_your_Passphrase

  gpg --edit-key Your-Key-ID-Here
  gpg> passwd
  gpg> save

cheers,
raf


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

Re: Why is --auto-key-locate only for encrypting?

[raf via Gnupg-users]

On Thu, Sep 02, 2021 at 01:10:40PM +0200, Ingo Klöcker  wrote:

> On Donnerstag, 2. September 2021 01:28:42 CEST raf via Gnupg-users wrote:
> > On Wed, Sep 01, 2021 at 01:50:36PM +0200, Ingo Klöcker  
> wrote:
> > > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote:
> > > > Why is the --auto-key-locate only for encrypting (says
> > > > the gpg(1) manpage)? Wouldn't it also be useful when
> > > > receiving emails and verifying signatures?
> > > 
> > > --auto-key-locate looks up keys by email address. It makes no sense when
> > > verifying signatures because in this case you already know the key id the
> > > signature was made with, so that there's no reason to look up the key by
> > > email address (which is ambiguous).
> > 
> > Thanks. I don't understand why it makes no sense, but
> > I'll take your word for it. But I can think of a reason
> > to look up the key by email address even though you
> > have the keyid from the signature: when the key is not
> > on a keyserver or a WKD server, but is in a DNS
> > OPENPGPKEY record (DANE). But perhaps that's not a thing.
> 
> I retract my claim that is makes no sense. It can make sense and that's why 
> --auto-key-retrieve also does a lookup by email address on WKD.
> 
> > > The equivalent for automatic look-up of keys when verifying signatures is
> > > --auto-key-retrieve.
> > 
> > Thanks, but the manpage doesn't include DANE as one of
> > the lookup methods for that option. That's what I was
> > hoping for.
> > 
> > Since this option does a WKD lookup if wkd is in the
> > auto-key-locate list (and --disable-signer-uid isn't
> > used), it seems that it would make sense to do a DANE
> > lookup if dane is in the auto-key-locate list (and
> > --disable-signer-uid isn't used).
> 
> So what you actually want is that --auto-key-retrieve also does a DANE lookup 
> or in fact all kinds of lookup supported by --auto-key-locate. Did you check 
> that it not already does this (even if the man page doesn't mention it)? If 
> yes, then I'd say submit a request for this feature at https://dev.gnupg.org.
> 
> Regards,
> Ingo

I didn't check. I just based it on the manpage. I just
checked the NEWS file, and there's no mention of such
functionality. I'll submit a feature request. Thanks.

cheers,
raf


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

Re: Why is --auto-key-locate only for encrypting?

[raf via Gnupg-users]

On Wed, Sep 01, 2021 at 01:50:36PM +0200, Ingo Klöcker  wrote:

> On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote:
> > Why is the --auto-key-locate only for encrypting (says
> > the gpg(1) manpage)? Wouldn't it also be useful when
> > receiving emails and verifying signatures?
> 
> --auto-key-locate looks up keys by email address. It makes no sense when 
> verifying signatures because in this case you already know the key id the 
> signature was made with, so that there's no reason to look up the key by 
> email 
> address (which is ambiguous).

Thanks. I don't understand why it makes no sense, but
I'll take your word for it. But I can think of a reason
to look up the key by email address even though you
have the keyid from the signature: when the key is not
on a keyserver or a WKD server, but is in a DNS
OPENPGPKEY record (DANE). But perhaps that's not a thing.

> The equivalent for automatic look-up of keys when verifying signatures is 
> --auto-key-retrieve.

Thanks, but the manpage doesn't include DANE as one of
the lookup methods for that option. That's what I was
hoping for.

Since this option does a WKD lookup if wkd is in the
auto-key-locate list (and --disable-signer-uid isn't
used), it seems that it would make sense to do a DANE
lookup if dane is in the auto-key-locate list (and
--disable-signer-uid isn't used).

> Regards,
> Ingo

cheers,
raf


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

Why is --auto-key-locate only for encrypting?

[raf via Gnupg-users]

Hi,

debian-11, gpg-2.2.27

Why is the --auto-key-locate only for encrypting (says
the gpg(1) manpage)? Wouldn't it also be useful when
receiving emails and verifying signatures?

cheers,
raf


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

Request: --export-options export-dane-modern

[raf via Gnupg-users]

Hi,

Is there any chance that a new export option could be
added (alongside or instead of export-dane) to output
"modern" Bind9 zonefile syntax (i.e. "OPENPGPKEY" rather
than "TYPE61 \# 2193", and base64 rather than hexadecimal)?

I suppose it's not important. It's just prettier.

But since DNS query tools like host and dig output
OPENPGPKEY records in base64, it would make it easier
to compare their output against gpg's output.

The reason I'm asking is that DNSSEC is so easy to
implement these days (at least with the new debian-11
which has bind-9.16+), and I've just written a DANE
management tool that makes DANE easy to implement.
So far it only handles TLSA and SSHFP. I'd like to add
support for OPENPGPKEY (i.e. calling gpg to produce the
record, and calling host to check that it's published).
I could (and probably will) get it to transform gpg's
output itself, but I thought I'd ask.

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Mon, Jan 18, 2021 at 01:42:52PM +0100, André Colomb  wrote:

> We need to remember that WKD is only a convenience mechanism for
> discovery, not any kind of authentication.
> 
> Kind regards
> André

And it's discovery that begins with an email address. I
still can't work out what functionality WKD provides in
a situation that isn't email-related.

If you have a non email-related use case for obtaining
a key, why use a non-functioning email address
lookalike as a label for the key, and then require the
user to use WKD client software to obtain the key, when
you could even more easily just give the user a URL
which can act as the label for the key, and the user
could then use any simple HTTP client to obtain the key.

In other words, when there is no email address, there
is no link between an email address's domain and a
website with the same domain (and a presumed connection
between the administration of the email and web
services for that domain), what functionality does WKD
actually provide?

It's the existence of a working email address that the
user already possesses, in combination with the
presumed link between the administration of a mail
service and a web service, that make WKD able to
provide discovery that is automatic and reliable.
Without all of the above, there is no discovery,
reliable or otherwise, and it's not automatic,
because the user has to obtain the label first
somehow.

If you have to give the user a special new label that
they don't already possess (because it isn't a natural
email address), why can't that label be a URL instead?
Why do they need special WKD software when they could
use any HTTP client? What does the user gain from it?
What does the key owner gain from it?

Forgive me if I'm being ignorant and unimaginative, and
perhaps I should just stop trying to understand, but it
looks to me like a case of finding a hammer, and things
starting to look more and more nail-like.

There should be some benefit to be had from the
additional complexity of using WKD in the absence of
email, but I can't see what it is, and it hasn't been
explained (unless I missed that).

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Sun, Jan 17, 2021 at 10:27:24PM +0100, Stefan Claas via Gnupg-users 
 wrote:

> On Sun, Jan 17, 2021 at 10:16 PM Juergen Bruckner via Gnupg-users
>  wrote:
> 
> Please try to accept that GitHub's SSL cert is *valid*, or do you think
> that a CA certifies and invalid cert?

Please try to accept that github's certificate is only
valid for the domains that the CA certified it as being
valid for (which are listed in the certificate itself
for all to see), and that it is not valid for any other
domain (that the CA did not certify it as being valid
for).

I thought the passport example was very good. A slight
tweak (for wildcard certificates) is to imagine a
passport that identifies a person and their children,
but not their grand children. I think such passports
exist (or used to), but only for very young children.
It's not a perfect analogy, but I hope it paints the
picture well enough.

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Sun, Jan 17, 2021 at 09:14:37AM +0100, Stefan Claas 
 wrote:

> Regarding a multi-purpose key and WKD. I mentioned here already
> that a multi-purpose usage key can be used for other tasks as well,
> besides popular email.

I know that keys can be used for things other than
email, but the point I was making is that WKD is only
for email. It's entire reason for existing is to
automatically and reliably find the key that
corresponds to an email address. It has no other
purpose.

But I can see that what you really want is to be able
to use WKD for other purposes. But I don't see how that
would work well. I assume that all existing WKD clients
are email clients. I think you are suggesting that
other types of system that are not email-related start
to adopt WKD for locating keys. That sounds reasonable.
Perhaps they will.

But I think that it would look strange to require a
label for a key that looks like an email address but
isn't, in order to obtain a key. I can't help thinking
that just publishing the URL of the key would be much
much simpler. Simpler still, and more automatable,
would be to come up with your own proposal for placing
keys in a website's .well-known directory and not have
anything at all to do with labels that look like email
addresses but aren't. I can't help thinking that if you
use labels that look like addresses but aren't, people
are likely to assume that it is an email address and
will try to send emails to it, and be thwarted. It
breaks the principle of least astonishment. But maybe
that won't be a problem, depending on the nature of
these other systems.

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Sat, Jan 16, 2021 at 02:25:14AM +0100, Ángel  wrote:

> On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote:
> > My intention was only to promote WKD OpenPGP usage for github.io
> > pages in case people like the idea.
> 
> This was a good idea, but github pages don't seem to support being used
> for WKD (due to the mentioned wildcard issues).

Is it a good idea, though? I'm not sure that many
people would want to change their email addresses so as
to end in @something.github.io just so that they could
then use WKD with github.io. How would that even work?

For example, sac001.github.io doesn't have an MX
record, so email can't be sent to any address with that
as the domain. Github doesn't support adding MX records
for sub-domains to their DNS servers. Even if they did,
you'd still need to set up an email server wherever the
MX record points to anyway. github.io is for setting up
web pages, not email addresses or email accounts.

I must be missing something, but I can't see how a
github.io email address can be connected to an actual
email server or email account, so I can't see how WKD
could be used in connection with github.io email
addresses.

The problem isn't just github doing DNS wildcarding
without the corresponding valid TLS wildcarding,
combined with gnupg not failing over to the direct
method when the advanced method fails. The problem is
that WKD is a protocol for automatically and reliably
mapping an email address to its corresponding public
key, and github.io doesn't support email addresses or
email accounts.

While gnupg's behaviour could be changed (in one or two
different ways) to workaround github.io's
mis-configuration (assuming there are no adverse
security or maintenance implications in doing so),
would that actually solve this problem? I don't think
it would. It wouldn't make github.io email addresses
suddenly become possible.

The only way I can see for this to work at all, is if
all WKD clients were also changed so as to be able to
use one fake "email address", solely for the purpose of
obtaining a public key (that is stored on github.io),
but then using that key to encrypt emails to a
completely different real email address (that has
nothing to do with github.io).

That seems to contradict the rationale for WKD, which
is to have a way of automatically finding the key
that you know really belongs to whoever owns the email
address that emails are being encrypted to. The above
change doesn't sound any better than the pre-WKD
situation of looking up a key from an arbitrary key
server and hoping that it's the right one.

Section 3 of the WKD draft outlines the rationale:

  https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11

I know that sequoia does failover to the direct method
when the advanced method fails, but their stated reason
for doing that wasn't related to github.io. So it seems
that there are use cases where failing over to the
direct method can be helpful, but I don't see how it
can help with github.io specifically.

But that could be due to my ignorance of something
important, or just a lack of imagination. :-)
But a bit of googling seems to confirm my thinking.

  
https://webmasters.stackexchange.com/questions/127564/how-to-setup-domain-email-for-a-site-that-uses-github-pages
  
https://www.breck-mckye.com/blog/2020/05/Setting-up-a-static-site-and-personal-email-without-paying-for-hosting/

Both of these links seem to indicate that combining
email and github.io requires a separate domain that you
control, where github.io only provides the web hosting.
It doesn't provide the email address. If you have a
domain that you control, you can easily avoid the
advanced method by not implementing it. But I think
avoiding having to pay for things like a domain was
part of the rationale for this WKD+github.io proposal.

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Sat, Jan 16, 2021 at 02:20:17AM +0100, Stefan Claas 
 wrote:

> On Sat, Jan 16, 2021 at 1:45 AM raf via Gnupg-users
>  wrote:
> 
> > But there is no certificate that covers that sub-sub-domain.
> > That's why browsers complain if you go to
> > https://openpgpkey.sac001.github.io/.
> 
> A quick question, if you don't mind. Why do people here on this ML
> insist on a sub-sub domain, named openpgpkey?

Because that's how WKD is defined to work.

> Have you ever maintained a web server?

Yes (but that's not really relevant).

> I am not using the html protokoll that much, but for me the openpgpkey
> part in, the for me fictious, URL, causes this error, because GnuPG or
> gpg4win is looking for this.

It's not fictitious. WKD client try to resolve it (i.e.
look it up via the DNS protocol), and github's DNS
servers successfully return several IP addresses for it.
Therefore, as far as github, the owner of the domain, is
concerned, it is real and therefore not fictitious.

> I ask, because for me the proper URL would be:
> 
> https://sac001.github.io/.well-kown/openpgpkey/etc..

What you refer to as "proper" is just the direct method.
That's only half of the WKD protocol. There is also the
advanced method. Both methods together comprise the WKD
protocol.

> And therefore I see absolutely no reason why GitHub or anybody
> else should change their valid SSL cert(s) or do elsewhere some
> mumbo jumbo, so to speak.

If their SSL cert were valid for your sub-sub-domain,
there would be no reason to change, but as has been
pointed out many many times, their certificate is only
valid for the domains that it is valid for. It is not
valid for anything else, and the domain
openpgpkey.sac001.github.com is one of the domains for
which github's certificate is not valid.

If this seems like mumbo jumbo to you, please accept
that it really isn't. It's just that you aren't
familiar enough with all of the protocols involved. And
if that's the case, you can't with any confidence
assert that github's certificate is valid (for anything
other than the domains that are bound to the
certificate).

> And even if people had to set-up this extra steps for the advanced
> method than at least there is still some room for explaining while
> then using also the direct method, or not, because of the name
> 'advanced', which tells me it has higher priotity than direct.

It has been explained a few times already. But if the
explanations aren't making sense, perhaps you need more
background information in order to understand the
explanations that have been given. Perhaps you could
read up on DNS and TLS and WKD. I'd recommend the
O'Reilly books on Bind and OpenSSL. There are probably
free online resources but those books are good. But
maybe I just like books for learning big new subjects.
And also the WKD draft, of course. Sorry to suggest a
pile of reading material, but I can't think of a better
way to learn the relevant topics.

> I must say good night now.
> 
> Best regards
> Stefan

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Fri, Jan 15, 2021 at 07:56:26AM +0100, André Colomb  wrote:

> Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users 
> :
> >But of course, you're not asking for that. You're just
> >asking for something to work. There must be other ways.
> >Accepting invalid certificates might just have been my
> >first thought at how to deal with this. But that would
> >enable the advanced method to work (in situations where
> >it shouldn't). If I remember correctly (possibly not),
> >you wanted the direct method to work, and github.io's
> >mis-configuration of certificates caused the advanced
> >method to be attempted and fail, before the direct
> >method could even be attempted.
> 
> I'll try to complete your summary. The DNS wildcard entry for
> *.example.github.io leads to the advanced method being tried. We can't
> change that entry, and therefore with the current protocol draft, it
> makes no sense forcefully wanting to use the direct method.
> 
> It's easy to set up the advanced method there. But GitHub uses an
> invalid TLS certificate for openpgpkey.example.github.io. That's what
> needs fixing and it is also out of our control.
> 
> So basically Stefan's request is to change the protocol to work around
> a misconfiguration because both DNS and the TLS certificate are
> controlled by a company that offers the service totally unrelated to
> WKD. Such a workaround could hurt the ecosystem because it may hide a
> misconfiguration in setups where the operator does have control over
> these things and just needs to notice.

That's why I thought maybe a skip list might be useful,
rather than automatically failing over to the direct
method in all cases where the advanced method is
mis-configured in some way. The user-controlled skip
list could be used in cases where the user knows that
the server administrators aren't going to fix their
system. I can totally understand a reluctance to add
workarounds to other people's bugs into your own
software. I've done that and wasn't happy about it.
But I imagine that a skip list to avoid the advanced
method for certain
known-to-be-permanently-misconfigured domains is
probably a minor instrusion into the code. But I'm just
guessing.

And for it to be of any use, github.io would have to be
in the list by default, so that all users "benefit"
from it without knowing in advance that they need it.
Of course, if github.io ever do fix their TLS system,
they would need to be removed from the skip list, which
presumably wouldn't happen until they next upgrade
gnupg. That would be a problem.

Trying to be pragmatic in the face of other people's bugs
can get tacky.

Hmm, does github itself have a bug-tracking system? :-)

> >OK. I just had a look at https://wiki.gnupg.org/WKD and
> >it doesn't refer to "advanced" or "direct" methods. It
> >seems to consider the "direct" method as the main
> >method, and the "advanced" method as a "Stopgap method"
> >which is "Not recommended - but a temporary
> >workaround". So having an additional mechanism to
> >disable the "advanced" method sounds reasonable. Or
> >maybe the wiki page needs to be updated(?).
> 
> Sorry, you just misread that part. The stopgap solution is to use a
> server operated by openpgp.org instead of your own web server. For
> that to work, you must set up the advanced method for WKD on your
> domain's DNS. That method is perfectly fine and in some scenarios even
> easier to use.

Thanks for that. That makes more sense. I thought the
advanced method sounded quite sensible. :-)

> Kind regards
> André
> 
> Hi raf,
> 
> thanks for your perspective on the matter.
> 
> --
> Greetings...
> From: André Colomb 

cheers,
raf


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

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Fri, Jan 15, 2021 at 07:56:16AM +0100, Stefan Claas 
 wrote:

> On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users
>  wrote:
> 
> [...]
> 
> > I'm really not an expert, and the above might not make
> > any sense. I'm just thinking aloud.
> 
> Me neither ... :-) For me, the questions I had is still unresolved
> when it comes to properly explaing what security implication
> it gives, when for example sequoia-pgp can handle this and
> why the draft explicity says it MUST use the advanced-method
> first.
> 
> Don't you think when GitHub, a major player, would have an invalid
> SSL cert, that maybe one of the millions programmers there would not
> have contacted GitHub, like I did, and say hey GithHub you serve
> the global community and visitors an invalid SSL certificate?

I would. But that doesn't seem to have happened. I can
only assume that github.io users aren't making much
using sub-sub-domains of their sub-domains, or if they
are, then they are not using TLS with those
sub-sub-domains, so the invalid certificate isn't
causing them any issues.

Github could probably create valid wildcard
certificates for sub-sub-domains (now that letsencrypt
supports wildcard certificates), but it seems that they
only have one certificate that covers their domains and
sub-domains, but they then hand them out for
sub-sub-domains as well. That is very odd behaviour on
their part. They must know that that is an invalid use
of their certificate. They are very clever people.

> I must admit that I also do not understand what you
> mean with sus-sub domains.

It's sub-sub-domain, not sus-sub-domain. Sorry if I
mistyped it.

The "sub-domain" is the sub-domain of github.io, e.g.:

  sac001.github.io

The "sub-sub-domain" is the sub-domain of a sub-domain, e.g.:

  openpgpkey.sac001.github.io

Github's web server is handing out the same certificate
for both your sub-domain and your sub-sub-domain, even
though it is not valid for your sub-sub-domain. It is
only valid for the following hostnames which includes
your sub-domain (but not your sub-sub-domain):

www.github.com
*.github.com
github.com
*.github.io
github.io
*.githubusercontent.com
githubusercontent.com

You can see this for yourself in Firefox, by going to
https://sac001.github.io/, clicking on the padlock,
then clicking on the right "arrow" to the right of
"Connection secure", then clicking on "More
information".

Github's web server should really just hand out this
certificate for hostnames that are covered by it, but
instead, they hand it out for sub-sub-domains that are
not covered by it.

The best solution would be for github, when handing out
sub-domains, to register a letsencrypt wildcard
certificate for that sub-domain's sub-sub-domains. In
your sub-domain's case, such a certificate would cover:

*.sac001.github.io.

But there is no certificate that covers that sub-sub-domain.
That's why browsers complain if you go to
https://openpgpkey.sac001.github.io/.

I think that letsencrypt didn't originally support
wildcard certificates. That might have something to do
with what github are doing. But they do support them
now, so this could be fixed by github. But there might
have to be a reasonable number of users asking for it,
for that to happen. It would take some effort on
github's part to fix this, and there's probably no
money in it for them.

> My GitHub page is sac001.github.io and not foo.bar.github.io
> or whatever.

Yes, but openpgpkey.sac001.github.io is a
sub-sub-domain and it is instrumental in the advanced
method. When a WKD client attempts to fetch a key for
ste...@sac001.github.io, they try to resolve that
sub-sub-domain, and the DNS resolution succeeds, and
the webserver hands out a certificate for that domain
which happens to be invalid.

> If Werner had told me/us, hey look, according to my draft
> the advanced method MUST been used because of this and that
> security implication and it is not allowed in this case to fall back
> if an (for WKD) invalid cert is present, because of this/that security
> issue, I guess then I had a better understanding and then I guess
> also the sequoia team would never had done it so that it works
> with sequoia-pgp.

I think that's exactly what this part of the draft is saying:

   3.1.  Key Discovery

   ...

   There are two variants on how to form the request URI: The advanced
   and the direct method.  Implementations MUST first try the advanced
   method.  Only if the required sub-domain does not exist, they SHOULD
   fall back to the direct method.

It just doesn't include the background rationale for
the algorithm in amongst the algorithm. That's probably
discussed elsewhere. But I haven't read the draft. I'm
just copying and pasting from

Re: WKD proper behavior on fetch error

[raf via Gnupg-users]

On Thu, Jan 14, 2021 at 04:33:00PM +0100, Stefan Claas via Gnupg-users 
 wrote:

> [...] My initial post was a help request and I also explained
> why it IMHO would be good to have such a solution, which
> would not hurt the GnuPG ecosystem in any form and would be
> IMHO an enrichment for GnuPG usage.
> 
> Best regards
> Stefan

[Note: First 3 paragraphs are mostly me being stupid -
please bear with me]

It sounded to me like you would like gnupg to have a
bug added to it, whereby it accepts invalid
certificates for sub-sub-domains, when the certificate
is only valid for sub-domains.

To me, that doesn't sound like it "would not hurt the
GnuPG ecosystem in any form". To me, that sounds like a
security bug, in the sense that it could lead users to
think that a certificate is valid, when it isn't.

If the ability to not validate certificates exists or
gets added to gnupg, it wouldn't be turned on by
default, so I'm not sure that it would even help your
use case. The only people who could fetch your keys
would be the ones who had disabled certificate
validation.

But of course, you're not asking for that. You're just
asking for something to work. There must be other ways.
Accepting invalid certificates might just have been my
first thought at how to deal with this. But that would
enable the advanced method to work (in situations where
it shouldn't). If I remember correctly (possibly not),
you wanted the direct method to work, and github.io's
mis-configuration of certificates caused the advanced
method to be attempted and fail, before the direct
method could even be attempted.

It's been suggested that, when the certificate for
openpgpkey.*.github.io is found to be invalid, WKD
clients could failover to the direct method (like
sequoia does). Then at least the direct method would
work with github.io sub-domains. That sounded good (to
a non-expert like me). But perhaps it's a bit
inefficient. But at least it's automatic.

Another possible solution might be for WKD clients to
have a list of domains to skip when doing the advanced
method. If it had "openpgpkey.*.github.io" by default,
then it would know not to try to resolve
openpgpkey.*.github.io at all. Any domain that hands
out invalid certificates for sub-sub-domains could be
in the skip list. The currently documented solution to
this expects the administrators of such
(mis-configured) domains to add DNS records to prevent
this, but when you can't rely on that happening,
allowing the client/user to exclude them could be
another option. And it wouldn't require accepting
invalid certificates. And it would eliminate the
attempt to use those domains so it would be more
efficient. But it does require additional configuration
that the above method doesn't require. A built-in
default skip list would help with that.

You still couldn't use the advanced method with
github.io (until they start issuing a wildcard
certificate for each sub-domain), but that's probably
OK. I just had a look at https://wiki.gnupg.org/WKD and
it doesn't refer to "advanced" or "direct" methods. It
seems to consider the "direct" method as the main
method, and the "advanced" method as a "Stopgap method"
which is "Not recommended - but a temporary
workaround". So having an additional mechanism to
disable the "advanced" method sounds reasonable. Or
maybe the wiki page needs to be updated(?).

I'm really not an expert, and the above might not make
any sense. I'm just thinking aloud.

cheers,
raf


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

Re: Thunderbird / Enigmail / Autocrypt

[raf via Gnupg-users]

On Mon, Nov 23, 2020 at 01:23:39PM +0100, Werner Koch via Gnupg-users 
 wrote:

> On Mon, 23 Nov 2020 07:22, cqcallaw said:
> 
> > At my job, I frequently send out summary charts and graphs surrounded by 
> > text.
> > Attachments simply do not work; my audience cannot spend the mental energy 
> > to
> 
> Proper MUAs display inline images without problems.  I recall that even
> exmh did this ~25 years ago.  It is just that the marketing department
> can't enforce the corporate identity on text mails - or are too lazy to
> create rules which work with plain text (and maybe inline images).
> 
> And well, I like HTML mails: my main address is free of spam thanks to a
> simple procmail rule ;-)
> 
> Shalom-Salam,
> 
>Werner

Apologies in advance. I know this is all off-topic for
a gnupg mailing list, but for those who really hate
html email, and are able to function without it,
there's a potentially useful mail filter I wrote that
converts everything to text that can be converted, and
deletes everything else.

  http://raf.org/textmail
  https://github.com/raforg/textmail

It makes it look like everyone is sending you plain text. :-)

For everyone else, I recommend lots of phishing training
to mitigate the biggest risks of html email.

At least until gmail/outlook/etc. implement, by default,
the equivalent of Thunderbird's brilliant Torpedo
anti-phishing addon.

cheers,
raf


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

Re: how to suppress new "insecure passphrase" warning

[raf via Gnupg-users]

Alan Bram via Gnupg-users wrote:
 
> I have been using gnupg for a few years now, with no change in the way I
> invoke it. Recently (I guess my package manager updated to a new version:
> 2.2.23) it started injecting a warning about "insecure passphrase" and
> suggesting that I ought to include a digit or special character.
> 
> I don't want to do that. I have a strong passphrase that was generated via
> Diceware. It's simply a few words made of plain letters; but it's long
> enough, and totally random. Stronger than a short, lame password that
> someone simply appends a "1" to.
> 
> Is there a way to suppress the annoying warning?

I don't know, but you could report it as a bug in the
package. If they are going to introduce such a warning,
the logic should be evidence-based, and I bet it isn't.

I once read a great article (on an Mozilla or OWASP
site) about the fact that the ancient corporate advice
of using a password that is at least eight characters
long, with at least three character classes (i.e. upper
case, lower case, punctuation and digits), was harmful
because humans all think very similarly, and we all
come up with passwords that look the same, like
"Password1". Being forced to change passwords for no
reason every 90 days just means we all use
"Winter2019", "Autumn2019", etc.

So penetration testers have done the stats on cracked
passwords and come up with a list of the top 100
password patterns that mean that you can dramatically
reduce the search space when cracking passwords and
crack about 95% of supposedly strong passwords. The top
pattern covers about 12% of passwords.

Here's a URL on the topic (but not the one I first
read):

  
https://blog.rapid7.com/2018/06/12/password-tips-from-a-pen-tester-common-patterns-exposed/

So the original advice wasn't evidence-based, and even
FIPS have adandoned it and have started recommending
long passphrases. Diceware passwords are brilliant, and
any system that complains that they are aren't secure
is an embarrassment.

I hate being told by websites that my 50 character
passphrase isn't secure enough, even more so when it
meets all of their stated password requirements (i.e.
they don't mention the fact that they don't accept
space characters as a special character - grr).

cheers,
raf

P.S. Of course you could make a local copy of the binary
and replace the first character of the warning with a
nul byte. That should fix it. :-)


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

Re: Protecting encryption server

[raf via Gnupg-users]

On Tue, Jul 28, 2020 at 08:39:28AM -0700, Ayoub Misherghi via Gnupg-users 
 wrote:

> A human environment went insane and uncontrollable. The system is intended
> to bring sanity back and maintain it.
> 
> 
> Client programs access server(s) for real-time encryption or decryption.
> Network of servers that may be located at different geographic locations.
> Each server would need keys that need to be protected. The servers are in a
> hierarchy communicating with each other securely as needed. Horrible
> environment to protect.
> 
> 
> Server design may need to be specialized with immunity to tampering and
> abuse. Operator and admin may need to be on constant monitoring/surveillance
> with biometric ID. Equipment may need to be identifiable and be under
> constant monitoring and surveillance.
> 
> Grateful for all suggestions. Keep them coming. I have a lot to learn.
> 
> Ayoub

You might be asking in the wrong place. We can suggest
helpful things like vetting staff, hardware security
modules (HSM), separation of duties, privileged access
management, ISO27001 etc. but this is just a gnupg
mailing list, not a security architecture mailing list.

You should consider engaging the services of security
architects who can analyse your environment in detail
and provide something as close to a solution as you can
afford. As rjh said, an actual solution is impossible
but you do what you can and what you can afford (and
log everything for evidenciary purposes).

cheers,
raf


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

Re: Have gpg-preset-passphrase always required a keygrip? (was: Newbie question.)

[raf via Gnupg-users]

Dmitry Alexandrov wrote:

> Peter Lebbing  wrote:
> > 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,
> 
> Hm...
> 
> Did not gpg-preset-passphrase(1) worked perfectly on any NAMEs (IDs,
> UIDs) as well some time ago?  Or is that me, who have some false
> memories?

For gpg-agent 2.0.x I needed to use gpg --fingerprint --fingerprint xxx@xxx
to get the cache id to use with gpg-preset-passphrase --preset.
Since then, I need gpg2 --fingerprint --with-keygrip xxx@xxx.
So it probably changed from fingerprint to keygrip with 2.1
(but I don't know exactly when).

cheers,
raf


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

Re: decrypt aes256 encrypted file without gpg-agent

[raf via Gnupg-users]

Werner Koch via Gnupg-users wrote:

> On Mon, 29 Jun 2020 13:07, vedaal said:
> 
> > otherwise , just use GnuPG 1.4.x , and unless you ever need an
> 
> Do not use 1.4 unless you have to decrypt old non-MDC protected data or
> data encrypted to a legacy v3 key.
> 
> Shalom-Salam,
> 
>Werner

Sadly, there are other reasons that make it seem (to me)
as though I still need 1.4. :-(

I assume the answer must be no, but is there any chance
that --pinentry-mode loopback could be made to prompt
again when the wrong passphrase is entered? If it did
that, I'd be happy to stop using 1.4 on my mac laptop.

Alternatively, is there a pinentry program that works
inside vim and all/most variants of gvim (at least
X11/motif and MacVim)? Preferably available via
macports, but not necessarily.

I can't seem to find one. I've tried pinentry-curses
and pinentry-tty on debian-10 with gpg-2.2.12 but
neither prompt for the passphrase when invoked inside
vim or gvim, and the file is not decrypted.

Hopefully, I'm just ignorant and there is a solution
to my ergonomic issues (other than using loopback
and typing long passphrases very slowly and carefully).

cheers,
raf


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

Re: Fwd: The GnuPR FAQ

[raf via Gnupg-users]

vedaal via Gnupg-users wrote:

> On 5/11/2020 at 6:15 PM, "Robert J. Hansen"  wrote:
> >
> >This arrived in my inbox: I'm presenting it here without comment.  
> >My
> >response will be following in a moment.
> >
> >
> > Forwarded Message 
> >Subject: The GnuPR FAQ
> >Date:Mon, 11 May 2020 14:19:07 -0600
> >From:James Long 
> >To:  r...@sixdemonbag.org
> -
> >You've advised people to use a HORRIBLE practice of using 
> >dictionary words solely for their password. I tested this theory myself back 
> >in the day, so I can 100% guaranty you of this fact: A brute force 
> >dictionary based attack can crack a password like that in LESS THAN 5 
> >minutes!! 
> 
> =
> How many words were in your passphrase??
> 
> Here is some data on the Diceware list:
> https://theworld.com/~reinhold/diceware.html
> 
> The Diceware list has only 7776 words.   A complete dictionary has almost 2 
> orders of magnitude more.
> 
> "Webster's Third New International Dictionary, Unabridged, together with its 
> 1993 Addenda Section, includes some 470,000 entries. The Oxford English 
> Dictionary, Second Edition, reports that it includes a similar number."
> https://www.merriam-webster.com/help/faq-how-many-english-words
> 
> 10 diceware words provides a greater Brute Force space, than 2^128 (a gnupg 
> session key for older defaults of CAST-5)
> (  7776^10 = 8.08x10^382^128 = 3.40×10^38  )
> 
> 20 Diceware words  provides a greater Brute Force space, than 2^256
> (  7776^20 =  6.53×10^77 2^256 =1.157×10^77  )
> 
> Even using only English words greater than 5 letters and unrelated to each 
> other, an extremely low-bound estimate, would be 77760 words. (in reality, 
> far greater, but let's use an example people would agree on).
> 
> So using 8 words chosen semi-randomly from a dictionary, 77760^8 = 
> 1.336×10³⁹, still greater than a a 2^128 Brute Force Space.
> 
> So, not only is is NOT *horrible* advice, it should be enough for anyone's 
> threat model.

I can only assume that James must have thought that a
*single* dictionary word was what was meant, not a large
number of randomly-chosen dictionary words. I love
diceware passwords. Sometimes you even get lucky and
generate a funny one.

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

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

Re: US Government

[raf via Gnupg-users]

Franklin-King, Sandra M. via Gnupg-users wrote:

> Hi
> 
> I am inquiring as to this software has been reviewed and classified by the 
> Bureau of Security with the US Government?
> 
> Sandra Franklin-King
> LPD Trade Compliance Manager
> 
> Thermo Fisher Scientific
> 28 Schenck Parkway, Suite 400 | Asheville, NC  28803
> Phone +1 828 365 1221 | Mobile: +1 828 458 8747
> sandra.franklin-k...@thermofisher.com
>  | www.thermoscientific.com

The only Bureau of Security I could find via google is
part of the California government, not the US government.

If they are who you are referring to, you can contact
them to ask at https://www.bsis.ca.gov/about_us/contact_us.shtml

cheers,
raf


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

Re: gpg-agent, pinentry and Emacs

[raf via Gnupg-users]

Ralph Seichter wrote:

> * raf via Gnupg-users:
> 
> > Does "--pinentry-mode loopback" make any difference?
> 
> Where exactly do you suggest I add this option?
> 
> -Ralph

Wherever it needs to be to get added to the gpg command line
when invoked from within emacs.

Or as a setting in gpg's config file (but then it would take
effect always which you probably wouldn't want). 


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

Re: gpg-agent, pinentry and Emacs

[raf via Gnupg-users]

Ralph Seichter wrote:

> I asked about the following on the Notmuch mailing list first, and
> Daniel Kahn Gillmor offered some advice, but the issue is not yet
> resolved. I'm hoping for additional input from the GnuPG community.
> 
> I use Dovecot with a Maildir-based message store, allowing me to access
> my mail using various IMAP based clients. I also use Notmuch[1] with
> Emacs as a MUA, and for that, I login using SSH and a terminal, which of
> course means no graphics beyond Ncurses.
> 
>   [1] https://notmuchmail.org/
> 
> This works fine until I encounter signed or encrypted mail (GPG and/or
> S/MIME). Emacs attempts to prompt me for my password, or to ask me
> whether I trust signator XYZ, but crams that prompt into the last two
> lines of the Emacs window, so I cannot really see what is expected of
> me.
> 
> I use gpg-agent and have tried both pinentry-tty and pinentry-curses. I
> tried with and without 'allow-emacs-pinentry' in gpg-agent.conf. I tried
> 'epa-pinentry-mode' with values 'nil' and 'loopback'. All this did not
> resolve the issue.
> 
> Daniel suggested "running gpg-agent in a dedicated terminal window, and
> handling the gpg-agent prompts from that window". I tried to achieve
> that by setting GPG_TTY to a fixed value like /dev/pts/1, and running
> Emacs in /dev/pts/2. This works for a single time only. When prompting
> me the next time, parts of my input are echoed on the screen, and when I
> press return, the shell in pts/1 attempts to execute my pass phrase. It
> looks like pinentry died halfway, so my input ends up in the shell.
> 
> I you have suggestions about how to solve this, I'd be grateful.
> 
> -Ralph

Does "--pinentry-mode loopback" make any difference?
Is it any different to epa-pinentry-mode?

cheers,
raf


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

Re: How to improve our GUIs (was: We have GOT TO make things simpler)

[raf via Gnupg-users]

Ryan McGinnis via Gnupg-users wrote:

> I might be missing something really obvious here but... what is this
> trying to protect against?

What they say they are trying to protect against, I suppose.
I summarised my understanding of it by saying:

> > It might not address all threats but it certainly seems
> > to solve some very real threats, mainly the threat of
> > someone hacking into your IMAP account and accessing
> > every email you ever received.

> ...Your service provider can
> certainly (and probably does certainly) retain archive or backup copies
> of all emails that enter into and exit your account...

I'm sure they have better things to waste their storage on.
Most IMAP service providers are not the NSA after all. :-)

> ... so encrypting them
> after reception only means that the copy you are accessing is encrypted
> and non-accessible to the provider, but the copy that they archived or
> backed up is just as plaintext as always (or is, more likely, encrypted
> with a key that only they know). 

The point is that it's not accessible to whoever hacks
into your IMAP account. They make it very clear that
that is the problem that they are trying to solve.

> ... E2E is really the only solution that keeps your email provably
> private from all parties concerned other than the recipients. 

Like anything else, E2E is only an actual solution if
it is actually used.

Since E2E for email is demonstrably too hard to achieve
for most people, it doesn't happen except in rare
cases. You can obviously send encrypted emails to all
your correspondents who have accessible keys. E3 allows
you to encrypt the emails that you receive that weren't
sent by senders who are able or willing to encrypt what
they send. The creators of E3 are not pretending that
E3 is an alternative to E2E for the problems that E2E
solves. It complements it (in the sense that it can
encrypt all the emails that weren't encrypted
end-to-end). It's just a tool that solves a particular
privacy problem in an accessible way. It seems like a
good thing.

Of course, making E2E just as accessible must be
possible too but it hasn't happened yet and we've been
waiting a long time. How hard would it be for all email
clients to automatically create a key pair and publish
the public key when you first run it if it can't find
an existing keypair? Pretty soon everyone would have
keypairs. Multiple devices would complicate things,
though.

I expect it would require Google and Microsoft to make
it happen automatically but Microsoft decided to charge
money to encrypt email and Google decided to make money
by analysing email content to improve advertising
effectiveness so I can't see them doing it any time
soon.

cheers,
raf

> On 10/29/2019 7:33 PM, raf via Gnupg-users wrote:
> > Hi,
> >
> > Sorry if this was mentioned before but I've just come
> > across a novel approach to email encryption that
> > doesn't do end-to-end encryption, but rather it
> > encrypts email upon receipt so that an individual can
> > encrypt the email that is stored in their IMAP account
> > as it arrives without the need for every sender to
> > encrypt and without the need for any service provider's
> > involvement (you just need an IMAP account), and it
> > supports reading email from multiple devices, each with
> > their own local private key. Most importantly, it
> > doesn't require the user to know anything about
> > encryption except that they want some.
> >
> > It might not address all threats but it certainly seems
> > to solve some very real threats, mainly the threat of
> > someone hacking into your IMAP account and accessing
> > every email you ever received.
> >
> >   Making It Easier to Encrypt Your Emails
> >   Authors: John S. Koh, Steven M. Bellovin, and Jason Nieh
> >   https://www.usenix.org/publications/login/fall2019/koh [paywall, usenix]
> >
> >   Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management
> >   EuroSys '19 Proceedings of the Fourteenth EuroSys Conference 2019
> >   Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
> >   https://doi.org/10.1145/3302424.3303980 [paywall, acm]
> >   http://nieh.net/pubs/eurosys2019_e3.pdf [free]
> >
> >   Easy Email Encryption with Easy Key Management
> >   Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
> >   https://mice.cs.columbia.edu/getTechreport.php?techreportID=1639 [free]
> >
> >   Automatically and invisibly encrypt email as soon as it is received on 
> > any trusted device
> >   https://www.helpnetsecurity.com/2019/04/01/easy-email-encryption/ [free]
> >
> > I know this doesn't help with the discussion of
>

How to improve our GUIs (was: We have GOT TO make things simpler)

[raf via Gnupg-users]

Hi,

Sorry if this was mentioned before but I've just come
across a novel approach to email encryption that
doesn't do end-to-end encryption, but rather it
encrypts email upon receipt so that an individual can
encrypt the email that is stored in their IMAP account
as it arrives without the need for every sender to
encrypt and without the need for any service provider's
involvement (you just need an IMAP account), and it
supports reading email from multiple devices, each with
their own local private key. Most importantly, it
doesn't require the user to know anything about
encryption except that they want some.

It might not address all threats but it certainly seems
to solve some very real threats, mainly the threat of
someone hacking into your IMAP account and accessing
every email you ever received.

  Making It Easier to Encrypt Your Emails
  Authors: John S. Koh, Steven M. Bellovin, and Jason Nieh
  https://www.usenix.org/publications/login/fall2019/koh [paywall, usenix]

  Why Joanie Can Encrypt: Easy Email Encryption with Easy Key Management
  EuroSys '19 Proceedings of the Fourteenth EuroSys Conference 2019 
  Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
  https://doi.org/10.1145/3302424.3303980 [paywall, acm]
  http://nieh.net/pubs/eurosys2019_e3.pdf [free]

  Easy Email Encryption with Easy Key Management
  Authors: John S. Koh, Steven M. Bellovin, Jason Nieh
  https://mice.cs.columbia.edu/getTechreport.php?techreportID=1639 [free]

  Automatically and invisibly encrypt email as soon as it is received on any 
trusted device
  https://www.helpnetsecurity.com/2019/04/01/easy-email-encryption/ [free]

I know this doesn't help with the discussion of
improving GUIs to make it easier to encrypt emails that
you want to send, but it looks like a promising
improvement in privacy that could help many more people
than just those that want to encrypt emails that they
send. And it's still relevant. I expect that those that
want to encrypt any emails that they send might also
like all the emails that they receive to be encrypted
as well.

cheers,
raf


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

Re: add-photo continued ...

[raf via Gnupg-users]

Stefan Claas via Gnupg-users wrote:

> Hi all,
> 
> some of you may remember the add-photo thread we had a while ago
> and I wondered why the max image size for a UAT packet is 16 MB.
> 
> Recently I saw a Twitter post explaining that a .jpeg image header
> can contain 16 MB of data.

That's just decadence. :-)
Just because it can, doesn't mean it should.
16MB is plenty. Use tinypng.com.


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

Re: Essay on PGP as it is used today

[raf via Gnupg-users]

Ángel wrote:

> On 2019-07-18 at 12:13 +1000, raf wrote:
> > At work, when a client insists on email, and I (or the law)
> > insist on encryption, I provide them with instructions for
> > installing 7-zip and send them an AES-256 encrypted zip or 7z
> > file as an attachment. It's the simplest thing I could think
> > of that I thought most people could cope with.
> 
> Encrypted zip files have several factors that make it a beautiful
> solution for sending encrypted messages to occasional users that don't
> care much about it:
> 
> a) zip is a file format supported out-of-the-box by pretty much every
> system, and that users are comfortable with. Whereas you would be seen
> as a weirdo if you sent them a .gpg or other new file that needed a
> special program, you would likely be asked to just sent it
> "normally" (ie. unencrypted).

> b) The format itself supports secure encryption (aes128/256).

Unfortunately, that's not entirely true. The zip format
that is supported out of the box by Windows doesn't
support AES-256. The impression I get is that it's v2
of the format which only supports broken zip password
protection. Zip v5 format is needed for AES-256 and
Windows Explorer doesn't seem to suppoort that. The
recipient must either have 7-Zip (which is free) or
Winzip (which costs money). I find it hard to believe
that the new format isn't supported everywhere but it
isn't. Even the command line tool unzip only supports
the ancient zip format when encryption is used.

> c) If their client doesn't support AES-Encryption, their client will
> show that *their program* can't cope with it. This places the onus on
> the receiver (their zip decompresser isn't "new enough"), rather than
> the sender (see a).
> 
> Nevertheless, it has a number of potential problems:
> 
> * As pointed out by Stefan Claas, you need to exchange the encryption
> keys. The zip file is just an encryption primitive, so key distribution
> may become a problem.
> 
> (raf, may I ask how you are dealing with it? As they are clients, are
> you providing a set of keys in advance when personally visiting them?
> Are you providing the key for the new message?)

Verbally over the phone (but I think SMS would be OK).

> * 7-Zip before 19.00 use a bad PRNG to fill a half-size IV 
> https://threadreaderapp.com/thread/1087848040583626753.html

Luckily we use v19.00 for encrypting (but my macports
version is only v16.02).

> * A naive user trying to reply would easily end up using PKWARE
> encryption (and reusing the password)

True. In that case, I'd recommend that they create a
.7z file rather than a .zip file. The .7z format only
seems to support AES-256. The .zip format supports both
AES-256 and PKWARE password protection but it defaults
to PKWARE protection (in the 7-Zip GUI).
 
> Kind regards

cheers,
raf


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

Re: Essay on PGP as it is used today

[raf via Gnupg-users]

Stefan Claas wrote:

> raf via Gnupg-users wrote:
> 
> > Stefan Claas via Gnupg-users wrote:
> > 
> > > Andrew Gallagher wrote:
> > > 
> > > > * And finally: “don’t encrypt email”? Yes, well. Email is not going 
> > > > away.
> > > > Just like passwords, its death has been long anticipated, yet never
> > > > arrives. So what do we do in the meantime?
> > > 
> > > I think the biggest problems is how can PGP or GnuPG users tell other 
> > > users,
> > > not familar with email encyrption yet, what else to use ...
> > 
> > At work, when a client insists on email, and I (or the law)
> > insist on encryption, I provide them with instructions for
> > installing 7-zip and send them an AES-256 encrypted zip or 7z
> > file as an attachment. It's the simplest thing I could think
> > of that I thought most people could cope with.
> 
> That is simple, indeed. But how do you exchange passphrases for
> the encrypted files in advance and do you switch them regularly
> or leave them the same when dealing with many clients?

Passwords are conveyed to clients over the phone and each client
has their own. If it were entirely automated and in heavy use, a
password would be generated for each file and sent via SMS to the
recipient.

> I solved this with using NaCl public keys, bearing no infos of
> the key owners and having a little key ring, where I only assign
> nicknames to the pub keys. The software I use is box
> 
> https://github.com/rovaughn/box
> 
> in combination with a base91 encoder / decoder, for ASCII armor,
> when sending encrypted emails. 
> 
> Before that I also experimented with other tools, like dhbitty,
> MiniLock and Pretty Curved Privacy etc. but for me they all had
> some disadvantages compared to box.
> 
> Regards
> Stefan

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

Re: Essay on PGP as it is used today

[raf via Gnupg-users]

Stefan Claas via Gnupg-users wrote:

> Andrew Gallagher wrote:
> 
> > * And finally: “don’t encrypt email”? Yes, well. Email is not going away.
> > Just like passwords, its death has been long anticipated, yet never arrives.
> > So what do we do in the meantime?
> 
> I think the biggest problems is how can PGP or GnuPG users tell other users,
> not familar with email encyrption yet, what else to use ...

At work, when a client insists on email, and I (or the law)
insist on encryption, I provide them with instructions for
installing 7-zip and send them an AES-256 encrypted zip or 7z
file as an attachment. It's the simplest thing I could think
of that I thought most people could cope with.


___
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

[raf via Gnupg-users]

Werner Koch via Gnupg-users wrote:

> On Wed,  3 Jul 2019 12:35, gnupg-users@gnupg.org said:
> 
> > problem but I have read RJH's article). It sounds like SKS servers can
> > handle these poisoned keys but GPG can't. That suggests that maybe GPG's
> 
> I think here is a misunderstanding.  Sure, processing 150k signatures
> takes quite some time and makes things very slow.  This is why we call
> it a DoS.  We can't do much about it.  Compare it to X.509 CRLs - they
> have a very similar problem (cacert.org is a prominent but not the only
> example of CRLs making S/MIME processing very slow).
> 
> The actual problem in gpg when using the keybox format is that only
> after processing the imported keys we hit a 5MiB limit for the keyblock
> in the database layer.  Thus the import fails.  Determining the size of
> the keyblock as it will be stored requires that we first remove some
> (standard) garbage from the keyblock - this takes some time.  With the
> currently deployed code gpg will just reject any updates from a key if
> that limit was reached.  That is not a good choice and the reason why I
> call it a bug.   The fix to this bug is to fallback importing a stripped
> down version of the key.  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).
> 
> > For example, if the problem is overuse of resources such as memory, could
> > the keyring handling code be rewritten to use fewer resources? e.g. treat
> 
> Years ago we had the problem that people uploaded keys with large user
> ids and such.  Thus we introduced limits to avoid spamming the keyring
> with such faked data.  There is also an overall limit of 5 MiB for the
> entire keyblock which is sufficient for all real-world keyblocks - even
> for those with many key-signatures.
> 
> > signatures when importing a key, perhaps there could be a limit to how many
> > signatures GPG will verify. Does it really have to verify every single one?
> 
> It needs to validate all self-signature because they make up the
> integrity of the keyblock.  For key-signature, sure we could introduce a
> limit, we actually do that with import-clean because that imports only
> those key-signature which we can verify and which are the latest from the
> same key (it is possible to sign a key several times to change meta data
> associated with the key-signature).
> 
> Salam-Shalom,
> 
>Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Hi Werner,

Thanks for the detailed explanation.
And thanks for gpg.

cheers,
raf


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