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

[Juan Miguel Navarro Martínez]

That should go on Tails maillist: tails-ux at boum.org

On 2015/07/14 at 6:16, L wrote:
> 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
>>
> _______________________________________________
> Gpg4win-users-en mailing list
> Gpg4win-users-en at wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
> 

-- 
Juan Miguel Navarro Martínez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20150714/b77b49b4/attachment.sig>