Lost GPG private key passphrase

[Daniele Nicolodi via Gnupg-users]

Hello,

I have an oldish GPG key for which I have lost the passphrase. I have a 
very good idea of what the passphrase is constructed but there are some 
characters substitution that I must have used back then really escape my 
memory now. I think that a tool like John the Ripper could make easy 
work in retrieving it.


Does anyone know how to run john on a private key stored in the format 
used by the new keystore used by gpg2?


Thank you.

Cheers,
Dan

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

Re: How to report issues and suggest changes to the Web Key Directory specification [was: Re: Please tackle the Right Thing]

[Daniele Nicolodi]

Hello,

this is only to report that Thunderbird 78.7.0 is unable to make sense
of the MIME structure of Werner's email and it only visualizes the
mailing list footer as the body of the email.

I don't know if the issue is with Thunderbird or with Werner's MUA,
although I suspect the first.

Cheers,
Dan


On 29/01/2021 16:09, Werner Koch via Gnupg-users wrote:
> 
> ___
> 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: WKD for GitHub pages

[Daniele Nicolodi]

On 12/01/2021 23:30, Stefan Claas wrote:
> The reason why I like also the option for, let's say github.io pages
> is that, like I have shown in the whole thread that a very well known
> site like GitHub, with it's millions of software developes allows one
> to host, via WKD, a mutli-purpose usage public-key without revealing
> to much details.

I still don't understand why you insist on WKD when it seems to do not
support your use case, nor to offer any advantage over a simpler

wget -O- https://sac001.github.io/foobar.asc | gpg --import

given that the relation between the identifiers
"ste...@sac001.github.io" or "https://sac001.github.io/foobar.asc; and
the key you are retrieving is the same, ie none.

Cheers,
Dan

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

Re: WKD for GitHub pages

[Daniele Nicolodi]

On 12/01/2021 22:17, Stefan Claas wrote:
> On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi  wrote:
>>
>> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
>>> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:
>>>>
>>>> Hi Stefan,
>>>
>>>> So there are two "bugs" involved here.  1. GitHub presenting an invalid
>>>> certificate for the sub-subdomain and 2. Sequoia not noticing that.
>>>> Neither of these are bugs in GnuPG.  If you can accept these facts, then
>>>> it makes sense to further discuss what could be changed where to make
>>>> your desired setup work.  Maybe that discussion will lead to a concise
>>>> change proposal.
>>>
>>> Hi Andre, currently I can only accept the fact that these two "bugs" are
>>> currently not resolved in GnuPG and gpg4win, if you allow me to
>>> formulate it this way.
>>
>> How can GPG solve bugs that are not in the GPG code or infrastructure? I
>> think André did a great job explaining what the issues are. How do you
>> think they can be addressed by GPG?
> 
> If you followed the whole thread you may agree that GnuPG and gpg4win,
> due to the way of how WKD is implemented does not allow wildcard (sub)domains,
> when fetching a pub key from, for example, github.io pages, because it gives
> a cert error for a *valid* SSL cert, while other OpenPGP software,
> like sequoia-pgp,
> can handle this.

It has been explained (several times now) that this is not the cases:
the certificates are invalid for sub-subdomains. Why are you insisting
that they are?

Cheers,
Dan

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

Re: WKD for GitHub pages

[Daniele Nicolodi]

On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:

>> One more question: You're talking about OpenPGP key discovery setups for
>> families and small groups, IIUC.  And that should involve WKD and
>> GitHub.  But how should these people actually get working e-mail
>> addresses @example.github.io?  WKD very specifically ties the key
>> discovery to the control over the involved domain.  It moves part of the
>> trust relationship to the domain administrator.  So who is actually in
>> control over those e-mail addresses?
> 
> Good question Andre! In case of github.io there is apprently no
> email address, which is IMHO a good thing if people like to
> set-up a github.io page and do not want to reveal their real
> email address, to third parties, which is IMHO their good right,
> in case they like to use this github.io pub key as multi-purpose
> key, let's say for multiple email accounts, from other services,
> file transfer, NFC postcards, you name it.

The point of WKD is using the trust of the CA machinery (and the
assumption that the email infrastructure and web servers serving a
specific domain are run by the same organization) to securely retrieve
OpenPGP keys associated to an email address. There keys can then be used
to communicate with the older of the email address.

