[Gpg4win-users-en] Private and Public Keys and their Extensions
Juan Miguel Navarro Martínez
juanmi.3000 at gmail.com
Tue Jul 14 13:46:32 CEST 2015
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
>> 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.
> Gpg4win-users-en mailing list
> Gpg4win-users-en at wald.intevation.org
Juan Miguel Navarro Martínez
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: OpenPGP digital signature
More information about the Gpg4win-users-en