[Gpg4win-users-en] Problems with Gpg4Win Verification Operations (and a couple of apparent bugs)

Fri May 29 04:18:11 CEST 2015

Finally, the sum data for Tails is as follows:

Sha 256 Checksum:
a32009af6d65cdc158bb4592f28f64147bbc5c9468693a413333dd7999f93592
Constituent RSAs: DBB802B258ACD84F, 98FEC6BC752A3DB6 and 3C83DCB52F699C56
Key IDs (asc and sig files): 58ACD84F and 752A3DB6
Primary key fingerprint: A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F
Subkey fingerprint: BA2C 222F 44AC 00ED 9899 3893 98FE C6BC 752A 3DB6

On 29/05/2015 02:56, L wrote:
> And now successfully preceded by Key (asc) importation. Indeed, now
> the output shows both primary (key) fingerprint and sub (sig)
> fingerprint, as well as the RSA (absent from GUI execution). A few
> notes, then, for anyone to whom it may concern:
>
> 1) The Gpg4Win GUI is faulty, and a cause of much trouble. It cannot
> be used in verification to gain the data available with the command
> line, though the key (asc) importation will provide immediate access
> to ID, fingerprint, and RSAs.
> 2) The Gpg4Win GUI cannot produce sha256sums: an alternative
> application is required. (For this I used RapidCRCUnicode, in its
> Portable Apps form.)
> 3) Online command lists for Gnu command line are also misleading. Do
> not run gpg.exe, and precede commands by two hyphens not one. The only
> two commands really required are import and verify: "gpg --import
> [path, key (ie. asc) file)]" and "gpg --verify [path, sig file] [path,
> data file]", along with trusting and signing. Include full paths to
> asc, sig and data files. External locations appear to be unworkable (I
> lack much experience in command line to explain why, but perhaps this
> is a command line limitation).
> 4) If the Tails key (asc file) is imported using the GUI, this should
> produce the expected data (as above, origin Tails developers - dates,
> ID -58ACD84F - primary key fingerprint-
> A490D0F4D311A4153E2BB7CADBB802B258ACD84F - and constituent RSAs -
> DBB802B258ACD84F, 98FEC6BC752A3DB6 and 3C83DCB52F699C56).
> 5) "Completely Trusting" the key will not have it appear in the
> Trusted keys field (a bug or misdescription).
> 6) If the sig and iso are verified using the GUI after key
> importation, this will produce only the Tails subkey fingerprint
> (BA2C222F44AC00ED9899389398FEC6BC752A3DB6: the one that was located on
> a Debian list, but fails to be mentioned on the Tails site).
> 7) If the key (asc file) is imported using the command line, it will
> show origin and key ID (Tails Developers, 58ACD84F).
> 8) If the sig and iso are verified using the command line without
> initial key importation, they will show part of the RSAs, seen in the
> subkey fingerprint (752A3DB6).
> 9) If the sig and iso are verified after key (asc) importation, they
> will show "Good signature", and the origin (Tails Developers), and
> both primary and subkey fingerprints (A490 D0F4 D311 A415 3E2B B7CA
> DBB8 02B2 58AC D84F and BA2C 222F 44AC 00ED 9899 3893 98FE C6BC 752A
> 3DB6).
>
> I hope that aids anyone who encounters the problems I did, should they
> locate these notes, and perhaps suggests a number of rectifications
> needed to the Gpg4Win and Tails data.
>
>
>
> On 29/05/2015 01:24, L wrote:
>> I've tried the command line execution, finally with success (ie.
>> actually attempts to verify iso-sig). I get the sign date and an RSA
>> ID (752A3DB6) identifiable to the Tails RSAs available in the key
>> (ie. asc file) (98FEC6BC752A3DB6). It does not, and as far as I can
>> see will never, produce what the Tails instructions say it should,
>> despite the Debian list number (I know Tails is based on Debian, but
>> still). Along with checksum, which I did with another app, that will
>> have to do: it shows the copy is genuine and comes from Tails dev.
>> I suggest to the Tails site people that these issues should be
>> addressed (warnings regarding Gpg4Win and checksums, and whatever is
>> going on with the verification ID data).
>>
>> El
>>
>>
>>
>> On 27/05/2015 00:36, L wrote:
>>> Um. I hav the new key, and there is no problem with that - as I have
>>> said, it is clearly the Tails developer key, by all indicators. The
>>> data on the old key page is just for those who have used the older
>>> key. On the other hand, the ISO verification using the signature
>>> file produces the anomalous string I have quoted. You pointed me to
>>> a Debian list, but the string is not listed on the Tails site.
>>> Regarding verification, it says:
>>>
>>> /If you see the following warning:/
>>>
>>> ////
>>> /Not enough information to check the signature validity.
>>> Signed on ... by tails at boum.org (Key ID: 0x58ACD84F
>>> The validity of the signature cannot be verified.
>>> /
>>> //
>>>
>>> /Then the ISO image is still correct, and valid according to the
>>> Tails signing key that you downloaded. This warning is related to
>>> the trust that you put in the Tails signing key. See, //Trusting
>>> Tails signing key
>>> <https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html>//.
>>> To remove this warning you would have to personally //sign
>>> <https://en.wikipedia.org/wiki/Keysigning>//the Tails signing key
>>> with your own key./
>>>
>>> https://tails.boum.org/download/index.en.html#download.verify-the-iso-image-using-other-operating-systems
>>>
>>> This is not the result I have, and the statement lacks any such
>>> string; the ID shown is the Tails developer key (as I have said,
>>> imported and verified). So what of this anomalous string, which you
>>> apparently located on a Debian list? Bear in mind, the Tails iso,
>>> downloaded several times from different locations, checksums fine,
>>> and I have of course also downloaded the asc and sig files numerous
>>> times, including through TOR, easy given their tiny size. If the Iso
>>> is a fraud, I need to know that, though if that is the case it is
>>> hard to see how I am going to get a genuine copy after so many
>>> attempts. If the sig-iso output is actually correct, what the hell
>>> is it doing on an obscure Debian list, and why on earth have Tails
>>> misstated the verification data?
>>>
>>> Thanks again.
>>>
>>>
>>> On 26/05/2015 22:17, Juan Miguel Navarro Martínez wrote:
>>>> The information about Tails key was given in this post about the
>>>> transition from the old to the new one:
>>>>
>>>> https://tails.boum.org/news/signing_key_transition/index.en.html
>>>>
>>>> You can compare the IDs/Fingerprints which the ones you have, but I can
>>>> tell you yours matches.
>>>> L:
>>>>> Thanks. If that is the case, it should certainly be listed on the Tails
>>>>> site; I found no mention of the string there, when I last checked, only
>>>>> that of the developers key from the Tails site (you can download it
>>>>> there yourself):
>>>>>
>>>>> User-ID:
>>>>>
>>>>> 	
>>>>>
>>>>> Tails developers (offline long-term identity key) <tails at boum.org>
>>>>>
>>>>> Validity:
>>>>>
>>>>> 	
>>>>>
>>>>> from 2015-01-18 14:17 through 2016-01-11 14:17
>>>>>
>>>>> Certificate type:
>>>>>
>>>>> 	
>>>>>
>>>>> 4,096-bit RSA
>>>>>
>>>>> Certificate usage:
>>>>>
>>>>> 	
>>>>>
>>>>> Signing EMails and Files, Certifying other Certificates
>>>>>
>>>>> Key-ID:
>>>>>
>>>>> 	
>>>>>
>>>>> 58ACD84F
>>>>>
>>>>> Fingerprint:
>>>>>
>>>>> 	
>>>>>
>>>>> A490D0F4D311A4153E2BB7CADBB802B258ACD84F
>>>>>
>>>>>
>>>>> Neither can it be found among the IDs (see Technical Details):
>>>>> DBB802B258ACD84F/98FEC6BC752A3DB6/3C83DCB52F699C56
>>>>> Nor does it match anything stated in sig-iso verification. That was the
>>>>> whole point :)
>>>>>
>>>>>
>>>>> On 26/05/2015 04:37, Juan Miguel Navarro Martínez wrote:
>>>>>> L:
>>>>>>> 3) I will also try trusting the Tails key using my own key; still,
>>>>>>> Gpg4Win does offer the ability to " completely trust" a key without
>>>>>>> using your own, and even when this is the case, the key fails to
>>>>>>> appear in Kleopatra's trusted field, also an apparent bug. If the
>>>>>>> trusted field only admits keys when signed with your own, this
>>>>>>> should be made clear.
>>>>>> You can give a trust level using command-line but it won't affect
>>>>>> Kleopatra "Trusted keys" list, it only will show if you sign it with
>>>>>> your own key.
>>>>>>
>>>>>> I would try and confirm it but I'm having some problems here.
>>>>>>
>>>>>>> 4) This still fails to account for the unidentified string (short
>>>>>>> and post-key-imported long), unmatched to anything on the Tails
>>>>>>> site, the real issue. Can anyone account for this string
>>>>>>> (/0xBA2C222F44AC00ED9899389398FEC6BC752A3DB6)?
>>>>>> That's Tails developers signing subkey:
>>>>>>
>>>>>> https://paste.debian.net/183806/
>>>>>>
>>>>>> See the second key fingerprint, it matches the 0xFingerprint key ID
>>>>>> format you typed.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Gpg4win-users-en mailing list
>>>>>> Gpg4win-users-en at wald.intevation.org
>>>>>>
>>>>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Gpg4win-users-en mailing list
>>>>> Gpg4win-users-en at wald.intevation.org
>>>>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Gpg4win-users-en mailing list
>>> Gpg4win-users-en at wald.intevation.org
>>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
>>
>>
>>
>> _______________________________________________
>> Gpg4win-users-en mailing list
>> Gpg4win-users-en at wald.intevation.org
>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
>
>
>
> _______________________________________________
> Gpg4win-users-en mailing list
> Gpg4win-users-en at wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20150529/b3c553fa/attachment.html>