The party in the communication are identified by email addresses.

In your scheme there are no email addresses. How is retrieving an
OpenPGP key from a random .github.io subdomain from obtaining it in any
other untrusted way? What is the line of trust in the scheme you are
proposing?

Cheers,
Dan

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

Re: WKD for GitHub pages

[Daniele Nicolodi]

On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:
>>
>> Hi Stefan,
> 
>> So there are two "bugs" involved here.  1. GitHub presenting an invalid
>> certificate for the sub-subdomain and 2. Sequoia not noticing that.
>> Neither of these are bugs in GnuPG.  If you can accept these facts, then
>> it makes sense to further discuss what could be changed where to make
>> your desired setup work.  Maybe that discussion will lead to a concise
>> change proposal.
> 
> Hi Andre, currently I can only accept the fact that these two "bugs" are
> currently not resolved in GnuPG and gpg4win, if you allow me to
> formulate it this way.

How can GPG solve bugs that are not in the GPG code or infrastructure? I
think André did a great job explaining what the issues are. How do you
think they can be addressed by GPG?

Cheers,
Dan

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

Re: --export-options export-reset-subkey-passwd

[Daniele Nicolodi]

On 23/08/2017 23:59, Werner Koch wrote:
> On Sun, 13 Aug 2017 08:17, dani...@grinta.net said:
> 
>> Digging a bit more, it seems that the functionality got dropped because
>> with GnuPG 2.x all key manipulations go through gpg-agent and it does
>> not (yet?) support password reset on expert.
> 
> Unfortunately this is still an open bug:
> 
>   https://dev.gnupg.org/T1753
> 
> we won't be able to fix it for 2.2.0 but given that it is marked as a
> bug it can and should be fixed in the soon to be release 2.2 series.

As a work around I come up with this simple script, which has the sole
problem of asking the secret subkey passphrase a few times too much, and
to require to explicitly enter an empty passphrase.

Let me know if it is excessively dummy or if there is a better way.

Cheers,
Daniele


#!/bin/sh

set -e

KEY="$1"
shift

# make sure to have a "!" at the end of the key fingerprint to export
# exclusively the corresponding subkey and not the primary key
if [ "$KEY" == "${KEY%\!}" ]
then
KEY="$KEY"\!
fi

umask 0077
TMPDIR=$(mktemp -d)
trap "rm -r $TMPDIR; exit" 0 1 2 3 15

gpg --export-secret-subkey "$KEY" | gpg --home $TMPDIR --import
gpg --home $TMPDIR --change-passphrase "$KEY"
gpg --home $TMPDIR --armor "$@" --export-secret-subkey "$KEY"


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

Re: [OT] Re: failed to convert unprotected openpgp key: Checksum error

[Daniele Nicolodi]

On 1/22/18 12:30 PM, Kristian Fiskerstrand wrote:
> On 01/22/2018 06:31 PM, Daniele Nicolodi wrote:
>> On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote:
>>> On 01/22/2018 08:33 AM, Werner Koch wrote:
>>>> That is an acceptable user-id.  I would have used a dot as delimiter but
>>>> that is a personal taste.
>>>
>>> Dot is a permitted part of username in POSIX though, while : is not :)
>>
>> Uh? As far as I know, the only characters not allowed are / and null.
> 
> http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html#tag_03_426
> 
>  3.426 User Name

Sorry, I should not be writing email before my morning coffee: I read
filenames instead than usernames.

Cheers,
Daniele

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

Re: [OT] Re: failed to convert unprotected openpgp key: Checksum error

[Daniele Nicolodi]

On 1/22/18 5:31 AM, Kristian Fiskerstrand wrote:
> On 01/22/2018 08:33 AM, Werner Koch wrote:
>> That is an acceptable user-id.  I would have used a dot as delimiter but
>> that is a personal taste.
> 
> Dot is a permitted part of username in POSIX though, while : is not :)

Uh? As far as I know, the only characters not allowed are / and null.

Cheers,
Daniele

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

Re: --export-options export-reset-subkey-passwd

[Daniele Nicolodi]

Hello Werner,

