[Gpg4win-users-en] Private and Public Keys and their Extensions

[L]

Can I take the opportunity to ask a question regarding Tails and its
implemenation of Tor? I have been trying to solve a problem, on an off,
for weeks, looking online for solutions without success. As a result I
have had to use Tor Browser through Windows rather than Tails, not
critical right now, but a serious problem if I do need the fuller
anonymity of Tails, which is thereby negated.

The problem concerns captive portals in public wifi settings. Tails
automatically runs its Tor connection procedure when an internet
connection is enabled, including in captive portal settings, getting as
far as the options panel. I am, of course, then forced to run the unsafe
browser in order to finalise the internet connection.
After this, all attempts to continue with Tor fail: it never connects.

I have tried finding instructions online to allow me to "reboot" Tor
without success; I do not even know where the necessary executable
resides in Linux, nor if I can run this in GUI or have to use the
terminal: none of the files I have tried running works.

Any ideas?

On 7/12/2015 9:11 PM, Daniel Kahn Gillmor wrote:
> Hi L--
> 
> I'll try to answer your questions below, but the narrative style of your
> questions makes it difficult for me to see what's going on concretely.
> 
> Since you seem comfortable using the command line, it would make things
> much clearer if you provided as much of a terminal transcript as
> possible.
> 
> See: https://support.mayfirst.org/wiki/terminal_transcripts for general
> advice on providing terminal transcripts.
> 
> On Sat 2015-07-11 15:56:20 -0400, L wrote:
>> When I generate a key pair using the only commands available in GnuPG, I
>> get TWO files, both with extension .key.
> 
> There are actually several files created or modified, not only two with
> the extension .key.  I think you're talking about files in your GnuPG
> home directory named private-keys-v1.d/<KEYGRIP>.key.  As the
> directory that they're in suggests, those are private keys.  This
> directory is used by GnuPG version 2.1 and later (it is also used by
> older versions of GnuPG when doing S/MIME work).
> 
>> They are apparently named for their fingerprints.
> 
> the files in private-keys-v1.d/ are named for their keygrip, which is a
> different calculation than their fingerprint. (these details are not
> relevant for most users)
> 
>> I have no immediate way of distinguishing what these two files are,
>> are how this corresponds to public and private keys, if at all (you
>> suggest not, I think).
> 
> One of them is the secret part of your primary key, the other is the
> secret part of your subkey.
> 
>> When I input gpg --list-secret-keys, I get nothing. Encrypting a file
>> with my own key and then attempting to decrypt it produces a "no secret
>> key" message.
> 
> These two things make sense together.  if you have no secret keys, then
> decrypting a message should fail with exactly that error message.
> 
> What's less clear to me is why these two things are happening when you
> have files in private-keys-v1.d/ .  what version of gnupg are you using?
> with what installations?  do you have gpg-agent running?
> 
> You can show the answers to these questions with a terminal transcript
> showing the following commands:
> 
>  gpg --version
>  gpg-connect-agent 'getinfo version' /bye
>  gpg --list-secret-keys
> 
>> All of this implies that the creation process is not creating a
>> private/secret key at all, only public ones that can be listed using
>> --list-public-keys (which works) or exported as ascii.
> 
> That would be weird.  the secret key needs to be created at some point
> or it would be impossible to create the OpenPGP certificates.
> 
>> I need a way to identify the .key files created, link them to IDs, and
>> retain the pertinent binary matched to its corresponding ascii key,
>> including isolating my private key (which appears not to exist via this
>> creation method).
> 
> thos files in private-keys-v1.d/ can be associated with other keys by
> keygrip (see --with-keygrip) but you really really do not want to work
> with them manually if possible; they should be controlled by gpg-agent,
> and only by gpg-agent.  if you show what versions of the tools you're
> working with, maybe we'll get more hints.
> 
> Regards,
> 
>         --dkg
>