Re: cannot decrypt file symmetric encrypted

[FuzzyDrawrings via Gnupg-users]

Stefano Tranquillini wrote:

> the fact is that no passphrase is asked

When you hit the Enter key after typing your decrypt command, it might also be 
closing the pinentry dialog immediately before it can appear on screen. Make 
sure you don't hold down the Enter key at all - just tap it once as briefly as 
possible.

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

Re: Can not decrypt and verify CD's

[FuzzyDrawrings via Gnupg-users]

Have you tried changing the certificate's Owner Trust? Since you imported the 
private key (as opposed to generating it), the trust is unknown. Owner trust 
should probably be set to "full".

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

Re: packet syntax

[FuzzyDrawrings via Gnupg-users]

Edgar Pettijohn wrote:

>  thought I read somewhere that gpg creates version 4 packets.

True. But the version 4 public-key packet specification only tells you what 
information will be contained in the packet, not the format used for the packet 
header.

- fuzzy

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

Re: packet syntax

[FuzzyDrawrings via Gnupg-users]

Edgar Pettijohn wrote:

> the first word is `99' which in binary would be 
> `10011001'. I was expecting to encounter `11000110'.

You were expecting the packet header to be written in the "new" format, but it 
is actually written in the "old" format (indicated by it beginning with "10" vs 
"11"). See RFC-4880 section 4.2.

Public key packets have a Tag ID of 6, and the "new" format isn't required 
unless the packet has a Tag ID greater than 15. 

-fuzzy

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

Re: draft-ietf-openpgp-rfc4880bis-04

[FuzzyDrawrings via Gnupg-users]

It is definitely my error in the m value I was hashing, which I failed to 
notice was not the same given in the documentation. I somehow repeatedly 
overlooked the fact that my obtained m value was different and only noticed 
that d (the hash) mismatch. Oops. 

Looking more carefully, I see did not in fact get the same value for m and am 
missing its trailing six octets 04ff000c.

Mystery solved. :)

But another more involved problem presents itself:

The value m is obtained as explained under "5.2.3.  {5.2.3} Version 4 Signature 
Packet Format"

| The concatenation of the data being signed and the signature data
| from the version number through the hashed subpacket data (inclusive)
| is hashed.

I can account for every part of that through the hashed subpacket data in the 
value m, but not in m's last six octets: 04ff000c

m: 4f70656e504750040016080006050255f95f9504ff000c
'4f70656e504750' is the text "OpenPGP" being signed.
'04' is the signature version
'00' is the signature type (Signature of a binary document)
'16' is the public-key algorithm (EdDSA)
'08' is the hash algorithm (SHA256)
'0006' is the length of following hashed subpackets (6 octets)
'05' is the length of the first hashed subpacket (5 octets)
'02' is the first hashed subpacket tag (Signature Creation Time)
'55f95f95' is the first hashed subpacket data (2014-08-19 14:28:27)

...and that's the end of hashed subpackets. That should be all that is hashed 
for the signature, yet there is the remaining octets in m:

 04ff000c

 I cannot figure out what information is contained in 04ff000c.  I'm sure 
the answer is some hilarious oversight on my part, but I'm stumped. :/

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

Re: draft-ietf-openpgp-rfc4880bis-04

[FuzzyDrawrings via Gnupg-users]

I don't know if this is an error in the documentation, but I cannot obtain the 
sha256 result here:

| A.2.  Sample EdDSA signature
| 
|The signature is created using the sample key over the input data
|"OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
|function is:
| 
|m: 4f70656e504750040016080006050255f95f9504ff000c
| 
|Using the SHA2-256 hash algorithm yields the digest:
| 
|d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280

I can obtain m, no problem. But fail to obtain d as m's sha256 digest.

Instead I repeatedly get:
d: 30d3de39f655d86b516058ae8c483f1a2cc10f0048882794655d4ce910abb7d6

Can anyone check if they are able to get the result shown in the documentation? 
And if so, is there anything else in addition to m that is input for the sha256 
hash?

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

Re: Keys clean of all signatures except those made by others I trust

[FuzzyDrawrings via Gnupg-users]

On January 24, 2018 11:58 PM, Werner Koch  wrote:

>On Tue, 23 Jan 2018 08:41, gnupg-users@gnupg.org said:
>
>>I would like to clean the key of the spam signatures while preserving
>> any signatures made by Alice (or anyone else I have trusted on my
>> keyring). Does there exist a command/option to accomplish this in
>> gpg2?
>>
> I do blacklisting of certain signatures in my gpg.conf.  A blacklist may
> look like this
>
> import-filter drop-sig=   sig_created_d=2015-12-24
> import-filter drop-sig=|| sig_created_d=2016-03-16
>
> and a whitelist would be
>
> import-filter drop-sig=   sig_created_d<>2015-12-24
>import-filter drop-sig=&& sig_created_d<>2016-03-16
>
> Unfortuntely a property for comparing the key-id or the fingerprint is
> not yet available.  Shall I look into this?

I was able to get the results I needed by using the 'clean' command under 
--edit-key, and also '--import-options import-clean'.

'import-filter' option is unavailable to me as I use the GnuPG versions in 
Ubuntu repository. If I put either the blacklist or whitelist in gpg.conf, GPG 
2.1.11 hangs while GPG 1.4.20 declares it an 'invalid option'

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

Re: Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc

[FuzzyDrawrings via Gnupg-users]

After looking at the content of subpacket 33, it appears to be the 
signing-key's fingerprint prepended by '0x04'.

So I'm guessing subpacket 33 is to be a more robust version of subpacket 16 
(Issuer)?

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

Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc

[FuzzyDrawrings via Gnupg-users]

​Hello, I am working to better understand the OpenPGP standard and how it is 
handled by the current implementation of GnuPG.

To this end I have created a Python program that reads ASCII-Armor and returns 
details about the encoded data within. This is purely for my own edification 
and understanding of how OpenPGP works and also learn Python in the process.  
I'm at the point where I can parse ascii armor to display almost all of the 
information I could otherwise get using "$ gpg --list-packets", including 
calculate the actual key fingerprint (which took a lot of re-reading the 
section of RFC-4880 that explains all the data that must be hashed to produce 
the fingerprint).

Does anyone know what are the additions or changes there are, in terms of 
packet tags, signature types, subpacket types, and algorithm identifiers used 
in the current version of GnuPG but that are not defined in RFC4880?

I've figured out a few on my own: additional public-key algorithm identifiers 
like 18 and 19 (ECDH and ECDSA, respectively, as defined in RFC-6637). And it 
seems that 22 is the identifier for Curve 25517 and/or EdDSA.

One I haven't been able to figure out is signature subpacket type 33. The 
signature files for the downloads on gnupg.org contain this subpacket type, but 
it isn't defined in RFC-4880. Strangely, even my installation of GnuPG does not 
display anything but "(?)" for the meaning of this subpacket's content:

$ gpg2 --list-packets gnupg-2.2.4.tar.bz2.sig
# off=0 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid 249B39D24F25E3B6
version 4, created 1513760871, md5len 0, sigclass 0x00
digest algo 8, begin of digest 75 a5
hashed subpkt 33 len 21 (?)
hashed subpkt 2 len 4 (sig created 2017-12-20)
subpkt 16 len 8 (issuer key ID 249B39D24F25E3B6)
data: [2046 bits]
# off=310 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid 2071B08A33BD3F06
version 4, created 1513762863, md5len 0, sigclass 0x00
digest algo 8, begin of digest 95 36
hashed subpkt 33 len 21 (?)
hashed subpkt 2 len 4 (sig created 2017-12-20)
subpkt 16 len 8 (issuer key ID 2071B08A33BD3F06)
data: [2046 bits]

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

Re: Keys clean of all signatures except those made by others I trust

[FuzzyDrawrings via Gnupg-users]

I guess I had stopped reading about ' clean' after the first line:

>clean  Compact (by removing all signatures except  the  selfsig)

...however the rest of the description indicates it does exactly what I need. 
Doh!

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

Keys clean of all signatures except those made by others I trust

[FuzzyDrawrings via Gnupg-users]

Title says it all.

Say I import Bob's key with "--recv-key" from some keyserver. Bob's public key 
has been signed by a lot of non-serious User ID's and spam. However Bob's key 
may have been signed by Alice (whose public-key I have in my keyring).

I would like to clean the key of the spam signatures while preserving any 
signatures made by Alice (or anyone else I have trusted on my keyring). Does 
there exist a command/option to accomplish this in gpg2?___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users