On 8/23/17 11:59 PM, Werner Koch wrote:
> On Sun, 13 Aug 2017 08:17, dani...@grinta.net said:
> 
>> Digging a bit more, it seems that the functionality got dropped because
>> with GnuPG 2.x all key manipulations go through gpg-agent and it does
>> not (yet?) support password reset on expert.
> 
> Unfortunately this is still an open bug:
> 
>   https://dev.gnupg.org/T1753
> 
> we won't be able to fix it for 2.2.0 but given that it is marked as a
> bug it can and should be fixed in the soon to be release 2.2 series.

I would like to help get this fix. What is the plan to implement it?

Thanks. Cheers,
Daniele



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

Re: --export-options export-reset-subkey-passwd

[Daniele Nicolodi]

On 12/08/17 20:15, Daniele Nicolodi wrote:
> Hello,
> 
> I have a workflow were I use this option to reset the subkey passphrase
> during export to a remote system where the subkey is used for unattended
> signing.  This option has been removed in GnuPG 2.1, and I haven't found
> a way to obtain the same result.

Digging a bit more, it seems that the functionality got dropped because
with GnuPG 2.x all key manipulations go through gpg-agent and it does
not (yet?) support password reset on expert.

Is there any plan to bring back this functionality?  I'm willing to
contribute code, but I would need guidance on the foreseen way to
implement this.

Cheers,
Daniele

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

--export-options export-reset-subkey-passwd

[Daniele Nicolodi]

Hello,

I have a workflow were I use this option to reset the subkey passphrase
during export to a remote system where the subkey is used for unattended
signing.  This option has been removed in GnuPG 2.1, and I haven't found
a way to obtain the same result.

Does anyone have any tip?

Thanks! Cheers,
Daniele

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

Re: How to encrypt and sign with different keys

[Daniele Nicolodi]

On 7/18/16 2:49 PM, Dashamir Hoxha wrote:
> On Mon, Jul 18, 2016 at 9:40 PM, d...@mielko.com 
> > wrote:
> 
> I am struggling with GPG command line that will encrypt file with
> key A and sign it with key B.

You can select the key for signing with the --local-user option and the
key for encrypting with the recipient option.

> Also, is there a way to provide the password for the signing key in
> the command line? 
> 
> 
> Try appending this to the command: `--passphrase-fd=0 <<< thepassphrase`

That's most definitely the wrong syntax.

> I am trying to automate encrypting files.

If you want to automate signing consider exporting a signing subkey
without a passphrase. The passphrase would have to be stored along with
the key anyhow.

> Consider also using and customizing `egpg`:
>  - http://dashohoxha.github.io/egpg/gnupg-2.0/man/#CUSTOMIZATION
>  - https://github.com/dashohoxha/egpg/wiki/gnupg-2.0-Customization

Or better not.

Cheers,
Daniele


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

Re: Documentation format

[Daniele Nicolodi]

On 06/02/16 21:59, Robert J. Hansen wrote:
>>> (For the record: yes, I know why org-mode has trouble with i18n export
>>> to LaTeX.  Yes, it's a hard problem.  Yes, fixing it might not be worth
>>> the effort.  All of this is true.  None of it changes how annoyed I am
>>> by the bug, though.)
>>
>> Do you happen to have links to the relevant bug reports, or other
>> documentation of the issues?
> 
> I don't; for all I know nobody's reported it yet.  (If that's the case,
> I should.)  The problem stems from how orgmode assumes that downstream
> tools can parse UTF-8.  LaTeX way predates UTF-8 and requires that
> foreign symbols be composed using TeX escape sequences.  For orgmode to
> translate UTF-8 to LaTeX reliably would require it to keep track of an
> impractically large translation table: Greek characters, French,
> Cyrillic, grave and acute accents, circumflex composition, and more.
> 
> LaTeX is unique among document processing systems in that it can
> effortlessly represent the correct orthography for the rock group Spinal
> Tap (which uses a Turkish dotless lowercase i and a Jacaltec umlauted
> n), but that comes with a steep price: namely, its near complete
> inability to handle Unicode like the rest of the world.

LaTeX handles utf8 encoded input files with \usepackage[utf8]{inputenc}
and on my system org-mode correctly produces utf8 encoded LaTeX files
using that directive. It works just fine for the non-ascii characters
contained in your examples a couple of messages up in the thread.

Can you be more precise in describing the problem?

I would also suggest to look into the org-entities facility as a way to
handle more complex cases: http://orgmode.org/manual/Special-symbols.html

Cheers,
Daniele

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

Re: absolutely nothing to panic over

[Daniele Nicolodi]

On 27/10/15 08:25, listo factor wrote:
> On 10/27/2015 03:55 AM, Robert J. Hansen wrote:
>> You start from tautology and conclude at paradox.  This doesn't appear
>> to be something to be taken seriously.
> 
> Allow me to try again:
> 
> *There is no secure communication over an insecure channel
> without out-of-channel bootstrap*.
> 
> I believe the above can be re-phrased as follows, with no change
> in meaning:
> 
> Cryptography is an art of turning large secrets into small secrets. [1]
> 
> We need a secure channel to transfer small secrets (typically
> the cryptographic device and the key), so that we can communicate
> large secrets over an insecure channel. [2]

If what makes you think that public key cryptography is insecure by
definition is the possibility to circumvent any key exchange protocol
via quantum computation, please note that the same quantum principles
allow for quantum key distribution, which is "quantum secure" key
exchange over an insecure channel.

In general I find broad and overly simplified statements on complex
matter very easy to confute, and I thus believe that they must not be
taken too seriously.

Cheers,
Daniele


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

Re: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)

[Daniele Nicolodi]

On 25/03/15 23:56, Ville Määttä wrote:
 On 26.03.15 00:14, Ingo Klöcker wrote:
 So it's not mailman that's not smart enough, but the mail clients
 the other recipients are using. Mail clients showing a
 signature.asc attachment probably do not understand PGP/MIME
 (which isn't that unusual because only a handful mail clients
 support PGP/MIME out-of-the-box without additional plugins).
 
 It seems to me that emails sent and signed by Thunderbird +
 Enigmail are displayed just fine by it. No signature.asc quirks.
 But emails sent by others are displaying the attachment in addition
 to the normal Enigmail added UI signature information. Ingo, Doug,
 Samir and Bob; I see the attached file for each of you but not my
 own PGP/MIME mails routed back to me from the list :).

The difference must be somewhere else: I use Thunderbird 31.5.0 and
Enigmail 1.8 (20150316-1815) and, while it recognizes the signatures,
I see the attachment signature.asc for all the PGP/MIME signed
emails I've checked.

Cheers,
Daniele



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

Re: Thoughts on GnuPG and automation

[Daniele Nicolodi]

On 03/03/15 14:29, Hans of Guardian wrote:
 It is actually more difficult to wrap GPGME in Java than to have just
 rewritten GPGME in Java.  GPGME is a fine API for C/C++, it is a bad
 API for other languages.  You end up with an API that feels like a C
 API forced into the language, e.g. Java, python, etc.  That makes for
 more coding mistakes because it feels foreign to the programmer.
 More mistakes means more security issues.

Hello,

I have no idea about the Java tooling for interfacing to external
libraries, but (after seeing so many complaints on the mailing list)
I've recently started to work on Python bindings to GPGME using Cython,
and so far it has been an extremely smooth process and the resulting
Python API feels quite pythonic (I haven't started with the asynchronous
calls yet, those will probably be harder to map in a pythonic way).

The fact that writing the bindings is quite easy, is due indeed to the
fact that GPGME is a fine API for C (and to Cython to a large extent).

Cheers,
Daniele


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

Re: Surprising command line options handling

[Daniele Nicolodi]

On 24/02/15 09:34, Werner Koch wrote:
 I find it surprising that unrecognized tokens are simply ignored.
 Wouldn't it be preferable to error out, at least on unrecognized options?
 
 GnuPG does not follow the common GNU model of interchangeable options
 and args.  It is modeled like a classic Unix tool.  Using the special
 option '--' indicates that everything what follows are args and using
 this is suggested to avoid args beeing interpreted as options.
 
 No, we can't error out on an arg which looks like an option because that
 may actually be a valid argument.

Hello Werner,

thank for your answer. Trying to better understand gnupg command line
argument parsing I found that the real confusing thing is that arguments
can be silently ignored:

gpg --list-keys foo

results in an error if there is no key matching foo, however

gpg --list-keys 41E999D7 foo

does not result in an error and the fact that foo does not match any
is not signaled to the user, if there is a key that matches 41E999D7.

I see that in the 2.1 branch there is indeed a check and a warning for
arguments that look like options (start with --) so I must not be the
only one that found this confusing :)

Why do not error out if an argument cannot be used to identify a key? I
think that signaling to the user that one part of the command line has
not been successfully interpreted is good practice.

Cheers,
Daniele


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

Surprising command line options handling

[Daniele Nicolodi]

Hello,

I've been struggling quite a long while today trying to understand why
the following command does not do what I expected:

gpg --export-secret-subkeys 41E999D7! \
--export-options export-reset-subkey-passwd

It does not reset the password on the exported subkey.

After some head scratching I recognized that gpg stop parsing arguments
when it encounters the key id and ignores what follows. This is probably
caused by the fact that whatever follows the first key id is also
interpreted as a possible key id, and that gpg by default does not error
out on invalid key ids. Please correct me if I'm wrong.

There is a reason why gpg does not choke on bad key ids? There is a way
to make the key id parsing strict and avoid surprises as the one above?

Thanks. Cheers,
Daniele

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

Re: Unattended signing

[Daniele Nicolodi]

Hello Daniel,

thanks for your reply.

On 21/02/15 20:11, Daniel Kahn Gillmor wrote:
 On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote:
 I have a sufficient trust in the security of the server where the
 automated process runs, but I would like to reduce to a minimum the risks.
 
 there are risks with unattended signing in general, related to what
 messages you allow to get passed to your system.  I'm sure you've
 already thought about this, but i'll just put it out there in case
 someone else reading this later hasn't thought about it enough.

I was not very clear on this: the unattended signing is performed by an
application that collects some sensible data and sends them by email
encrypted and signed.

 What is the best practices in such cases?  I can imagine several
 possible options: using a subkey of my key (is it possible to remove
 passphrase protection from a subkey?), using a dedicated key, using a
 subkey of a dedicated key and periodically rotate such subkey.
 
 Using a dedicated key for your system would clearly be better than using
 your own personal key, but i don't know if it meets your other
 requirements (we don't know your requirements for the system).
 
 Using a subkey is a reasonable approach, and rotating (and destroying)
 the secret key of the rotated subkey is not a bad idea.

What do you exactly mean by destroying? Isn't setting a suitable
expire date enough?

Thanks. Cheers,
Daniele


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

Re: Surprising command line options handling

[Daniele Nicolodi]

On 24/02/15 00:19, Doug Barton wrote:
 On 2/23/15 2:51 PM, Daniele Nicolodi wrote:
 Hello,

 I've been struggling quite a long while today trying to understand why
 the following command does not do what I expected:

 gpg --export-secret-subkeys 41E999D7! \
  --export-options export-reset-subkey-passwd

 It does not reset the password on the exported subkey.

 After some head scratching I recognized that gpg stop parsing arguments
 when it encounters the key id and ignores what follows.
 
 That's not 100% accurate, but I won't quibble. :)
 
 The man page makes it very clear that the format is as follows:
 
 gpg2 [--homedir dir] [--options file] [options] command [args]
 
 options come before commands, and anything after the command is 
 interpreted as an argument to the command.

In retrospect this is quite clear.

However, the ordering is not really enforced: this

gpg --export-secret-subkeys \
--export-options export-reset-subkey-passwd --armor \
whatever 41E999D7!

or this

gpg --export-secret-subkeys \
--export-options export-reset-subkey-passwd whatever --armor \
41E999D7!

appear to be valid command lines.

I find it surprising that unrecognized tokens are simply ignored.
Wouldn't it be preferable to error out, at least on unrecognized options?

Cheers,
Daniele


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

Re: Unattended signing

[Daniele Nicolodi]

On 18/02/15 19:46, Daniele Nicolodi wrote:
 I have an automated process that collects some data and unattended sends
 it via email. I want that data to be encrypted and signed. The
 encryption part is easy as it requires only public keys of the
 recipients. Signing, however, requires to make the private key used
 available to the process.
 
 I have a sufficient trust in the security of the server where the
 automated process runs, but I would like to reduce to a minimum the risks.
 
 What is the best practices in such cases?  I can imagine several
 possible options: using a subkey of my key (is it possible to remove
 passphrase protection from a subkey?), using a dedicated key, using a
 subkey of a dedicated key and periodically rotate such subkey.

Hello,

I haven't received any comment on this. Is ti because the question is
too dummy, I'm being too naive, or the context is not explained with
sufficient detail?

Thanks for your attention :)

Cheers,
Daniele



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