Re: [paperkey] Always output "interrupt"

[David Shaw]

On Jun 20, 2018, at 11:28 AM, Damien Cassou  wrote:
> 
> David Shaw  writes:
>> Which version of paperkey is this?
> 
> both the version from source and from Fedora package are 1.5.
> 
>> If that doesn't resolve your problem, can you send me a sample secret
>> key (not your real secret key, of course - just generate a dummy one)
>> that exhibits the problem?  I'll make it work.
> 
> Please find attached the very secret key :-).

I tested this on my regular development box and it worked fine.  Just for 
completeness, I spun up a Fedora 28 VM and it worked fine there as well.  It 
occurs to me that given the pipeline you were using, the "interrupt" error may 
have come from gpg2 rather than paperkey:

> $ gpg2 --export-secret-key "FooBar" | paperkey -

What happens if you do this:

$ gpg2 --export-secret-key "FooBar" > /tmp/foo.key
$ paperkey < /tmp/foo.key

David


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

Re: [paperkey] Always output "interrupt"

[David Shaw]

On Jun 20, 2018, at 5:14 AM, Damien Cassou  wrote:
> 
> Hi,
> 
> The output of paperkey is just "interrupt" instead of being a printable
> output. I've tried to use paperkey on 2 different main private keys and
> failed twice. I tried with both the Fedora package and from paperkey's
> source. Same result in every case.
> 
> System:
> - Fedora 28
> - gpg (GnuPG) 2.2.8, libgcrypt 1.8.3
> 
> Keys:
> - key1: ed25519
> - key2: rsa4096
> 
> Command:
> $ gpg2 --export-secret-key "FooBar" | paperkey -
> interrupt
> $

Hi Damien,

Which version of paperkey is this?  The latest is 1.5 (and support for EdDSA 
keys was only added in that version), so if you're using an old version can you 
try the latest?

If that doesn't resolve your problem, can you send me a sample secret key (not 
your real secret key, of course - just generate a dummy one) that exhibits the 
problem?  I'll make it work.

David


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

Re: GnuPG public key vulnerability?

[David Shaw]

On Oct 31, 2017, at 8:10 PM, murphy  wrote:
> 
> I got a signed notification from facebook (good signature, enigmail)
> that claims my GnuPG generated public key has a "recently disclosed
> vulnerability".  This is the full text:
> 
> We have detected that the OpenPGP key on your Facebook profile may be
> susceptible to attacks due to a recently disclosed vulnerability.  We
> recommend that you revoke and replace your public key immediately to
> minimize the risk to your encrypted communications.  You can update your
> public key by visiting your Security and Login settings.  To help reduce
> the risk of your key being attacked, we have set the privacy of your
> potentially vulnerable public key on your profile to "Only Me" to limit
> further distribution.  We will continue to encrypt your notification
> emails using this OpenPGP public key.
> 
> This is doubly weird since the private/public key was generated on a
> Yubikey-4 nano and it is safe at home.  Does anyone know what this may
> be about?

Yes.

Recently, a flaw in the firmware for some Infineon hardware crypto was found.  
RSA keys that were generated with this faulty firmware are not nearly as strong 
as their key length would imply.

You mention a Yubikey 4 nano, and unfortunately, that is one of the devices 
that used Infineon components.  In the case of a Yubikey and OpenPGP, if you 
generate the key *on* a vulnerable Yubikey, you may have a problem.  If you 
generate the OpenPGP key elsewhere and *import* the key to your Yubikey, you 
are not affected.

The Yubico people have a site up to check your device serial number to see if 
it is vulnerable and are offering a replacement program.  See 
https://www.yubico.com/keycheck/

There has been some discussion of the implications of this vulnerability on 
this list.  Search the list archives for "ROCA" to see more.

The original paper is at https://crocs.fi.muni.cz/public/papers/rsa_ccs17

David


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

Re: suspicious key found

[David Shaw]

On May 16, 2017, at 9:47 AM, Janne Inkilä  wrote:
> 
> I made a key search with my name and found something suspicious.
> 
> The search:
> 
> https://pgp.mit.edu/pks/lookup?search=janne+inkila&op=index&fingerprint=on
> 
> I have used my old key since 2007. Fingerprint F4DB 40F8 BF22 8B9D 9B8F  F679 
> A482 4C9A 033E 22A2. I know this is quite old key and maybe I should revoke 
> it.
> 
> BUT
> 
> I also found another key with fingerprint 87C4 F4C8 16D1 3CC3 03E0 7977 1A9C 
> 6259 033E 22A2. The key ID is the same 033E 22A2 on both keys. There's also 
> signatures in this key. Looks like same persons and same key ID's but 
> fingerprints doesn't match. For some reason this key has been revoked.
> 
> Did someone really generated same looking key? And why? Any ideas? Someone 
> tries to capture my emails? I would like to see some sort of theory what is 
> going on, thanks :)

There are many such fake keys on the keyservers.  I have one as well.  It's 
trivial to forge the short (8 hex digit) key ID - just keep generating keys 
over and over until you match the lower 32 bits.  Note that the fingerprints do 
not match, as there is no (current) way to forge an entire fingerprint.

See https://evil32.com - they made the keys as a demonstration, but didn't 
upload them.  It's an excellent demonstration why people should never trust the 
short key ID for anything.

David


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

Re: Trust signature domain

[David Shaw]

On Jan 16, 2017, at 11:52 AM, John Lane  wrote:
> 
> I'm trying to experiment with trust signatures but I can't work out how
> the 'domain' question is used ?
> 
> I think I understand what it is for, but I can't enter a value and get
> it to work.
> 
> I have a key A that has signed b...@example.com and c...@example.org
> 
> If I tsign A at level 2 with the domain blank then B and C are fully valid.
> 
> If I tsign A at level 2 with a domain of example.com then neither are
> valid. I expected B to be valid.
> 
>> From what I've read, I think this value might be a regular expression
> and need to be entered in a certain way.

The value is a regular expression internally, but you don't need to enter it as 
one.   GnuPG automatically takes what you enter into the domain field and 
converts it to a regexp.  For example:

  example.com

becomes:

  <[^>]+[@.]example\.com>$

Can you post the actual user IDs of the keys you are testing with (or a similar 
example.com set) so I can try them as well?

David


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

Re: File Encrypted with Primary key

[David Shaw]

On Aug 19, 2016, at 11:56 AM, Scott Linnebur  wrote:
> 
> I have an issue that I just cannot figure out.  What I’m trying to do is move 
> a file between two organizations using two different transports while 
> encrypting the file.  On one side they use ipswitch movit to encrypt the file 
> and post it to a sftp site.  Then from my end I use camel to pick up the 
> file, decrypt it and place it where it needs to go internally.  What I have 
> done is generate a key pair with GPG and have given the other company my 
> public key to encrypt with as well as imported the key rings into Camel.
>  
> Testing…
> They post the encrypted file and when my camel process pull is down I get the 
> error “exception creating cipher”.
> If I manually pull down the file I can decrypt it fine with GPG.
> If I encrypt a test file with my own public key and feed it to Camel it 
> decrypts fine.
>  
> This is where I think the problem is but I can’t figure out a way to prove 
> it.  When I generated the key pair with GPG, it created a primary and 
> secondary keys.  Primary has usage set to SC and secondary set to E.  When I 
> look at the file they sent me, it’s encrypted with the primary key.  That 
> file fails in the camel process but is successful in a manual GPG decyption 
> process.  When I encrypt a file with GPG it uses the secondary key and I can 
> decrypt it with Camel or manually with GPG.  I have a suspicion that is the 
> cause but I can’t test it.  I can’t find anyway to force the primary key to 
> encrypt and I can’t figure out how to generate a key pair without secondary 
> keys in it.  Any ideas how to troubleshoot this?  The secondary party is not 
> helpful and they are using their standard process with moveit to encrypt it 
> and aren’t likely to change that, especially if I can’t prove that’s what’s 
> wrong.

I have seen this before - basically the Moveit code is using a buggy/older 
OpenPGP engine that does the wrong thing and ignores key flags.  Your key has 
an RSA primary key, and their engine sees that and concludes that since it's 
RSA, it can encrypt to it.  GPG properly respects key flags so uses the subkey.

There is only one fix for this, but two workarounds:

1 (the true fix): Get Moveit to fix their OpenPGP engine.  That's likely not an 
easy task since Moveit most likely purchased it from an upstream vendor (I'm 
going to guess Symantec - I have a vague recollection the previous time I saw 
this was with the Symantec code), so the actual fix would need to be from the 
upstream vendor, then Moveit would have to integrate it, and then whoever 
you're communicating with would have to update Moveit.  Given that this problem 
still exists in 2016, I'm going to guess that a fix here is not going to happen 
any time soon!

2 (workaround A): You can generate a key that explicitly permits encrypting to 
the primary key.  Then both GPG and Moveit will encrypt to the primary and 
everyone can interoperate.  This is not ideal as it is best practice to split 
the signing and encryption capabilities, but should solve your immediate 
problem.

3 (workaround B): Don't use an RSA primary key.  Instead of generating a RSA 
primary key with an RSA subkey, generate a DSA primary key with an Elgamal 
subkey (or for that matter, an RSA subkey - what matters here is the primary is 
DSA).  This pretty much forces the Moveit code to encrypt to the subkey since 
there is no way to encrypt to a DSA primary key (it's a signature-only 
algorithm).

My advice would be to try workaround B first.  If they're using the same engine 
that I saw before, it was smart enough to handle that case and would properly 
use the subkey.

David


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

Re: Remove photos from OpenPGP key in the keyservers

[David Shaw]

On Mar 8, 2016, at 6:54 AM, Marco A.G.Pinto  
wrote:
> 
> Hello!
> 
> I have made the mistake of adding the same photo with different file sizes 
> using Enigmail and export it to the servers.
> 
> I have already deleted two of the three photos using the CLI, but the key in 
> the server still has three photos and a size of 70 kB.
> 
> Is there anyone I could contact to export this attached public key which only 
> has one photo?

Alas, no.  Like other key items (user IDs, signatures, subkeys), the keyservers 
are strictly additive.  Once you add something, the servers have no means to 
remove them.

The most you can do is revoke those photos (like you'd revoke a user ID).  That 
does not remove them, but at least marks them as no longer intended.

David


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

Re: Possible values for --compress-level and --bzip2-compress-level

[David Shaw]

On Feb 24, 2016, at 9:11 AM, Josef Carnap  wrote:
> 
> Hello everyone,
> 
> I have a question to the options --compress-level and
> --bzip2-compress-level. Which are the supportet (possible)
> values of each of the options? -- Numbers from 0 up to 6?

1 through 9, with 1 being the least compression (but generally runs faster) and 
9 being the most compression (but generally runs slower).

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

Re: Hash selection failure on 2.1.1

[David Shaw]

On Jan 17, 2015, at 5:48 PM, Robert J. Hansen  wrote:

> quorra:~ rjh$ grep default-pref .gnupg/gpg.conf
> default-preference-list SHA256 RIPEMD160 AES256 CAMELLIA256 TWOFISH 3DES
> 
> 
> ... As I understand the way algorithms are selected, GnuPG uses the
> most-preferred algorithm in my list that is also present in the
> recipient's capability set.  Since SHA-1 implicitly follows after SHA256
> and RIPEMD160, it has the lowest priority.

That's basically how it works for "personal-digest-preferences", but you're 
showing your "default-preference-list".  They're very different.  
default-preference-list sets the default preferences for new keys and is not 
part of the digest choice when signing.

> By my understanding, GnuPG should start by trying SHA256 and discovering
> Raven doesn't advertise that as a capability.  It should then try
> RIPEMD160 and see Raven advertises that, and thus it should use RIPEMD160.

Not in this case.  That's a clearsigned message above, and so GnuPG has no way 
to know who your recipient is.  If you were encrypting & signing, it could know 
based on the recipient key, but there is no "recipient key" for a signed (only) 
message.  Without a recipient, there are no preferences for it to consult 
beyond stuff (personal-digest-preferences, usually) in your config file.

There are a bunch of steps GnuPG follows when selecting a digest for signing 
without a recipient, but outside of the cases when it is forced to use a 
particular algorithm (due to DSA size requirements, smartcard capabilities, or 
the like), the main steps are "If digest-algo is set, use that.  Otherwise, if 
personal-digest-preferences is set, use that.  Otherwise, use SHA-1."

Do you have a personal-digest-preferences (or even digest-algo) set in your 
config file?

David


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

Re: relationship between primary keys and subkeys

[David Shaw]

On Jan 16, 2015, at 7:56 AM, Salih Kardan  wrote:
> 
> Hi everyone,
> 
> I have two simple questions about subkey mechanism. I search gnupg 
> documentations and mailing list, but could not find answers to my questions. 
> I would be so glad, if someone can answer below questions. 
> 
> 1) Is it possible to create a subkey of a subkey ?

No.  Primary keys own/parent subkeys.  There is no nesting beyond that.

> 2) What are the trust implications between a parent key and a child key? Is 
> it "Ultimate Trust"? How can we confirm this? Or is this something for us to 
> determine/interpret?

It's not really something that needs interpretation or calculation.  
Essentially you trust a subkey exactly the same way you trust the parent key 
for that subkey.   The interpretation and calculation is done for the parent 
key.

David


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

Re: Vanity Keys

[David Shaw]

On Jan 13, 2015, at 10:11 PM, Sandeep Murthy  wrote:
> 
> Hi
> 
>> Only the right key will actually work for verification, but the program may 
>> not be able to find that right key.
> 
> Wouldn’t this issue of possible collisions in the long key ID (64 bits / 16 
> hex digits)
> causing problems for the GPG program only be an issue in an organisational 
> setting,
> where there is a large number of users sharing that program and where keys
> are uploaded to/retrieved from key servers using short IDs?
> 
> For an individual who for example only imports keys with fingerprints (160 
> bits /  40 hex) and
> publishes their fingerprint rather than the short or long key ID, how can 
> this risk arise
> or is there still an issue with key servers?

Unfortunately, it doesn't matter if users only use fingerprints when deciding 
to import a key or not.  Internally, keys are looked up using the 64-bit key 
ID.  This is a limitation of OpenPGP - the "issuer" of a signature is 64 bits 
long.  If the user manages to get two keys that happen to have the same 64-bit 
key ID (the lowest 64 bits of the fingerprint, for OpenPGP keys) then this 
problem applies to them.

The discussion on gnupg-devel is about adding a larger issuer that contains the 
complete fingerprint.

David


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

Re: Vanity Keys

[David Shaw]

On Jan 13, 2015, at 2:53 PM, NdK  wrote:
> 
> Il 13/01/2015 16:34, David Shaw ha scritto:
> 
>> I like the idea of adding a proper fingerprint to signature packets.  I seem 
>> to recall this was suggested once in the past, but I don't recall why it 
>> wasn't pursued.
> What I don't understand (surely because of my ignorance of GPG inner
> working) is what that should add to the security... IOW, if the private
> key have been generated by a third party to have a certain fingerprint,
> what's the purpose of adding that fingerprint to the signature?

OpenPGP uses the 64-bit key ID to locate keys.  If two people have the same 
64-bit key ID, it doesn't mean that person A can impersonate person B, but it 
does mean that if both person A and person B's keys are on a given keyring, the 
verifying program will not know which key to use to check the signature.  Only 
the right key will actually work for verification, but the program may not be 
able to find that right key.

The fingerprint is a 160-bit key ID - effectively impossible (given today's 
knowledge) to impersonate.

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

Re: Vanity Keys

[David Shaw]

On Jan 13, 2015, at 3:10 AM, Werner Koch  wrote:
> 
> On Mon, 12 Jan 2015 21:51, gn...@lists.grepular.com said:
> 
>> Apparently some of the funds will be donated to the GnuPG project. I suspect
>> he hasn't been in contact, and I imagine the funds would not be welcome?
> 
> I have not heard about it but given that the Wau Holland Stiftung is
> collecting GnuPG donations also via Bitcoin, it is likely that this
> can't be tracked.
> 
> However, if that processing power is used to find many dups for long
> keyids we will sooner or later neet to invest work to mitigate the
> effect of this (e.g. adding a fingerprint as signed attribute to each
> signature).

I'm sort of amused by vanitykeys.io.  If you read the HN thread, the author is 
pretty willing to accept this isn't the greatest idea, and has updated the page 
to say that.  (Of course, he hasn't taken the thing down completely either..)

I like the idea of adding a proper fingerprint to signature packets.  I seem to 
recall this was suggested once in the past, but I don't recall why it wasn't 
pursued.

David


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

Re: DSA key sizes

[David Shaw]

On Nov 10, 2014, at 8:56 AM, Robert J. Hansen  wrote:

>> FIPS-186-3, the document that specifies DSS (aka DSA with some
>> additional restrictions as to algorithm, key length, etc) specifies 4
>> key sizes:
> 
> Five, but nobody uses DSA-512 and I think it's been formally obsoleted.
> But yes, DSA-512 is a real thing, although GnuPG never supported it
> (for good reasons -- it was seen as marginal even when it first came out!).

No, four. Section 4.2 of FIPS-186-3:

  This Standard specifies the following choices for the pair L and N (the bit 
lengths of p and q, respectively):

  L = 1024, N = 160
  L = 2048, N = 224
  L = 2048, N = 256
  L = 3072, N = 256

http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf

Remember that the FIPS-186 documents cover DSS, not DSA.  There was a < 
1024-bit DSS, but it didn't make it into FIPS-186-3.

It's also not the case the GnuPG never supported 512-bit DSA.  You could 
generate a 512-bit DSA until 1024 was made the minimum in late 2004.  Even 
today, it's possible to generate a 512 bit DSA key in 1.4.x if you use 
--expert.  (Not that you should).

David


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

Re: DSA key sizes

[David Shaw]

On Nov 10, 2014, at 7:00 AM, Nicholas Cole  wrote:

> Just out of curiosity: DSA key sizes are now rounded to one of 3
> values, whereas RSA keys are available in a range of sizes between two
> limits.  Why the difference?

FIPS-186-3, the document that specifies DSS (aka DSA with some additional 
restrictions as to algorithm, key length, etc) specifies 4 key sizes:

  1024 bit key, 160 bit hash
  2048-bit key, 224 bit hash
  2048-bit key, 256 bit hash
  3072-bit key, 256 bit hash.

To be closer to FIPS, GnuPG rounds up to the next 1024-bit boundary when making 
DSA keys.  The hash rules are keys 2048 bits and over use a 256-bit hash, keys 
over 1024 bits use a 224 bit hash, and 1024 and under use a 160 bit hash 
(classic DSA).  GnuPG skips the 2048/224 option in favor of 2048/256.

In --expert mode you can select whatever key size you like without rounding, 
but the same hash size rules still apply.

David


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

Re: encrypting to expired certificates

[David Shaw]

On Sep 17, 2014, at 3:54 PM, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi
> 
> 
> On Tuesday 16 September 2014 at 11:03:29 PM, in
> , Doug Barton wrote:
> 
> 
> 
>> When you get into the edit-key menu you can do 'uid *'
>> (or specifically select the uids you want to update, if
>> not all). Then update the expiry.
> 
> Do key UIDs have an expiry date? I never noticed that.

Both keys and UIDs can have expiration dates in OpenPGP.  Though both date 
fields live on the UID self-sig, they're not the same thing and aren't 
necessarily set to the same value.

GnuPG, like most OpenPGP clients, only really implements key expiration, though 
it should properly honor a UID expiration if someone generates it elsewhere.

David


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

Re: encrypting to expired certificates

[David Shaw]

On Sep 15, 2014, at 3:06 PM, Hauke Laging  wrote:

> Am Mo 15.09.2014, 09:47:21 schrieb David Shaw:
> 
>> I disagree with this.  Expiration is the way the key owner (the person
>> who knows best whether the key should be used or not) tells the
>> world, "Do not use this key after this date".
> 
> Where do you take that from? Neither the RfC uses this description nor 
> GnuPG nor any GUI I know. It is OK (not meaning: being safe from getting 
> criticized by the key owner for sending clear text instead) if you treat 
> the expiration date this way. But it is absolutely not OK to enforce 
> this really not obvious interpretation on others.

I suspect that the word "expired" was expected to be clear on its own in the 
RFC.  If there was some non-common meaning of expired, the term would have been 
explicitly defined.  RFCs don't seek to confuse things.  5.2.3.6 defines it as 
"the validity period of the key".  In other words, after that specified time 
has elapsed, the key is not valid.

Are you arguing that in other places we allow people to use non-valid keys, so 
why not here as well?  I don't agree with that, but I do understand it.  
("valid" being a fairly weakly defined term without, yes, policy).

In any event, the choice being presented here between "use an expired key" vs 
"send in plain text" strikes me as misleading.  There is a third case, which is 
"Stop.  Something is wrong.  Figure it out before proceeding."

David


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

Re: encrypting to expired certificates

[David Shaw]

On Sep 14, 2014, at 9:05 PM, Hauke Laging  wrote:

> Hello,
> 
> after filing a bug report for my mail client because it does not allow 
> me to encrypt to an expired certificate (neither does Enigmail) I was 
> surprised to notice that I didn't manage to encrypt to an expired 
> certificate with gpg in the console (2.0.22).
> 
> Is this not possible (what about gpgme?) or am I just not aware of how 
> to get that done?
> 
> I would consider not being able to encrypt to an expired key a severe 
> security flaw because it may force the sender to send the message 
> unencrypted. It is OK to warn the user but it must be possible to 
> override this warning. Expiration is not a security problem (let alone a 
> severe one).

I disagree with this.  Expiration is the way the key owner (the person who 
knows best whether the key should be used or not) tells the world, "Do not use 
this key after this date".  If someone encrypts to the key anyway, they are 
going against the key owner's statement.

I'm sure people can come up with particular scenarios where it is either okay 
or very not okay to use a key after it is expired, but either way, the key 
owner gave a date.  Who are we to disregard that?

David


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

Re: HP-UX and GnuPG

[David Shaw]

On Aug 13, 2014, at 4:20 PM, Bill HT  wrote:

> We are on HP-UX ver 11.11 U 9000/800. GnuPG 2 was installed at 
> /usr/local/bin, we have to call it with the at path to do anything with it: 
> /usr/local/bin/gpg2. I can list keys and import keys. However, when trying to 
> generate keys or encrypt, we get this error: "no entropy gathering module 
> detected”. I was under the impression that EGD is part of GPG, is there some 
> reason why it isn’t seeing it? Or is it just not there?

While GPG can make use of an EGD, EGD is not part of GPG.

That said, I'm not very familiar with HP-UX, but I was under the impression 
that 11.11 either had, or could download a package from HP, that gives you a 
true /dev/random (which GPG can then use).  Have you read 
http://newfdawg.com/SSHpart5.htm ?

David


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

Re: what is "correct" for users' Preferred keyserver ?

[David Shaw]

On Aug 14, 2014, at 1:08 AM, Doug Barton  wrote:

> On 08/12/2014 11:27 PM, shm...@riseup.net wrote:
>> i've seen a multitude of ways people input data into this pref
>> 
>> for example, some people put a link to their public key .asc or .txt file
>> 
>> some others put a link to an actual keyserver
>> 
>> from the name of the actual pref, it states a keyserver, so shouldn't
>> users input a link to their Preferred keyserver and not a link to
>> download a public key or txt file ?
> 
> Please don't use this option, or encourage its use. It leads to the trap 
> described here:
> 
> https://dougbarton.us/PGP/stale-keyserver-url.html
> 
> which most users (even those few who update their keyrings) cannot figure out 
> how to escape.

Perhaps the problem here is not the option, but the behavior on failure.  If 
querying the preferred keyserver does not return a response during a refresh 
(for whatever reason), maybe GPG should continue on and try to get the key from 
the standard --keyserver location.

After all, it's a "preferred" keyserver.  Not an "exclusive" keyserver.

David


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

Re: what is "correct" for users' Preferred keyserver ?

[David Shaw]

On Aug 13, 2014, at 2:27 AM, shm...@riseup.net wrote:

> i've seen a multitude of ways people input data into this pref
> 
> for example, some people put a link to their public key .asc or .txt file
> 
> some others put a link to an actual keyserver
> 
> from the name of the actual pref, it states a keyserver, so shouldn't
> users input a link to their Preferred keyserver and not a link to
> download a public key or txt file ?

It can be either.  The definition of that option in the protocol is:

   This is a URI of a key server that the key holder prefers be used for
   updates.  Note that keys with multiple User IDs can have a preferred
   key server for each User ID.  Note also that since this is a URI, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

GnuPG supports both the keyserver, and link-to-key cases.

David


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

Re: Seeking clarification with a few GPG concepts

[David Shaw]

On Aug 14, 2014, at 5:46 AM, Peter Lebbing  wrote:

> On 13/08/14 23:51, David Shaw wrote:
>> Try this:
>> 
>>  gpg2 --expert -u (thekey) --edit-key (thekey)
> 
> Ah! I never thought of trying good old --expert. Thanks!

It may be appropriate to not need --expert for this specific case of re-signing 
a revoked user ID.  --expert is odd corner cases and "don't try this at home" 
sort of stuff, and re-signing a UID is perhaps uncommon, but certainly a 
straightforward operation in OpenPGP.

I'll take a look.

David


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

Re: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 14, 2014, at 1:20 AM, Doug Barton  wrote:

> On 08/12/2014 08:41 PM, David Shaw wrote:
>> Maybe the answer is to remove the things to generate PGP 2 messages 
>> specifically, and leave the other stuff?
> 
> Yes please. :)
> 
> Not being able to encrypt/sign with PGP 2 at this point is totally 
> reasonable. Not being able to decrypt/verify leads to toolchain complications 
> down the road for people with such archives, and sends a dangerous message 
> that we're not serious about backwards compatibility.

I think the context has been lost in that sentence.  The "other stuff" I was 
referring to was --pgp6, --pgp7, etc.  The --pgpX options in general.  There 
was never a question of removing the ability to decrypt PGP 2 messages.  As you 
say, that would destroy the ability to decrypt old messages.

David


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

Re: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 13, 2014, at 3:56 AM, Werner Koch  wrote:

>> state.  One place that comes to mind is in --gen-revoke.  GPG can
>> import a bare revocation certificate.  No version of PGP can, so there
>> is code to push out a minimal public key before the revocation
>> certificate.  We'd need to add some sort of flag to indicate to
>> include the minimal public key, and that's sort of reinventing --pgp
> 
> That is
> 
>  if (keyblock && (PGP2 || PGP6 || PGP7 || PGP8))
>{
>  /* Use a minimal pk for PGPx mode, since PGP can't import bare
> revocation certificates. */
>  rc = export_minimal_pk (out, keyblock, sig, NULL);
> 
> Thus removing PGP2 won't harm.
> 
>> Maybe the answer is to remove the things to generate PGP 2 messages
>> specifically, and leave the other stuff?  That feels a bit messy.
> 
> Actualluy this was my idea.  However, signature verification has some
> kludges for PGP2 and we could consider to remove that too.  IIRC, this
> is not even controlled by an option.

I agree.  But I wasn't clear enough - the "other stuff" I'm referring to above 
is the (PGP6 || PGP7 || PGP8).  That is, removing --pgp2 and leaving the 
others.  On second consideration, though, the --pgpX options are at least 
theoretically OpenPGPish (some more than others!), so having those options stay 
is reasonable.

David


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

Re: Seeking clarification with a few GPG concepts

[David Shaw]

On Aug 13, 2014, at 8:22 AM, Peter Lebbing  wrote:

> It is precisely as you said, GnuPG does allow reinstigating a revoked
> UID. However, there is a slight hitch in the UI that means you can't do
> it completely straight-forwardly. You need to delete the offending UID
> before re-adding it, but other than that, it works, and the
> certifications are even carried over.

Try this:

  gpg2 --expert -u (thekey) --edit-key (thekey)
 Select the uid you want to un-revoke
  sign
 You'll get a prompt like " was already signed by key Y.  Do you 
want to sign it again anyway?".  Say "yes".

David


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

Re: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 12, 2014, at 3:33 AM, Werner Koch  wrote:

> On Tue, 12 Aug 2014 00:08, ds...@jabberwocky.com said:
> 
>> Rather than fixing RFC-1991 support, why not go in the other direction
>> and make it clear that it isn't supported, and won't work?  I did a
>> bunch of work to make --pgp2 work well and interoperate with PGP 2.x
>> over a decade ago.  Even then it was intended as a stopgap measure
>> until people finally stopped using PGP 2.x.  Over 10 years later, it's
>> well past time to kill it.
> 
> I fully agree.  Do you mean to document it or to remove the function and
> change the options to print a warning message that they don't do
> anything?  For 2.1.

How about remove the functions in 2.1, and add a warning (in the docs, and 
perhaps upon use in the code) that the functions will be going away in 2.0?  
That might be aggressive, but then, 2.1 isn't officially released yet, so it's 
not unreasonable to make a larger change there.  What do you think?

I need to look at the code and see if there are any places where removal of 
--pgp2 (or --pgpX in general) will leave things in a messy state.  One place 
that comes to mind is in --gen-revoke.  GPG can import a bare revocation 
certificate.  No version of PGP can, so there is code to push out a minimal 
public key before the revocation certificate.  We'd need to add some sort of 
flag to indicate to include the minimal public key, and that's sort of 
reinventing --pgp again.

Maybe the answer is to remove the things to generate PGP 2 messages 
specifically, and leave the other stuff?  That feels a bit messy.

> What about --compress-keys and --compress-sigs?  These are GnuPG only
> features which predate OpenPGP and have been introduced only to allow
> that old accidental behaviour of GnuPG.

I'd remove them as well.  They're much easier to remove than --pgp2 as they 
only affect very specific (and few) places in the code.

David


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

Re: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 11, 2014, at 1:31 PM, Johan Wevers  wrote:

> On 11-08-2014 8:49, Robert J. Hansen wrote:
> 
>> On Enigmail, I recently had a frustrating
>> experience helping a user who was trying to use GnuPG to exchange
>> traffic with a PGP *2.6* user... a codebase which is about 20 years old now.
> 
> Fixing the packet order when --pgp2 or --rfc1991 are used would help a
> lot. And now I assume that pgp 2 will not pass away before the
> generation that was on the internet in the 1990's lies in the grave.

Rather than fixing RFC-1991 support, why not go in the other direction and make 
it clear that it isn't supported, and won't work?  I did a bunch of work to 
make --pgp2 work well and interoperate with PGP 2.x over a decade ago.  Even 
then it was intended as a stopgap measure until people finally stopped using 
PGP 2.x.  Over 10 years later, it's well past time to kill it.

David


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

Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications

[David Shaw]

On Jun 29, 2014, at 6:23 AM, Werner Koch  wrote:

> On Sat, 28 Jun 2014 15:22, ds...@jabberwocky.com said:
> 
>> I put a limited workaround in GnuPG at the time - that's why the
>> encryption key is always written to the card after the auth key (so
>> the encryption key would always be the "newest".  Of course, that
> 
> I have noch checked by I assume that this does not work anymore because
> at some point we started to create all keys with the same timestamp.

Ha, sure enough.  Looks like that was quite a few years ago.  I won't guess how 
many people are still using PGP 8, but if they're out there, they're likely not 
using it to interoperate with people using smartcards.  Given the lack of bug 
reports since this change way back in 2009, I'll go out on a limb and wager 
that the intersection between PGP 8 users, if they still exist, and smartcard 
users isn't exactly large.

David


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

Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]

[David Shaw]

On Jun 28, 2014, at 5:20 AM, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi
> 
> 
> On Friday 27 June 2014 at 11:35:00 PM, in
> , David Shaw
> wrote:
> 
> 
>> Incidentally, since subkeys have come up in this
>> thread, I seem to recall a few strange bugs with 8.x
>> (8.0? 8.1?) that make it difficult to use if the key
>> you are encrypting to has a signing subkey.  8.x didn't
>> always handle signing subkeys properly, so could end up
>> failing to encrypt (it wasn't 100% of the time - it
>> depended on which subkey was dated first).  If anyone
>> is curious, I'll dig out my notes for this.  I
>> submitted the bug to PGP, and I know it was fixed in a
>> later version.
> 
> 
> My recollection is that PGP 8.x would always try to encrypt to the
> newest subkey, and encryption would fail if the newest was a signing
> subkey. I had 8.0.3 and 8.1; if memory serves, both had this issue -
> signing subkeys were fairly new at the time.

Yes, that was it.  It got particularly strange when someone was using an RSA 
signing subkey or auth key (as they would do if they had a smartcard).  In that 
case, the PGP encryption would actually succeed (after all, RSA is capable of 
it, despite what the key flags instructed for use) but the GnuPG recipient 
would be unable to decrypt as from their perspective, that key was sign or auth 
only.

I put a limited workaround in GnuPG at the time - that's why the encryption key 
is always written to the card after the auth key (so the encryption key would 
always be the "newest".  Of course, that didn't handle existing keys.  The real 
fix was needed in PGP, and it was fixed.

David


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

Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]

[David Shaw]

On Jun 27, 2014, at 4:24 PM, John Clizbe  wrote:

> Kristian Fiskerstrand wrote:
>> On 06/27/2014 03:54 PM, shm...@riseup.net wrote:
>> 
>> 
>>> Robert J. Hansen:
 On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
> PGP 8 was released over a decade ago, that's hardly a modern 
> implementation:
 
 And yet, it still conforms (largely) to RFC4880.  Methinks
 you're objecting because it's a largely-conforming implementation
 that doesn't have good support for SHA256.  ;)
 
> In what ways is its support for SHA-256 limited?  I'm having a
> hard time finding documentation for it.
 
 If I recall correctly, it can understand SHA-256 but not
 generate SHA-256.  SHA-256 generation support was added late in
 the 8.x series, but earlier 8.x releases could understand it.
 
> 
> That is as I remember it, Rob. I don't recall if there was a difference
> between 8.0 and 8.1 with respect to SHA-256. JM3 probably would.

My notes say that PGP 8.1 can verify sigs made with SHA-256, but won't generate 
it.  I'm afraid I don't have a copy of 8.1 handy any longer to check.

Incidentally, since subkeys have come up in this thread, I seem to recall a few 
strange bugs with 8.x (8.0? 8.1?) that make it difficult to use if the key you 
are encrypting to has a signing subkey.  8.x didn't always handle signing 
subkeys properly, so could end up failing to encrypt (it wasn't 100% of the 
time - it depended on which subkey was dated first).  If anyone is curious, 
I'll dig out my notes for this.  I submitted the bug to PGP, and I know it was 
fixed in a later version.

David


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

Re: riseup.net OpenPGP Best Practices article

[David Shaw]

On Jun 27, 2014, at 6:45 AM, Viktar Siarheichyk  wrote:

> On 26.06.2014 23:28, Paul R. Ramer wrote:
>> On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor
>>  wrote:
>> 
>>> As for arguments about use on smartcards -- if you plan to get a 
>>> smartcard, and you have a primary key that is too large for it, you
>>> can always generate and publish new subkeys that will fit in your 
>>> smartcard. If that's the tradeoff that seems the most secure for
>>> you, that's fine, and the fact that you were using stronger keys in
>>> your non-smartcard implementation doesn't hurt you at all.
>>> Smartcards are not a good reason to object to larger keysizes for
>>> people who don't use smartcards.
>> 
>> Actually, it is for those of us who prefer smartcards.  I was once
>> newbie trying to use a smartcard. Repeated emphasis on having only a
>> 4k key can create the impression that a smartcard is not strong
>> enough, that it is weaker because it can only go up to 3072 bits
>> (depending on the card).
>> 
>> The reason for me to have a smartcard was to physically separate the
>> key from the computer.  Using a key that is too large for the
>> smartcard does not fit my purpose for having one.
> 
> I got an FSFE Fellowhip card and an OpenPGP SmartCard V2 from
> kernelconcepts.de (both were received early this year) and they both
> happily support 4096-bit keys. I do not know about YubiKey NEO "an
> experimental OpenPGP applet" though.

My understanding is that the YubiKey Neo applet supports up to 2048 bit RSA.  
Thus there are some keys that will work with the V2 SmartCard but not on the 
Neo.

I do admire the Neo form factor though.

David


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

Re: more bikeshedding about offline primary keys & auth subkeys

[David Shaw]

On Jun 25, 2014, at 1:53 PM, Jérôme Pinguet  wrote:

> Hello!
> 
> Thanks to Werner, I learned a new english word today: bikeshedding! :-)
> 
> This guide
> http://spin.atomicobject.com/2013/11/24/secure-gpg-keys-guide/ suggests
> creating a subkey with authentication capability. Most other sources
> stress the fact that the primary key and the offline computer must be
> used to authenticate other people's public keys.
> 
> I'm at a loss.
> 
> Can I use an RSA subkey with autentication capability (and cross
> certified) to authenticate other people's public keys, will it be
> recognized by sks key servers and used in the web of trust?
> Or do I have to use the primary key?

I think the confusion here is with the term "authenticate".  The ability to 
sign someone else's key is to "certify".  To "authenticate" is to prove your 
identity (for example, using an OpenPGP keys for ssh).  You can only certify 
with a primary key, and all primary keys are capable of certification (you 
literally can't turn the ability off).  Authentication is a different 
capability.

David


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

Re: Google releases beta OpenPGP code

[David Shaw]

On Jun 4, 2014, at 4:32 AM, Werner Koch  wrote:

> On Wed,  4 Jun 2014 04:43, ds...@jabberwocky.com said:
> 
>> I haven't looked at the fine details yet, but on the surface it seems
>> like they're aiming at Gmail (mainly, but not solely).
> 
> Interesting.  This is in contrast to a recent online article in the
> German c't magazine [1] where the author claims that Google would
> cannibalize their own business model if they offer end-to-end
> encryption.  Apple on the other hand can afford the luxury of encrypted
> chats because their revenue stream is not alone based on advertising.
> 
> Maybe Google now fears that users move away from Gmail and to mitigate
> that they provide end-to-end so that they still have access to their
> user's traffic pattern.

If we look at it cynically, I think this is a win-win for Google.  They get a 
lot of good press about "increasing user security" for nearly no cost to their 
business model.  This still requires manual steps to encrypt which pretty much 
rules it out for the overwhelming majority of users, and like you say, even for 
those relatively few users who start encrypting, Google still has access to 
traffic patterns.

I don't think they're being that cynical though.  The code is real, and 
presumably does what it is described to do.  It's not a complete solution 
(which for me would be automating it somehow), but it's a nice step.  And this 
is an 800 pound gorilla throwing some more weight behind encryption in general 
and OpenPGP in particular.  I'm quite pleased to see this.

David


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

Google releases beta OpenPGP code

[David Shaw]

Likely of interest to this group:

  
http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html

Briefly, it's a Chrome extension for doing OpenPGP.  It can import and use RSA 
keys generated elsewhere, but only has code to generate ECC keys internally.

I haven't looked at the fine details yet, but on the surface it seems like 
they're aiming at Gmail (mainly, but not solely).

David


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

Re: Why create offline main key without encryption capabilities

[David Shaw]

On Jun 2, 2014, at 11:30 AM, Suspekt  wrote:

> Am 02.06.2014 17:01, schrieb David Shaw:
> > One problem with multiple encryption subkeys is that the person
> > encrypting to you doesn't know which one to use. As things stand in
> > OpenPGP clients today, unless the person encrypting explicitly
> > specifies which subkey to use (and not all clients even offer a
> > choice at all) they'll *a* subkey, which may or may not be the one
> > you (or they) would have wanted.
> >
> > This problem doesn't exist in exactly the same way for multiple
> > signing subkeys since which key is used is under your control (the
> > signer), but there is a related problem in that you'd have a "low
> > security" signing key and a "high security" signing key. How does the
> > recipient know which is the intended one at any given time?  From the
> > recipient's perspective, it's just a good signature. There is no
> > "this is a good signature from my high security key" (there is a
> > "good signature from key X", but they don't know what additional
> > meaning you give to that key in particular).
> >
> > To be sure, OpenPGP does have enough hooks and capabilities to
> > implement what you're talking about (signature notations to say "this
> > is my high security key", for example) but it isn't done at this
> > time.
> >
> > David
> >
> Correct me if I'm wrong but doesn't GPG prefer the keys created last over 
> keys created earlier? So it would use the every-day keys by default and use 
> the high-security keys only if told specifically?

This is the GPG behavior, but this is just what GPG does.  It's not mandated by 
the OpenPGP standard, so other clients may do other things.  It would be 
equally as correct for a client to choose the key created earlier, or indeed to 
choose randomly.

There is some interesting discussion of key selection in 
http://tools.ietf.org/html/draft-brown-pgp-pfs-03.  They argue (as part of a 
PFS scheme) that the key most near its expiration time should be chosen.

David


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

Re: Why create offline main key without encryption capabilities

[David Shaw]

On Jun 1, 2014, at 3:25 PM, Suspekt  wrote:

> OK,lets take the forced-by-law-theory in account. Than the "best" way from a 
> pure security-standpoint in this regard would be:
> 0. OFFline-mainkey (certification of own keys and other people's keys)
> -> 1. OFFline-subkey (signing)
> -> 2. OFFline-subkey (encryption)
> -> 3. ONline-subkey (signing)
> -> 4. ONline-subkey (encryption)
> 
> You use keys 3&4 for everyday-usage. You use keys 1&2 for high-security 
> operations. If you get forced by authorities you would give them exactly the 
> keys they demand (lets say key 1 and key 4), revoke them and create new ones 
> with your offline-mainkey (key 0).
> Or they just force you to hand over your entire keyring but then this whole 
> thing would be half the fun

One problem with multiple encryption subkeys is that the person encrypting to 
you doesn't know which one to use. As things stand in OpenPGP clients today, 
unless the person encrypting explicitly specifies which subkey to use (and not 
all clients even offer a choice at all) they'll *a* subkey, which may or may 
not be the one you (or they) would have wanted.

This problem doesn't exist in exactly the same way for multiple signing subkeys 
since which key is used is under your control (the signer), but there is a 
related problem in that you'd have a "low security" signing key and a "high 
security" signing key. How does the recipient know which is the intended one at 
any given time?  From the recipient's perspective, it's just a good signature. 
There is no "this is a good signature from my high security key" (there is a 
"good signature from key X", but they don't know what additional meaning 
you give to that key in particular).

To be sure, OpenPGP does have enough hooks and capabilities to implement what 
you're talking about (signature notations to say "this is my high security 
key", for example) but it isn't done at this time.

David


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

Re: Why create offline main key without encryption capabilities

[David Shaw]

On Jun 1, 2014, at 6:54 AM, Suspekt  wrote:

> Hi there,
> I understand the concept of using a secure offline key and than creating one 
> or multiple subkeys to use in rather insecure environments like a 
> internet-connected laptop or a smartphone. Depending on which tutorial you 
> look at, the recommended capabilities of the offline key vary.
> Some use the key just for certification of own subkeys and keys of other 
> people.
> 
> Some recommend using it for certification of own subkeys, keys of other 
> people and signing of documents that are so important, that the 
> signing-subkey is not secure enough.
> 
> But I yet have to find someone recommending to use the offline mainkey also 
> for encryption/decryption of files, that are so important that subkey 
> encryption/decryption is not secure enough.
> 
> Is there a reason for that? Am I missing something?

One reason is that in some places there are legal issues around this.  You can 
be legally required to give up your encryption key to the authorities or suffer 
the consequences (arrest / jail / etc).  The idea is that if you have a 
different encryption and signing/certification key, you can easily give up the 
encryption (sub)key without compromising your (much more valuable) main key.  
At least that's the theory - I don't know offhand if this "I'll give you this 
key, but not that one" trick has been tested in practice, and if so, which 
legal jurisdiction it was tried in, and whether it worked or not.  (I'd be 
curious to find out, if anyone has any pointers).

For the sake of argument, let's say it worked, though: the authorities have 
your encryption key and can now decrypt as they like.  You promptly make a new 
encryption key using your (uncompromised) main key and continue on.  They can 
read your old mail, but not the new, and notably cannot make signatures as you, 
and cannot make new keys as you.

As a side note, when doing a key signing with someone, I send them a message 
and request they sign it to prove ownership of the key.  I require that this 
signature comes from the main key - that's the key I'm signing, so that's the 
key I need to prove ownership of.  The subkeys are not really relevant here.

David


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

Re: How are primary key binding signatures (0x19) handled by gpg?

[David Shaw]

On May 22, 2014, at 1:04 PM, martijn.list  wrote:

> According to RFC 4880
> 
> "For subkeys that can issue signatures, the subkey binding signature
> MUST contain an Embedded Signature subpacket with a primary key binding
> signature (0x19) issued by the subkey on the top-level key."
> 
> The sub key of the following key (key ID 0549B8A5640444E6) is valid for
> signing (RSA Encrypt or Sign) but it does not contain a primary key
> binding signature:
> 
> http://pgp.mit.edu/pks/lookup?search=0x0549B8A5640444E6&op=index
> 
> Enigmail tells me that the sub key is valid for signing. It might be
> that I misunderstand the requirement but it seems that in this case the
> key should not be used for signing since it lacks the primary key
> binding signature. I know that this requirement is relatively recent so
> it might be that for this key the current behaviour is for backward
> compatibility reasons. Is there some documentation on how GPG handles
> signing sub keys without a valid primary key binding signature?

When verifying a signature from a subkey without a 0x19 binding signature (aka 
"backsig"), you should get an error:

 WARNING: signing subkey XX is not cross-certified
 please see http://www.gnupg.org/faq/subkey-cross-certify.html for more 
information

and the signature verification will fail.

If you own the key in question, you can add a backsig to it via "gpg --edit-key 
0549B8A5640444E6" and then "cross-certify".

David


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

Re: Future inclusion of Threefish in Gnupg?

[David Shaw]

On May 14, 2014, at 9:35 AM, Sin Trenton  wrote:

> Hello everyone,
> 
> Just out of curiousity, are there any plans for including Threefish into 
> GnuPG?
> Or does it have to be incorprorated into the OpenPGP standard first and 
> *then* perhaps baked into GnuPG?

Yes.  GnuPG follows the OpenPGP standard, so any new algorithms would need to 
go through that process first.

David


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

Re: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases

[David Shaw]

On May 13, 2014, at 7:15 PM, Aaron Toponce  wrote:

> I don't know if this is a bug, or if I am doing something wrong, so I might as
> well ask here. I ran the following command from my terminal, and cannot
> retrieve the fingerprint from the file:
> 
>$ gpg --output 0xBB065B251FF4945B.gpg --export 0xBB065B251FF4945B
>$ gpg --with-colons --with-fingerprint 0xBB065B251FF4945B.gpg 
>pub:-:2048:1:BB065B251FF4945B:2008-07-27:::f:
>uid:Daniel T. Hagan :
>sub:-:2048:1:6BA86443C0C6CDA2:2008-07-27
>sub:-:2048:1:16C018D9B89B420A:2008-07-27
> 
> There should exist an "^fpr" line in the output. Compare to:
> 
>$ gpg --output 0x4713D527ECE16009.gpg --export 0x4713D527ECE16009
>$ gpg --with-colons --with-fingerprint 0x4713D527ECE16009.gpg 
>pub:-:1024:17:4713D527ECE16009:2005-06-06:::f:George Hacker (GLS) 
> :
>fpr:8BFD3F436366D9820E9EAB2F4713D527ECE16009:
>uid:George Hacker :
>uid:George Hacker :
>uat:1 2493:
>sub:-:1024:16:0D94CF6C0C8C2F1B:2005-06-06
> 
> Of the 453 keys in my public keyring, this happens on 8 of them (about 2%):
> 
>0x072DC7442B89BD45
>0x14774C7B9958256C
>0x4B2A4897D39DA0E3
>0x63E42BD8C58C753A
>0x677A7DE8CC9A6F67
>0x6FA1B04BB6724E04
>0x9710B89BCA57AD7C
>0xBB065B251FF4945B
> 
> Any ideas what is going on?

Looks like a bug.  Note that on each of the keys that didn't work there is a 
direct signature on the key.  This is not very common, and is usually used for 
a designated revoker (i.e. "I permit so-and-so to revoke my key for me").   I 
suspect there is a bug printing the fingerprints on a key from a key file 
(rather than from a keyring) for keys with a direct signature.

David


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

Re: improving validity calculation: external program

[David Shaw]

On May 5, 2014, at 1:05 AM, Hauke Laging  wrote:

> Hello,
> 
> from time to time when changes to GnuPG's behaviour (about validity and 
> trust) are suggested, Werner responds kind of: "No, that should be done 
> on top of GnuPG." This attitude makes sense but in the current situation 
> I would ask: How? How shall that be done on top of GnuPG without causing 
> a huge mess of adaption need in the higher layer applications?
> 
> Thus I would like to suggest that – similar to gpg-agent's option 
> "pinentry-program" – an option is added which disables gpg's internal 
> handling of --check-trustdb / --update-trustdb and has the configured 
> external program be called for that. This would more or less be a 
> modified version of --import-ownertrust.

Believe it or not, this almost exists.  Way back in 2003, I added the concept 
of an "external" trustdb.  The intent was exactly for what you mention: to 
allow people to make up and experiment with their own ideas in trust handling 
without having to have GPG support them all directly.

The trustdb in GPG is essentially a frozen image of what ownertrust you've set 
on which keys, and which users IDs are valid, and to what degree (partial, 
full, etc).  When you run --check-trustdb and/or --update-trustdb, you're 
rebuilding the trustdb image.

An external trustdb is just like any other trustdb, except that GPG follows it 
directly, and does no trust calculations of its own.  So GPG is capable of 
reading this special trustdb that can encode any behavior you like.  The catch 
is that I never had time to write a generic trustdb "compiler" where you could 
feed it the key/user ID/validity relationships you desire, and have it spit out 
the resulting trustdb.  A reasonably good programmer should be able to write 
one in short order though.  You just need to follow the format used in tdbio.c, 
and tag it as TM_EXTERNAL so GPG knows to treat it as special and refuse to run 
check-trustdb or update-trustdb on it.

Note that while you may choose to use a nonstandard notion of trust and/or 
validity, that of course only applies to you.  Just like the standard trust 
models, just because A sees B's key as valid, it doesn't necessarily imply that 
B sees A's key as valid.

David


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

Re: new keys vs. sub-keys vs. uids

[David Shaw]

On May 2, 2014, at 9:08 PM, gn...@tim.thechases.com wrote:

> So I guess I'm looking for
> 
> 1) something that doesn't leak identities across signatures
> 2) a single passphrase to manage the multiple identities
> 3) can be identified by the signing email address (Claws seems to
> make this easy for choosing the signing key)
> 
> Is there a way I'm missing to go about keeping these separate without
> the overhead of new keys for each persona?

Briefly, no.  The signature is issued from the key, not by a particular 
identity using that key.  There is an optional feature in OpenPGP to say "I 
meant that signature to come from *this* user ID", but that doesn't really 
solve your problem either - it doesn't hide the fact that there are other 
identities or what those identies are, but rather indicates the one (of 
several) that you're using at the moment.  In any event, GPG doesn't support 
that feature (neither does PGP).

If you have a key with multiple user IDs, anyone looking at that key can see 
all of those identities.  The standard method for doing what you are trying to 
do is to have two separate keys.

David


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

Re: Access to www.gnupg.org only via TLS

[David Shaw]

On Apr 30, 2014, at 3:23 PM, Doug Barton  wrote:

> ... your whole premise seems to be invalid as there is no clear evidence at 
> this time (that I'm aware of, and I've been paying attention) that any actual 
> secret keys have been compromised by Heartbleed. It was listed as a potential 
> risk when the vulnerability was first announced, but several groups have done 
> research on that specific point and have found that it would be sufficiently 
> difficult, if not actually impossible; to render this particular risk as 
> negligible at best.

There were questions early on whether grabbing secret keys was possible via 
Heartbleed or not.  Since then, it's been proven that it is definitely 
possible.  At least one company set up a server and invited people to try and 
steal the secret key via Heartbleed.  It took less than a day:

  http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge

Here's a program that automates the process.  Just run it and wait:

  http://blog.erratasec.com/2014/04/cloudflare-challenge-writeup.html

I can't speak to whether actual (meaning "not example keys put there for the 
purpose of stealing") secret keys have been compromised by Heartbleed, but it's 
definitely not impossible (or all that difficult now that someone has done the 
hard part - just start a script and walk away).

David


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

Re: Get expiration date by searching on keyservers

[David Shaw]

On Apr 29, 2014, at 6:40 PM, Koen  wrote:

> Hi,
> 
> I use '--keyserver  --search-keys  to get info on a number of
> keys. As far as I can tell, that doesn't return an expiration date (if
> that exists).

GPG's keyserver code is capable of displaying expiration date, if the keyserver 
provides it.  Not all do.

But - and this is important - like all key data (from expiration date, to 
revocation status, to the user IDs, etc), the info returned by a keyserver is 
only informational.  You cannot rely on it until you download the key and check 
it yourself.  The keyservers are simply storage, and do not verify the keys 
sent to them (and you shouldn't trust them even if they claimed to).

David


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

Re: GPG cannot import public key

[David Shaw]

On Apr 24, 2014, at 9:15 AM, helices  wrote:

> Thank you, for your response.
> 
> [1] 
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: Encryption Desktop 10.3.0 (Build 8741)

[..]

> -END PGP PUBLIC KEY BLOCK-

Interesting!  This definitely has a selfsig, but the key itself is very odd.  
It's an RSA sign-only key, which is deprecated in OpenPGP.  The subkey is 
similarly odd - a RSA encrypt-only key, also deprecated.  The header says it 
came from "Encryption Desktop", which is a Symantec product (well, it is now).  
I don't know why that key is using deprecated key types, but certainly 
something is odd there.

RFC-4880 (published back in 2007) says:

   RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
   generated, but may be interpreted.

Weirder, the selfsig says it's a RSA signature (not RSA_S), so you have the odd 
situation of a key (RSA_S) and its self-sig (RSA) being from different 
algorithms.

So, it's legal for GPG to not accept this key (using deprecated algorithms), 
though the error message you got seems misleading to me.

> [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is 
> successful:
> # gpg --import /tmp/imps.asc
> gpg: key 845F5188: public key "Concerto Support Key 
> " imported
> gpg: Total number processed: 1
> gpg:   imported: 1  (RSA: 1)

GPG 1.4.5 treats RSA_S and RSA_E as identical to RSA for existing keys, but 
does not allow generating them.  This is legal as per the spec (i.e. don't 
generate them, but it's optional to use them).

I'm afraid I don't have immediate access to the GPG 2.x code base to check, but 
I wonder if your problem is simply that 2.x doesn't accept RSA_S and RSA_E keys?

David


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

Re: GPG cannot import public key

[David Shaw]

On Apr 23, 2014, at 11:14 PM, David Shaw  wrote:

> On Apr 23, 2014, at 3:24 PM, helices  wrote:
> 
>> No matter how I try, I cannot encrypt a file using that public key, even 
>> using --edit-key to assign trust:
>> 
>> gpg: 845F5188: skipped: Unusable public key
>> 
>> gpg: /tmp/test.txt: encryption failed: Unusable public key
>> 
>> 
>> The owner of the public key insists that it is self-signed; but, our GPG 
>> cannot find the self-signature
> 
> It doesn't look like it's self-signed, but without looking at the key itself, 
> I couldn't say for sure.  Is it posted anywhere on the net?
> 
> In any event, you can override the check for encryption with the same flag 
> you used to override the check on import.  So:
> 
>  gpg -r 845F5188 --allow-non-selfsigned-uid -e 
> the-file-i-am-encrypting-etc.txt

I should add, though, that overriding these checks is something you should do 
with suitable verification of the key.  Don't override the check unless you 
know what you're doing, and have assured yourself that the key you are 
encrypting to is really owned by the person/group that you believe it is.  
Those checks are there for a reason.

David


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

Re: best practice for pgp mail service, revoking keys

[David Shaw]

On Apr 23, 2014, at 6:13 PM, t...@piratemail.se wrote:

> Greetings,
> 
> This is a tiny bit philosophical. Perhaps a little off-topic. I think this is 
> probably the best list to ask never-the-less.
> 
> So I've been working on this pgp base web based mail service.
> https://github.com/timprepscius/mv
> 
> Here is the problem I hope eventually to be confronted with:
> 
> 1. User registers name "dec...@piratemail.se," user auto-magically generates 
> a pgp pub/priv key. The pub key is registered on the pgp key servers.
> 2. User goes away. Account is closed.
> 3. User still has "dec...@piratemail.se" registered on the pgp key servers.
> 4. Another person wants to use "dec...@piratemail.se."  He would generate a 
> brand new pgp key with a later creation date, but still that old one seems 
> like a liability.
> 
> What should I do?
> 
> A few options I can see:
> 1. email addresses are used only once.
> 2. email addresses are used more than once, but with a warning, "there 
> already exists an unrevoked pgp key for this address."
> 3. user gives me a revocation certification when he generates his pgp key, I 
> can revoke accounts which close.
> 4. user generates pgp keys which expire after a year
> 5. ?

I haven't looked extensively at your design, so this isn't a suggestion as to 
what you should do, but just to mention a possibility you may have missed:

5. User appoints you (or a designated key) as their designated revoker.  This 
allows your key to issue a revocation on their key.  Pro: no need to store 
revocation certificates for all of your users, which could leak.  Con: the 
revocation only works if the person checking has both your key and their key.

It's similar in many ways to 3.

David


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

Re: GPG cannot import public key

[David Shaw]

On Apr 23, 2014, at 3:24 PM, helices  wrote:

> No matter how I try, I cannot encrypt a file using that public key, even 
> using --edit-key to assign trust:
> 
> gpg: 845F5188: skipped: Unusable public key
> 
> gpg: /tmp/test.txt: encryption failed: Unusable public key
> 
>  
> The owner of the public key insists that it is self-signed; but, our GPG 
> cannot find the self-signature

It doesn't look like it's self-signed, but without looking at the key itself, I 
couldn't say for sure.  Is it posted anywhere on the net?

In any event, you can override the check for encryption with the same flag you 
used to override the check on import.  So:

  gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt

David


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

Re: Removing old preferences from exported key

[David Shaw]

On Apr 8, 2014, at 1:48 AM, Johan Wevers  wrote:

> On 07-04-2014 15:16, David Shaw wrote:
> 
>> When you change preferences you add another selfsig for your
>> user ID that contains the new preferences.
> 
>> If you want to make the old preferences go away completely,
>> you can simply delete the old selfsig via delsig
> 
> Yers, that removes it completely from my keyring. That's not necessary
> and will be undone after the first sync with the keyservers anyway.
> 
> However, is there a way to remove it from the exported key only - to
> keep the size of the exported key as small as possible? The export
> options didn't do that as list-packets showed.

Sure:

  --export-options export-clean

David


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

Re: Removing old preferences from exported key

[David Shaw]

On Apr 7, 2014, at 2:06 AM, Johan Wevers  wrote:

> Hallo,
> 
> I changed the preferences for my gpg key to add the new Camelia ciphers
> and move IDEA more backward as I got problems with people with old pgp
> keys using old gnupg versions claiming they supported it but actually
> didn't support it.
> 
> However, when I export the key it now contains both preference
> signatures. I did export it with
> 
> export-options export-clean-sigs export-clean-uids
> 
> in gpg.conf.
> 
> How do I export it removing the first preference signature?

When you change preferences you add another selfsig for your user ID that 
contains the new preferences.  If you want to make the old preferences go away 
completely, you can simply delete the old selfsig via delsig (you only need one 
selfsig, and the newer one is already present).  However, this won't 
necessarily do what you want - since keyservers are strictly additive, even if 
you delete the old selfsig, when you upload to a keyserver, any keyserver that 
has seen the key with the old selfsig will put it back.  Similarly, if someone 
had your key with the old selfsig, sending them the new preference will cause 
them to have both.

Luckily in practice, this isn't a problem - most implementations will ignore 
the old selfsig/preference in favor of the newer one.

David


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

Re: Encrypted file-size approximation with multiple recipients

[David Shaw]

On Apr 1, 2014, at 9:01 PM, Tim Chase  wrote:

> I've been trying to find a good explanation on how something like
> 
>  gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt
> 
> works.  The best I've been able to find is this:
> 
> http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html
> 
> I'm mostly interested in the overhead, so I set up 4 distinct
> homedirs for testing.  It looks like each additional recipient adds
> about 271 bytes (though one of them only has an extra 270 bytes), and
> there's a per-file overhead of about 66 or 67 bytes.
> 
> So from my experimentation, the final file-size ends up being
> something like
> 
>  input_file_size + 67 + (271 * recipient_count)
> 
> but I'm not sure how much that might change based on conditions I'm
> not taking into consideration (all my test GPG users were just
> g...@example.com, g...@example.com, etc), all with 2048-bit keys.

This can change pretty significantly given different key lengths, different 
algorithms, and perhaps most significantly, how compressible the original 
document is (by default GPG compresses data before encryption).  An input file 
of text will compress very differently than an input file that's a jpeg (as 
jpegs are already compressed, and so do not benefit much from a second layer of 
compression).

> Is there a more formal formula that can be used to approximate the
> overhead of multi-recipient encryption?

Not really.  If you constrain the problem as you have (everyone gets 2048 bit 
keys, etc), and constrain the input to a particular type of data, you can get a 
better approximation, but as soon as you open the problem up, the file sizes 
vary.

David


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

Re: Use own key with symmetric encryption?

[David Shaw]

On Mar 31, 2014, at 2:18 PM, Barnet Wagman  wrote:

> In symmetric encryption (AES256), is it possible for me to supply my own key, 
> rather than entering a passphrase and having a key generated by pgp?

No.  Not without patching the source.

David


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

Re: GnuPG encryption with key file

[David Shaw]

On Mar 26, 2014, at 5:37 PM, -- --  wrote:

> Hi,
> is it possible to encrypt a file with a symmetric cipher (e.g., AES256) using 
> a key file (e.g., a binary file) instead of a password?

Not really, but you can sort of weakly approximate it via something like this:

   base64 -w0 binary-file-for-passphrase | gpg --passphase-fd 0 --symmetric 
file-to-encrypt

Limitations of the method are that it's not really using the binary file as a 
key, but rather as a passphrase (so it gets the usual hash treatment), and 
there is a size limit on how large the passphrase can be (it's in the thousands 
of characters, but there is a limit).  The reason for the base64 is that 
passphrase-fd stops reading after \n for obvious reasons, and text passphrases 
can't have \0 in them, so a naturally-occuring \n or \0 in the binary file will 
truncate your "passphrase".  Same reason for the -w0, which tells base64 not to 
add any \n of its own.

David


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

Re: OpenPGP smartcard and RSA 8192 bit

[David Shaw]

On Mar 23, 2014, at 8:37 AM, -- --  wrote:

> Hi!
> 
> Just for the sake of curiosity, is it possible to store a 8192 bit RSA key on 
> the OpenPGP smart card? Two keys ? Three keys?

No.  You can store three 4096-bit RSA keys.  Larger than that is not possible 
on the card (and not supported in GnuPG even not using a smartcard).

David


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

Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash

[David Shaw]

On Mar 17, 2014, at 10:39 AM, Daniel Kahn Gillmor  
wrote:

> On 03/15/2014 03:53 PM, Juha Heljoranta wrote:
> 
>> I am not able to get the gpg to verify a signature.
>> 
>> Any advice how to fix this?
>> Or could the key 9C973C92 be invalid/broken?
>> 
>> 
>> $ mkdir -m 700 newgnupg
>> $ echo foo > zinc-0.2.0.jar
>> $ wget 
>> http://repo1.maven.org/maven2/com/typesafe/zinc/zinc/0.2.0/zinc-0.2.0.jar.asc
> 
> This is a signature ostensibly made by a 2048-bit DSA key, made over an
> SHA-1 digest.  DSA keys larger than 1024-bits should generally make
> signatures over stronger digests than SHA-1.
> 
> See section 4.2 of FIPS-186-4
> http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf for similar
> guidance.
> 
> Perhaps the folks who publish zinc need to --enable-dsa2, or to remove
> any mistaken "digest-algo sha1" from their signing routines?  You could
> point them at this thread in the gnupg-users archives if you think it
> would be useful.

It doesn't matter if you specify --digest-algo sha1.  Regardless of the setting 
of enable-dsa2, it the key wants a 256-bit hash, gpg won't allow you to sign 
with SHA-1.  There is no way to generate that signature, at least in gpg.

David


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

Re: Can't check signature, DSA key 9C973C92 requires a 256 bit or larger hash

[David Shaw]

On Mar 15, 2014, at 3:53 PM, Juha Heljoranta  wrote:

> Hi,
> 
> I am not able to get the gpg to verify a signature.
> 
> Any advice how to fix this?
> Or could the key 9C973C92 be invalid/broken?

The key may be fine, but the signature is invalid.  DSA keys specify how many 
bits of hash are necessary to make a signature.  This key says it needs a 
256-bit hash:

> gpg: requesting key 9C973C92 from hkp server pgp.mit.edu
> gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
> gpg: armor header: Version: SKS 1.1.4
> gpg: armor header: Comment: Hostname: pgp.mit.edu
> :public key packet:
>version 4, algo 17, created 1330048372, expires 0
>pkey[0]: [2048 bits]
>pkey[1]: [256 bits]



But the signature is strange.  It claims to be SHA-1:

> :signature packet: algo 17, keyid 04918EA99C973C92
>version 4, created 1352169028, md5len 0, sigclass 0x00
>digest algo 2, begin of digest 6f 81

  ^

But is way too large:

>hashed subpkt 2 len 4 (sig created 2012-11-06)
>subpkt 16 len 8 (issuer key ID 04918EA99C973C92)
>data: [255 bits]

 ^^^

Basically, the signature failed verification because it's mangled somehow.  I'm 
not sure how they managed to create it, but it's broken.

David


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

Re: Multiple Subkey Pairs

[David Shaw]

On Mar 13, 2014, at 6:17 PM, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> NotDashEscaped: You need GnuPG to verify this message
> 
> Hi
> 
> 
> On Thursday 13 March 2014 at 2:31:06 PM, in
> , Hauke Laging wrote:
> 
> 
> 
>> gpg --recipient 0xD4BC64B8\!
> 
> I've never see it with a backslash before the exclamation mark.
> What does the backslash add?

Probably escaping the exclamation mark to prevent it from being interpreted by 
the shell.  In bash, at least, it's not necessary as a trailing ! mark doesn't 
get interpreted by the shell.  Doesn't hurt to escape it though.

David


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

Re: Encrypting File with passphrase

[David Shaw]

On Mar 12, 2014, at 9:07 AM, Kumar, Vikash X  
wrote:

> Hi Team,
>  
> Could you please help me to understand the following query.
>  
> We are using gpg encryption method for encryption and decryption in our 
> application. We have generated the keypairs on server A and public key is 
> imported on server B also a passphrase say “Strange” was provided while 
> generating the key.
>  
> Now I am trying to encrypt the file on server B using this public key, I am 
> able to do so without any matter I pass the passphrase or not.
>  
> So my ask is, if a key pair is generated with passphrase it won’t restrict 
> the encryption incase incorrect passphrase or no passphrase is passed? Also I 
> was able to encrypt the file on server B by providing any random passphrase, 
> but decryption is possible with correct passphrase only.

In short, yes (though you don't need to provide a passphrase at all to encrypt 
to a public key - the passphrase has no meaning there).  Encrypting to a public 
key does not use a passphrase at all.  Only decrypting with the private key 
uses a passphrase.

David


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

Re: GPG key trust after a signing party

[David Shaw]

On Feb 26, 2014, at 8:43 AM, Óscar Pereira  wrote:

> Hello all,
> 
> I've just stumbled across this question, on Security StackExchange,
> but it has no satisfactory answers, so I'd thought to relay it here.
> Basically, it asks whether after a GPG signing party, you still have
> to assign trust values to all the key (or rather the keys' owners)
> in order to have a meaning full web of trust. Finding myself asking
> the same question, I quote the question:
> 
> « I might be totally misunderstanding the concept of web-of-trust,
>  but imagine the following scenario: I generate my key, then go to
>  a key signing party, and after, I import all the keys which
>  fingerprint I have verified, and sign those. Now, this will make
>  all those keys fully valid, but the default trust for each key
>  will still be set to the default, i.e. "unknown". Which means that
>  if I now import a new key, even if this new key has enough (*)
>  signatures from those, it still won't be considered valid, because
>  none of those keys is trusted.

A (slightly) simplified way to think of it is:

  1) You sign someone's key to say "I assert that this key belongs to the 
person identified".
  2) You assign trust to someone's key to say "I believe this person is 
responsible enough to do number 1 well".

#1 is a public statement from you (your key) to the world.  #2 is a private 
note in your own GPG setup.

The two don't necessarily go together.  If you think someone makes terrible 
signatures (for example, doesn't check sufficiently before signing), then you 
may still sign their key (after all, you're not making a statement as to their 
reliability, just as to their identity), but you probably wouldn't want to 
assign trust to their key.  In other words, you believe their key belongs to 
them, but you don't "trust" them to make good signatures on other people's keys.

At a keysigning party, it's quite common to be able to sign someone's key (you 
check some ID, verify their email address works via a cookie, and so on), but 
yet have no idea if the person is worth trusting to sign someone else's key.  
After all, in many cases, you've never even met them before.

David

p.s. There are variations here like the trust signature that combines both 
identity and trust into a single statement, and the local signature which is 
like a regular signature but not a public statement, but in the context of a 
keysigning party, they're much less common.


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

Re: Size of main key...

[David Shaw]

On Feb 23, 2014, at 10:54 AM, Laurent Jumet  wrote:

> 
> Hello David !
> 
> David Shaw  wrote:
> 
>>>   With 1.4.16, I suppose there is no way to change the size of the main
>>> key (actual 1024), isn't it?
>>>   I'm limited to RIPEMD160.
> 
>> If you're limited to using RIPEMD160 for some reason (or SHA-1, also a
>> 160-bit hash), then you are limited to a 1024-bit DSA key.  You are not
>> limited to using DSA though: you can make a RSA main key of whatever size
>> you desire, as RSA key sizes are not tied to the size of the hash.
> 
>...yes but I mean: I've a DSA 1024 key KeyID: 0xCFAF704C
>Is there a way to upgrade to a 2048 key without changing main key KeyID: 
> 0xCFAF704C ?

No.  You can't add bits to a key, so the only way to do that is to make a new 
key, which would naturally give you a new key ID.  It is possible to generate 
many keys over and over until you randomly hit the key ID you want, but that 
could take a while.  It's not too bad to match the 32-bit (8-digit) key ID you 
see usually, but note that internally GnuPG uses 64 bits (16 digits) for most 
purposes, and no matter what you do, your fingerprint won't be the same in any 
case.

David


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

Re: Size of main key...

[David Shaw]

On Feb 23, 2014, at 2:33 AM, Laurent Jumet  wrote:

>With 1.4.16, I suppose there is no way to change the size of the main key 
> (actual 1024), isn't it?
>I'm limited to RIPEMD160.

If you're limited to using RIPEMD160 for some reason (or SHA-1, also a 160-bit 
hash), then you are limited to a 1024-bit DSA key.  You are not limited to 
using DSA though: you can make a RSA main key of whatever size you desire, as 
RSA key sizes are not tied to the size of the hash.

David


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

Re: Newbie problem

[David Shaw]

On Feb 21, 2014, at 7:06 PM, john s.  wrote:

> Having had no trouble generating a key pair, I am having some problems of
> understanding.
> 
> I am going around in circles trying to understand something i am sure is quite
> straightforward.
> 
> The command:
> 
>   gpg --edit-key UID takes me to a command prompt and suggests I check
> help. What do I do now? I wish to extend the the expiry date of my key which I
> initially set at one year

Enter "expire" and follow the prompts.  It will ask you for the new expiry 
date, and then ask for your passphrase to encode it onto the key.

David


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

Re: old pgp2.6x keys imported in gpg (compile pgp 2.6)

[David Shaw]

On Jan 28, 2014, at 9:37 AM, Uwe Brauer  wrote:

> Hello
> 
> I have a problem to import my secret key into a iOS app called iPGmail.
> 
> The problem is that of course the key is password protected and the app
> seem to have difficulties with the password. 
> 
> So I just deleted the password and then can import the secret key, but I
> don't like this possibility and so I deleted my key.
> 
> The cipher for the key protection is CAST5
> 
> However the key was originally generated with pgp 2.6.2 more than 10
> years ago (yes I know it is only 1024 bit long and should not be used
> anymore), but could it be that such a key has some incompatibilities
> with RFC 4880??

Yes and no.  PGP 2.6.2 keys (version 3 keys) are compatible with RFC-4880, but 
that does not necessarily mean that every implementation supports them.  
Version 3 key support is optional in the standard, so it is possible that the 
iPGmail app only supports OpenPGP (version 4) keys.

(Frankly, if I was writing a OpenPGP program today, I'd probably leave out 
version 3 support as well).

David


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

Re: pgp export private key with password

[David Shaw]

On Jan 27, 2014, at 3:26 PM, Uwe Brauer  wrote:

>>> "David" == David Shaw  writes:
> 
>> On Jan 27, 2014, at 3:02 PM, Uwe Brauer  wrote:
>>> Hello
>>> 
>>> I just tried out iPGmail a app for the iPhone which supports
>>> pgp. However I want to import my private key and here the trouble
>>> starts. For some reason iPGmail only supports private keys in armor
>>> format which are password protected.
>>> 
>>> But 
>>> gpg --export-secret-keys --passphrase hallo --armor > oub2.asc
>>> 
>>> Did not really add a passphrase, since I could import oub2.asc as a
>>> different user, without being asked the password.
> 
>> I'm not sure I understand what you're trying to do.
>> --export-secret-keys doesn't add or remove a passphrase.  If the key
>> has a passphrase, the exported one still does.  If the key has no
>> passphrase, neither does the exported one.
> 
> Right there is a misunderstanding. What you say is of course correct 
> so during exportation and importation no password is asked, however when
> I want to *use* the key then I must provide the password.
> 
> However it seems that the application expects for some reason another a
> password during the import process.

Interesting.  I wonder why it does that - perhaps it stores the key unencrypted 
internally?  What happens if you provide your regular key passphrase to the app 
on import?

David


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

Re: pgp export private key with password

[David Shaw]

On Jan 27, 2014, at 3:02 PM, Uwe Brauer  wrote:

> Hello
> 
> I just tried out iPGmail a app for the iPhone which supports
> pgp. However I want to import my private key and here the trouble
> starts. For some reason iPGmail only supports private keys in armor
> format which are password protected.
> 
> But 
> gpg --export-secret-keys --passphrase hallo --armor > oub2.asc
> 
> Did not really add a passphrase, since I could import oub2.asc as a
> different user, without being asked the password.

I'm not sure I understand what you're trying to do.  --export-secret-keys 
doesn't add or remove a passphrase.  If the key has a passphrase, the exported 
one still does.  If the key has no passphrase, neither does the exported one.

If your secret key has a passphrase, then "--armor --export-secret-keys x" 
generates an armored key file with a passphrase.

David


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

Re: Import "Raw" RSA Secret Key?

[David Shaw]

On Dec 19, 2013, at 7:10 PM, Eric Swanson  wrote:

> I'm trying to import a "raw" RSA secret key into GnuPG.
> 
> I have p, q, d and the creation timestamp, as well as anything else
> that can be computed from them (n, u, e, etc etc).
> 
> I've been implementing bits of RFC 4880 in an attempt to generate
> valid secret key files, but it looks like GnuPG won't import a key
> unless it has a valid self-signature, and that chunk of the
> specification is large and looks painful to implement.
> 
> So how can I best get my (p,q,d,timestamp,n,u,e) structure into a
> valid GPG key which can be used to sign, encrypt, etc messages?

If you can manage to make a RFC 4880 secret key packet, you should be able to 
combine it with a user ID packet (either generate one yourself - no crypto 
needed - or just copy one from another key), and then import the result with 
--allow-non-selfsigned-uid.  That should skip the need for a self-signature.  
Once you have it imported, you can self-sign it via GPG, using "--edit-key 
xx sign".

David


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

Re: encryption algorithm

[David Shaw]

On Dec 18, 2013, at 5:41 AM, Werner Koch  wrote:

> On Wed, 18 Dec 2013 02:27, r...@sixdemonbag.org said:
> 
>> because you just shifted to arguing that "since GnuPG defaults to
>> AES-256, we need to use RSA-15000 by default otherwise the asymmetric
> 
> FWIW:
> 
>The rationale why we use the order AES256,192,128 is
>for compatibility reasons with PGP.  If gpg would
>define AES128 first, we would get the somewhat
>confusing situation:
> 
>  gpg -r pgpkey -r gpgkey  ---gives--> AES256
>  gpg -r gpgkey -r pgpkey  ---gives--> AES
> 
> PGP prefers AES256 for the simple reason that the marketing deptartment
> told the engineering that 256 sounds stronger than 128 (according to one
> of their lead developers).

Plus the related reason why Camellia is ordered the same way: because it would 
look strange to have AES 256,192,128 and then Camellia 128,192,256 !

Now that we have the preference list scoring, though, the above change is no 
longer necessary.  Instead of using the command line ordering, the score code 
handles it the same way regardless.  In the above example, AES (not AES256) 
would be chosen no matter what the order.  The rationale from back then was:

  /* Note the '<' here.  This means in case of a tie, we will
 favor the lower algorithm number.  We have a choice
 between the lower number (probably an older algorithm
 with more time in use), or the higher number (probably a
 newer algorithm with less time in use).  Older is
 probably safer here, even though the newer algorithms
 tend to be "stronger". */ 

I don't think it's worth changing the default ranking back at this point though.

David


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

Re: encryption algorithm

[David Shaw]

On Dec 17, 2013, at 12:41 PM, Matt D  wrote:

> How can I find whats on my list?

gpg --edit-key (thekey)
showpref

You can see your own, or anyone else's preference list that way.  Note that 
each user ID (or photo ID) has its own preference list.

David


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

Re: encryption algorithm

[David Shaw]

On Dec 17, 2013, at 1:53 PM, Matt D  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 12/17/2013 01:37 PM, David Shaw wrote:
>> On Dec 17, 2013, at 12:41 PM, Matt D  wrote:
>> 
>>> How can I find whats on my list?
>> 
>> gpg --edit-key (thekey) showpref
>> 
>> You can see your own, or anyone else's preference list that way.
>> Note that each user ID (or photo ID) has its own preference list.
>> 
>> David
>> 
>> 
> Thanks a bunch that was easy.  So mine is 2048 with AES-256.  So whats
> all the complaining about the defaults?

Search me.  The defaults are reasonable defaults.  Of course, not everyone 
agrees :)

David


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

Re: encryption algorithm

[David Shaw]

On Dec 17, 2013, at 11:31 AM, Matt D  wrote:

> On 12/17/2013 11:09 AM, Daniel Kahn Gillmor wrote:
>> Hi Matt--
>> 
>> On 12/17/2013 10:07 AM, Matt D wrote:
>>> Hi!  What encryption algorithm do we use in OpenPGP
>> 
>> OpenPGP has "algorithm agility", meaning that it's possible to use 
>> different encryption algorithms at different times in the same 
>> cryptographic framework.  encrypted OpenPGP messages are generally
>> also "hybrid" messages -- that is, the bulk of the message is
>> encrypted with a symmetric encryption algorithm (using a random
>> key), and that random key is encrypted to the recipient's public
>> key using an asymmetric algorithm.
> 
> Please excuse my ignorance but I have a question after looking at the
> list. It is my impression that I can choose an algorithm for my
> machine and whoever else I communicate with can choose another
> algorithm.  Is this correct?   Why would anyone choose AES-128 instead
> of something more secure, say AES-256?

The short answer is that not every OpenPGP program supports all algorithms.  
The only algorithm that MUST be present is Triple-DES.  Some algorithms are 
recommended, and some are totally optional, but 3DES is a hard requirement.  
It's possible that they simply don't have AES-256.

It's not quite accurate that you can choose an algorithm for your machine and 
whoever you communicate with can choose another.  Rather, algorithms in OpenPGP 
are ranked.  Each user (i.e. each key) has their own list, in order, of 
algorithms.  Triple-DES, the required algorithm, is always on this list (if you 
leave it off, GnuPG acts as if it's at the bottom of the list).  This list 
serves several purposes at the same time - first, it means that an algorithm 
that a particular user can't use (say their OpenPGP program doesn't support it) 
is guaranteed never to be used.  If it's not on the list somewhere, it won't be 
used.  Secondly, it allows users to indicate which algorithms they prefer.  If 
you prefer AES-256, above AES-128, then you list them in that order.  (In 
practice, GnuPG usually supports all of the algorithms, so the ordering 
functionality is more useful than the "don't use an algorithm I don't have" 
functionality.)

Different programs take this ordering into account in varying ways.  For GnuPG 
specifically, it tries to make as many people as happy as possible.  For 
example, if a message is being encrypted to three people, two of whom have 
AES-256 as their first choice, and one who has something else, the likely 
result will be that AES-256 is chosen.

So you pick your favorites, and people you communicate with pick their 
favorites, and the OpenPGP protocol handles the rest.

David


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

Re: Setting encryption algorithm for specific key

[David Shaw]

On Nov 20, 2013, at 5:33 PM, Johan Wevers  wrote:

> Hello,
> 
> I communicate with someone whose key tells me it supports IDEA, and
> since that's my prefered algorithm my gpg uses it to encrypt the
> message. However, het setup does not in fact support it (any more, it
> used to do in the past). Re-signing the key is no option, this is as
> computer-literate as she'll get.
> 
> I have now hardcoded cipher-algo in gpg.conf but is there an option I
> can select a specific cipher-algo for a particular key or recipient?

Not really.  This is one of the limitations of the preference algorithm in 
OpenPGP (well, a limitation of most algorithms): GIGO.  There is no easy 
workaround for a key falsely claiming support for a particular algorithm.

If you really can't get her to change her key, probably the best you can do is 
use personal-cipher-prefs to remove IDEA from the list of algorithm you'll 
consider.  That's a good bit better than hardcoding a particular algorithm, but 
is still global rather than per key or recipient.

There is a ugly hack you could use, which would be to create a dummy key, and 
set the preferences to not include IDEA.  Then make a group alias for her name 
that includes both her real key, and the dummy key.  Thus, when encrypting to 
the alias, you'll be encrypting to both her and the dummy.  Since the dummy 
doesn't allow IDEA, IDEA cannot be chosen overall.  That's per recipient, but 
pretty messy.

David


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

Re: Theoretical and maybe stupid questions about security

[David Shaw]

On Nov 20, 2013, at 1:21 PM, Josef G. Bauer  wrote:

> Hi,
> 
> I wonder how easily my private key(s) ('secgring.gpg') can be cracked
> once somebody get access to it.

Not at all easily, *if* you have a good passphrase on your private key(s).

> Q: Is the password stored as an hash and can it be cracked using Rainbow
> Tables? Is it maybe salted?

In OpenPGP, a S2K (string-to-key) algorithm is used, where the passphrase 
entered by the user is hashed multiple times (with added salt) to transform it 
into the key used to decrypt the secret key.

David


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

Re: How to add information about purpose/security of sub keys?

[David Shaw]

On Nov 13, 2013, at 6:08 PM, adrelanos  wrote:

> Hi!
> 
> I would like to partition my key like this:
> 
> - long term identity key (air gapped, master key) [a]
> -- short term e-mail encryption key (less secured sub key, only on mail
> machine) [b]
> -- short term e-mail signing key (less secured sub key, only on mail
> machine) [c]
> -- short term images/repository key (less secured sub key, only on
> software build machine) [d]
> -- long term encryption key (air gapped, sub key) [f]
> 
> In other words, I would use:
> 
> - [b] and [c] for convenience, communication which isn't that important
> - [c] to sign software / apt repository
> - [a] to sign important messages (key transition etc.)
> - [f] little convenience, for receiving important messages
> 
> What is the best way to make key [b] the default, so anyone writing an
> encrypted mail will use key [b] and not key [f] unless a conscious
> decision was made?

There isn't a standard way to do this - the encrypting client is free to pick 
either b or f, as it desires, when encrypting to your key.   That said, many 
(most?) clients will pick the most recent key, so if you generate b after f, 
you should get what you want, at least most of the time.

> What is the best way to communicate...?
> - if you want to send a mail, in most cases, use key [b],
> - unless it is really important, then use key [f]
> - most of my mails will be encrypted with key [c], unless it's
> important, then I use key [a]
> - software I sign will be signed with key [d], do not use software
> signed with key [c]
> 
> It would be best if this information was presented by default, such as
> when importing my key or at least when running --fingerprint. What is
> the best way to communicate that, sub packets (notations), UUID comments
> or something else?

The standard way to express how you intend to use your key is via a notation or 
a policy URL pointing to some document where you set out your desires.  It does 
not display when importing your key, but is present if anyone cares to look for 
it.  Do note that few people read these documents unless they have a specific 
reason to (you're in control of what you generate - you can't place 
requirements on how people process it).

> Are sub packets (notations) signed by the master key [a]?

Notations are a signature subpacket (i.e. live on a signature themselves), so 
if the signature was issued by the master key, then yes, they're signed by the 
master key.  If you're making a notation on a self-signature (like the one 
binding your user ID or a subkey), then this would of course be issued by the 
master key.

> Are UID comment signed by the master key [a]?

Yes.  All parts of the UID string are signed by the master key.

David


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

Re: (GnuPG) 1.4.2 - Signature Verification Issue

[David Shaw]

On Oct 24, 2013, at 4:47 PM, "VINEETA DESHMUKH (CRGL-THIRDPARTY.COM)" 
 wrote:

> Hello,
>  
> I am facing an issue with the Signature verification from one of our clients 
> – JP Morgan. We currently have FTP+encryption+signature of all the files 
> which they send to us. However, they recently have migrated their FTP servers 
> to connect through secure FTP with SSH keys. This is where we are facing 
> problems when it comes to signature verification to a few files which are 
> placed through their automated process. I am pasting successful and failed 
> logs for your reference.

The first thing to ask whenever people put FTP and signatures together is 
whether the files are transferred via ascii or binary mode in FTP, and the 
related question of whether the files you are transferring are in ascii armor 
or not.  Transferring non-armored files via ascii mode in FTP can cause various 
corruption problems.

David


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

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

[David Shaw]

On Oct 24, 2013, at 3:05 PM, Sylvain  wrote:

> Hi,
> 
> I saw a lot of activity in the Debian project about upgrading to a
> 4096 RSA key,
> e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg3.html
> 
> However GnuPG's default is 2048.
> 
> Is this zealotry on the Debian front, or something to update in gnupg?

Heh, you might dig through the mail archives from this list from around that 
time.  In short, some people will call it zealotry.  Some people will call it 
necessary.  Some people are in the middle.  Reasonable people can disagree 
about these things, and there isn't one right answer for everyone.

However, in regards to the GnuPG default, that isn't an oversight.

David


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

Re: trust your corporation for keyowner identification?

[David Shaw]

On Oct 16, 2013, at 8:04 AM, "Brian J. Murrell"  wrote:

> If you worked in a corporate environment, would you trust the HR
> department there to have verified the identity of employees well enough
> to leverage that into signing a GPG key?
> 
> Let's say such an environment had an messaging system where employees
> had to authenticate with their corporate IT credentials in order to use
> the system.  Would that, and the assertion by HR/IT that a message that
> I get from Bob really did come from the employee HR verified as Bob
> (i.e. when they hired him) be enough for you trust the key you get from
> Bob enough to sign it that it really is really Bob's?
> 
> I guess what I am describing is a virtual key signing party where the
> verification of IDs is being done by the corporation instead of the
> individuals.

It's an interesting question, but it would not be enough for me.  If you think 
about it, this is effectively the same as Alice signing Baker's key, and then 
Charlie signing Baker's key because Charlie knows Alice (and not necessarily 
Baker).  If I were Charlie, I would not be willing to sign Baker's key, even if 
I knew and trusted Alice, without verifying Baker myself.

A somewhat related case would be when the corporation itself has a corporate 
signing key and on HR/IT approval, signs employee keys.  (This sort of thing is 
one of the classic uses for trust signatures).  In that case, you can either 
trust the corporate signing key or not, as you like.

David


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

Re: better handling of importing local signatures

[David Shaw]

On Oct 15, 2013, at 7:30 PM, Hauke Laging  wrote:

> Hello,
> 
> I think it would be a good idea to change the handling of local signatures. I 
> suggest to import local signatures even without
>--import-options import-local-sigs
> if the local signature is by one of the secret keys in the local keyring. 
> That 
> would make the handling of offline mainkeys easier: It would allow the user 
> to 
> avoid putting "import-options import-local-sigs" in the config file (which he 
> is otherwise heavily tempted to do in order to avoid problems).

Have you tried doing this?  The code (at least in 1.4.x) already works this way.

David


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

Re: my gpg key does not conform to rfc4880?

[David Shaw]

On Oct 10, 2013, at 1:45 PM, "Brian J. Murrell"  wrote:

> I was told by a developer of a piece of software that my key does not
> conform to rfc4800.  He said:
> 
>  According to http://tools.ietf.org/html/rfc4880#section-5.2.2
>  signatures of version 3 don't have subpackets, which are only
>  available in version 4.
> 
>  Looks like your key from 1998 is not compliant to RFC4880.
> 
> Do I have any recourse other than to generate a new key?

Probably, but without seeing the key it is hard to be completely sure.  Most 
likely, you could just strip the poison signature from your key and keep using 
it.  If it's a self-signature, you'll have to make another one.  If it's a 
signature from someone else, you can either disregard it, or ask them to 
re-sign your key.

Can you say what the software that rejected your key is?  If you think about 
it, rejecting a key because of a bad signature could lead to an denial of 
service attack - just upload a signature that is noncompliant enough to cause 
the key to be rejected, but compliant enough to make it onto a keyserver.  Is 
your key with the bad signature on a keyserver?

David


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

Re: GPG Private Key Export Question

[David Shaw]

On Sep 27, 2013, at 9:58 AM, Paul Taukatch  wrote:

> Really appreciate the help and the quick response! 
> 
> I just wanted to clarify, where exactly is the public key information stored 
> within the exported secret key data? Is it part of the Secret key packet as 
> part of the "Encrypted stuff follows section" or is following that? I'm 
> currently trying to develop some software and would like to extract the 
> public key value along with the fingerprint/ID information from the exported 
> secret key packet. I'm assuming that when GPG imports such a secret key 
> packet it is able to extract the public key info and able to link it to the 
> corresponding public key (if one exists within the keyring already) or is 
> able to reconstruct and place the public key if it does not already exist. 

It's part of the secret key packet, immediately before the encrypted stuff.  So 
a secret key is effectively a public key, with a few more fields of secret 
stuff tacked on the end.

Your assumption is correct, for both.  When GPG imports a secret key, it 
creates a public key and imports it alongside the secret key.

David


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

Re: GPG Private Key Export Question

[David Shaw]

On Sep 26, 2013, at 12:54 PM, Paul Taukatch  wrote:

> I had a question regarding exporting a private key using GPG.
> 
> I generated a Key pair using GPG 1.4.13 and then used the export command to 
> export the private key into another file.
> 
> Based on the RFC 4880 documentation: 
>A Secret-Key packet contains all the information that is found in a 
>Public-Key packet, including the public-key material, but also 
>includes the secret-key material after all the public-key fields.
> 
> But when I --list-packets on the file it does not seem to contain any 
> information about the public key. So my question is, do GPG private key 
> packets contain the public key information as specified by the RFC 4880 
> documentation?

Yes.  This isn't an actual public key packet - just the contents of the public 
key packet at the end of the secret data, so it doesn't show up as a ":public 
key packet:" in --list-packets.

> Also, is there anyway to export a key pair using a single GPG command into a 
> single file?

Not exactly, but (at least using GPG) you get the same effect.  If you import a 
secret key and you don't have the public key, GPG will use the embedded public 
key data to recreate the public key, so effectively an exported secret key is 
like exporting a key pair.

> Also, I had a question regarding the Key Fingerprint/Key ID and its relation 
> to the public/private key pair. While viewing my keys using GPG it seems that 
> the private key has the same Key ID as the public key. 

Correct.

> Based on the RFC4880 specifications I know that a fingerprint is generated by 
> :
> 
> A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
>followed by the two-octet packet length, followed by the entire
>Public-Key packet starting with the version field. for the secre
> 
> My question then is, when I attempt to import my exported secret key, how is 
> the key fingerprint calculated for the secret key, is it based only  on the 
> "public key packet" portion or is it also based on the secret key 
> information? 

It's based only on the public key information.

David


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

Re: Magic numbers for keyring files?

[David Shaw]

On Sep 25, 2013, at 9:18 AM, "Robert J. Hansen"  wrote:

> I'm working on adding support for GnuPG keyrings to a file carver (a
> forensic tool that recovers data from damaged filesystems, or recovers
> things that have been deleted but not overwritten).  Detecting an
> ASCII-armored keyblock is pretty easy: look for the "BEGIN PGP PUBLIC"
> header.  Binary, though, is still an unsolved question.
> 
> Before I start diving into code to find out if the keyring has a
> specific binary header I can detect, I figured I'd ask on-list.  :)
> 
> Does anyone know of any magic numbers for GnuPG keyring files?

Do you mean OpenPGP keyrings (i.e. "transferable public/secret keys", a la 
RFC-4880)?  If so, it's statistical magic only.  There are binary headers you 
can look for that don't quite ensure it's a OpenPGP keyring, but can leave you 
fairly confident.

Take a look at the "file" magic database as a start.  It's not 100%, but should 
get you going.

http://www.darwinsys.com/file/

David


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

Re: lsign produces exportable signatures when used for self-sigs

[David Shaw]

On Sep 13, 2013, at 1:22 AM, Daniel Kahn Gillmor  wrote:

> GnuPG is currently not able to create a non-exportable self-sig.  If you
> try to do this, it gives an error:
> 
> WARNING: the signature will not be marked as non-exportable.

This is by design (hence the warning message), as an unsigned user ID is not 
really meaningful as anyone could add it against the will of the keyholder, and 
a locally signed user ID is effectively unsigned.

David


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

Re: GNUPG and Cast6

[David Shaw]

On Aug 29, 2013, at 2:01 PM, Csabi  wrote:

> Hi all,
> 
> Why does not support GNUPG the CAST6 (256 bit key) variant of the CAST 
> algorithm?
> It supports the CAST5 (128 bit key) variant and it is the default cipher.

There never was a really good reason to support it.  The OpenPGP working group 
added TWOFISH as a 256-bit cipher (and not incidentally a 128-bit blocksize), 
and later AES.  There is nothing specifically wrong with CAST6, but given that 
OpenPGP has both TWOFISH and AES, there isn't really a pressing reason to 
include CAST6 too.

David


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

Re: Serpent?

[David Shaw]

On Aug 22, 2013, at 10:15 AM, Daniel Kahn Gillmor  
wrote:

> On 08/22/2013 09:56 AM, Robert J. Hansen wrote:
>> GnuPG extends this with support for Camellia-128, Camellia-192 and
>> Camellia-256.  I don't know the reasoning for introducing Camellia, but
>> I'm sure there's a solid basis for it.
> 
> Camellia in OpenPGP is now a published part of the spec, complete with
> symmetric algorithm number assignments from the IANA:
> 
>  https://tools.ietf.org/html/rfc5581
> 
>> The best way to get GnuPG to support SERPENT is to convince the IETF
>> OpenPGP Working Group to add SERPENT to the symmetric cipher profiles.
> 
> And the best way to do get started on the path to standardization is to
> provide a patch for an existing implementation (probably using an
> algorithm number from the experimental range [0] that implements it, to
> demonstrate feasibility.
> 
> Using RFC 5581 as a template for the proposed draft would probably be
> the quickest path to getting it documented and agreed upon in an
> acceptable way.

If anyone wants the xml2rfc source for RFC-5581, just let me know.  You can 
make almost any "add this cipher algorithm to OpenPGP" draft with very little 
more than cut and paste on top of that.  Of course, that's just gives you a 
draft document.  There are quite a few more steps in producing a RFC.

David


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

Re: Serpent?

[David Shaw]

On Aug 22, 2013, at 9:56 AM, "Robert J. Hansen"  wrote:

> GnuPG extends this with support for Camellia-128, Camellia-192 and
> Camellia-256.  I don't know the reasoning for introducing Camellia, but
> I'm sure there's a solid basis for it.

I think it was implemented in GnuPG first, but it's not a GnuPG extension.

http://www.rfc-editor.org/rfc/rfc5581.txt

David


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

Re: Issue with --sign option

[David Shaw]

On Aug 18, 2013, at 11:45 AM, ashish tiwari  
wrote:

> echo test123|/usr/local/bin/gpg --no-tty --passphrase-fd 0 -o 
> /apploatr/.gnupg/ab.pgp --debug-level advanced --log-file a.log --sign 
> --encrypt -r nkumar /apploatr/.gnupg/test.txt
> 
> gpg: O j: ... this is a bug (getkey.c:2696:lookup)
> secmem usage: 1632/1632 bytes in 3/3 blocks of pool 1632/32768
> ksh: 41382116 IOT/Abort trap

I think this is a corrupt secret keyring.  Regardless of the issue of "-sign" 
vs "--sign", an abort like that shouldn't happen.  I don't know what version of 
GnuPG this is, but the only BUG() call in the lookup function is one that fires 
if the packet it sees in the secret keyring is not a secret key.

David


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

Re: understanding GnuPG "--clearsign" option

[David Shaw]

On Aug 12, 2013, at 4:40 AM, Martin T  wrote:

> Hi,
> 
> one can sign the message with "--clearsign" option which adds ASCII
> armored(Radix-64 encoding) "PGP signature" at the end of the text.
> This "PGP signature" contains the UID of the signer, timestamp and key
> ID. However, two questions:
> 
> 1) Where is the UID of the signer, timestamp of the signature and
> signer key-ID stored? If I execute "gpg2 --verify file.asc", then I'm
> able to see the UID of the signer, timestamp and signer key-ID, but if
> I decode the Radix-64/base64 data back to binary(base64 -d) and use
> "hexdump -C" to analyze this data, I do not see the UID, timestamp or
> signer key-ID.

The timestamp and the signer's key ID are both present in the binary blob.  The 
signer's user ID is not, as GPG is using the signer's key ID to look up the 
signer's key and shows the user ID from there.

> 2) What exactly is this "PGP signature"? Is it a SHA1 hash of the
> message which is encrypted with my private key and then ASCII armored?

It's not always SHA-1, and there are other things included in the hash, but at 
a very high level, this is basically accurate.  The exact construction of a 
signature and how the input is calculated is given in RFC-4880, the OpenPGP 
specification.

David


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

Re: Question about notations and domains

[David Shaw]

On Aug 9, 2013, at 2:43 AM, Khelben Blackstaff  
wrote:

> I only replied to Mr. Shaw and not to the list so i send this again.
> 
> On Fri, 9 Aug 2013 00:09:29 -0400
> David Shaw  wrote:
> 
>> There are two namespaces here.  If a tag is defined by the IETF
>> process, then there is no @domain at all.  The @domain tags are used
>> when regular users want to define a tag.
>> 
>> Anyway, so it's true that you can use the @domain notation to
>> differentiate between a tag you use and the same tag used by someone
>> else, but this shouldn't be interpreted as that you should always use
>> the local domain.  The domain is set by whoever defines the tag.
>> 
>> In this case, the preferred-email-encoding tag was defined by the
>> pgp.com people.  Thus preferred-email-encod...@pgp.com is the proper
>> string to use.
>> 
>> David
>> 
> 
> Yes i understood the two namespaces but i had not understood that the
> proper domain is the one of the person who defines the tag. I had
> the impression that everyone should use his own domain.
> 
> So, in the case of the issuer-fpr notation, which if i am not wrong
> was introduced by Mr. Gillmor, the proper notation is
> issuer-...@notations.openpgp.fifthhorseman.net and not
> issuer-...@my.domain.tld ?

Sort of.  Basically, if you want the semantics of the tag as defined by a 
particular person, you use their tag.  If you want different semantics, you can 
use your own tag (possibly using the same tag name, but @ your own domain).  In 
the case of the issuer-fpr tag specifically, I'd use dkg's tag.  It's 
straightforward and well defined.

David


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

Re: Question about notations and domains

[David Shaw]

On Aug 8, 2013, at 5:17 PM, Khelben Blackstaff  
wrote:

> Greetings.
> 
> I am sorry if this is already answered but i could not find anything
> relevant in the archive.
> 
> Quick introduction: I got a new smart card and reader so i thought to
> create a temporary test key and document on my blog all the steps i
> did over the years. In the next post i want to describe the policy urls
> and notations i use.
> 
> If i have understood the standard correctly, notations should have
> the form t...@my.domain.tld using a domain i own because my meaning
> for "tag" might be different than someone else's. Is this correct ?

There are two namespaces here.  If a tag is defined by the IETF process, then 
there is no @domain at all.  The @domain tags are used when regular users want 
to define a tag.

Anyway, so it's true that you can use the @domain notation to differentiate 
between a tag you use and the same tag used by someone else, but this shouldn't 
be interpreted as that you should always use the local domain.  The domain is 
set by whoever defines the tag.

For example:

> Another question i have is about the pgpmime notation. I see many
> people using it verbatim "preferred-email-encod...@pgp.com=pgpmime".
> Shouldn't @pgp.com be changed to the domain of each user ?

In this case, the preferred-email-encoding tag was defined by the pgp.com 
people.  Thus preferred-email-encod...@pgp.com is the proper string to use.

David


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

Re: Identifying your private key by the public KeyID

[David Shaw]

On Aug 6, 2013, at 9:22 AM, Kenneth Jones  wrote:

> I'm referring to the information you see for example in the prompt to
> enter your private key when you have received an encrypted message in
> Thunderbird/Enigmail. The window "pinetry" prompts "Please enter the
> pass...2048-bit RSA key, ID DEADBEEF, created ... (main key ID
> ABCD0123)." Notice there are two key ID mentioned in the window, one
> called Main, which is also the public Key ID, (the one I expected, the
> one I remember) and the other for the secret key (which I have Never
> Paid any attention to).

Ah, that clarifies it.  Yes, as a few people have suggested, that's the subkey 
ID.  It's not inherently public or secret, but just another key attached to 
your primary key.  In OpenPGP, "your key" refers to a primary key, plus some 
number of subkeys (occasionally zero, but that's fairly rare).  The primary key 
is the one that the user IDs (email addresses, etc) are attached to, and the 
one that gathers signatures from other people if you get your key signed.

The subkey(s) are keys attached to the primary key, that can be used for 
encryption or signing.  The idea is that since it is difficult to change your 
primary key (you'd need to get it re-signed, and re-print your business cards, 
and the like) you should be able to change the subkey quickly and easily.  A 
common methodology (and in fact the default for many programs) is to use the 
primary key for signing, and a subkey for encryption.  There are interesting 
variations that can be used with this basic design: some people leave their 
primary key offline completely, only taking it out to make new subkeys.  Some 
people use different passphrases on different subkeys.

To answer your original question, though, traditionally the key-as-a-whole is 
referred to by its primary key ID and fingerprint.  The subkeys are effectively 
along for the ride. Some programs make a point of telling you which subkey is 
in use at a particular time.  Some do not.

David


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

Re: Identifying your private key by the public KeyID

[David Shaw]

On Aug 6, 2013, at 6:38 AM, Kenneth Jones  wrote:

> 
> Good day, and hello to the autoresponder (%]##{}#%^!!!) (just my opinion, 
> mind you).
> I've been toying with PGP GPG GnuPG and whatever on and off since mid 1995, 
> but recently have become interested again as the political situation in the 
> US seems to warrant it. (Warrant? We don't need no stinking warrants...) 
> anyway...
> 
> I have a question about procedure...nomenclature, actually.  Is it normal to 
> refer to the private key by its own keyID, or by the KeyID of the mating 
> public key? The public fingerprint is the one known by others (natch) and 
> it's the identification I associate with the key pair. Is there any time when 
> it is appropriate to refer to my private key by its own KeyID? I understand 
> that each of the two eight-character sequences is unique, and so the private 
> key is in fact not accurately identified by using the public key's ID, but is 
> it common to do so? Seems to me it would be less confusing (for me, any way) 
> to be prompted with the Main KeyID than with that of the private key.

The public and private keys, by design, have the same fingerprints and key IDs. 
 I'm not quite sure what you're referring to here.  Is it possible you're 
looking at the primary key and subkey?  Subkeys do have their own fingerprint 
and key ID, but that doesn't have anything to do with whether it is public or 
private - the subkey on a public key is public, and the subkey on a private key 
is private.

David


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

Re: Is it possible to sign a key again after revoking a signature?

[David Shaw]

On Aug 2, 2013, at 1:17 AM, Philip Jägenstedt  wrote:

> Hi all,
> 
> I'm new to GnuPG and have probably been a little too ambitious for my
> own good. I originally signed key AB4DFBA4 at level 3 after a meetup,
> but was later paranoid that I was too lax and wanted to resign it at
> level 2, but did the resigning (by deleting the first signature locally)
> and revoking in the wrong order, and left my signature simply revoked.
> 
> After some tinkering I arrived at
>  and now want to sign the
> key again at level 3, but want to make sure I don't make a mess of it
> again. The problem:
> 
> When I try to sign the key using gpg --edit-key, I'm told that (twice)
> that the key "was already signed by key 9DC6C210" and that there's
> "Nothing to sign with key 9DC6C210."
> 
> The first time I bypassed this didn't turn out great, so can someone
> confirm to me that my (3) existing signatures locally, signing again and
> then syncing with the keyserver will leave this is in a state where my
> signature will be considered valid, in spite of an earlier revoke on the
> same key?

Yes.  So long as the date on the most recent signature is after the date of the 
revocation, the signature will take effect.

Leaving aside a bunch of more complex cases like non-revocable signatures, and 
signatures with expired expiration dates for now, in the simple case, the 
algorithm used for deciding if a signature is valid is to find the latest 
signature from a given key.  If that signature is a revocation, then it's 
considered revoked.  If the latest signature isn't a revocation, that signature 
takes effect.

An easy way to see what GnuPG considers a valid signature is to run "clean" on 
the key from the --edit-key menu.  GnuPG will strip off everything that it 
isn't using for trust calculations (so, revoked signatures are removed, runs of 
multiple signatures are collapsed down to the most recent, and so on).

David


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

Re: How to detect fingerprint and type of the key from pubring.gpg(public keyring file)?

[David Shaw]

On Aug 2, 2013, at 3:56 AM, Martin T  wrote:

> Hi,
> 
> thanks for the reply!
> 
>>> I think "method" in the example above is just indicating that this is a PGP 
>>> key.
> 
> Exactly. However, how does RIPE server-side software detect that it's
> a PGP key? Is this information(besides other information like key
> creation date and UID) written into pubring.gpg file during the
> creation of the public key?

Not directly.  There isn't some special tag that says "this is a PGP key" that 
lets you tell it apart from (say) some new image format that just happens to 
have a similar packet structure.  If you think about it, that's not possible 
since some other file format might accidentally trip the detector since there 
is no global registry of tags.

Many people use heuristics, based on the format in the spec.  (For example, the 
'file' program does this).  Or the ultimate heuristic: if it looks like a PGP 
key, can you parse it and import it?

>>> No.  The fingerprint is based on the key material only.  You can add/change 
>>> UIDs without the fingerprint changing.
> 
> Indeed. I revoked my current UID and changed it to another one and
> both public and private key fingerprints remained the same. So the key
> fingerprint is a hashed key material? Is it a SHA-1, MD5 or some other
> type of hash?

SHA-1.  The exact bytes that get fed into the hash are given in RFC-4880, but 
basically it's the public key material with a few bytes of structure around it.

David


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

Re: How to detect fingerprint and type of the key from pubring.gpg(public keyring file)?

[David Shaw]

On Aug 1, 2013, at 6:58 PM, Martin T  wrote:

> Hi,
> 
> RIPE(RIR in European region) database allows one to upload ASCII armored PGP 
> public keys: http://www.ripe.net/data-tools/support/security/pgp Server-side 
> software is able to generate some "key-cert" object attributes automatically. 
> For example "method", "owner" and "fingerpr":
> 
> noc@T42 ~ $ whois -h whois.ripe.net -t key-cert | grep gene
> method: [generated]  [single] [ ]
> owner:  [generated]  [multiple]   [ ]
> fingerpr:   [generated]  [single] [inverse key]
> noc@T42 ~ $ 
> 
> 
> Example "key-cert" object provided by RIPE:
> 
> key-cert: PGPKEY-4B8AE00D
> method:   PGP
> owner:Joe User 
> fingerpr: 9D 82 4B B8 38 56 AE 12  BD 88 73 F7 EF D3 7A 92
> certif:   ---BEGIN PGP PUBLIC KEY BLOCK---
> certif:   Version: 2.6.3ia
> certif:
> certif:   mQA9AzZizeQAAAEBgJsq2YfoInVOWlLxalmR14GlUzEd0WgrUH9iXjZ
> certif:   a/uqWiLnvN59S4rgDQAFEbQeSm9lIFRoZSBVc2VyIDxqb2VAZXhhbXB
> certif:   iQBFAwUQNmLN5ee83n1LiuANAQFOFQGAmowlUYtF+xnWBdMNDKBiOSy
> certif:   YvpKr05Aycn8Rb55E1onZL5KhNMYU/gd
> certif:   =nfno
> certif:   ---END PGP PUBLIC KEY BLOCK---
> mnt-by:   EXAMPLE-MNT
> changed:  j...@example.net 19981117
> source:   TEST
> 
> 
> How are those fields automatically detected/generated? "Owner"(UID in gpg 
> terminology) is written to public key- one can verify this with analyzing the 
> public key with hex editor. However:
> 
> 1) is "method" also built into public key? At least "hexdump -C pubring.gpg | 
> grep -i pgp" does not indicate this.. Or has "PGP" some sort of special 
> fingerprint which is understood by server-side software? Last but not least, 
> are there any other types besides "PGP"? I guess it is as pgpdump is even 
> able to dump the timestamp when the key itself was generated.

I think "method" in the example above is just indicating that this is a PGP 
key.  That is, there may be other types than PGP that RIPE supports, but you'd 
have to ask them about that.


> 2) is fingerprint automatically hashed based on the UID?

No.  The fingerprint is based on the key material only.  You can add/change 
UIDs without the fingerprint changing.

David


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

Re: cleartext signature: digest determination

[David Shaw]

On Jun 19, 2013, at 8:19 AM, Hauke Laging  wrote:

> Hello,
> 
> in RfC4880 I read this:
> 
> https://tools.ietf.org/html/rfc4880#section-7
> 
> «If the "Hash" Armor Header is given, the specified message digest
> algorithm(s) are used for the signature.  If there are no such headers, MD5 
> is 
> used.»
> 
> That doesn't make sense to me. I checked a cleartext signature with 
> gpg --list-packets and got this:
> 
> :signature packet: algo 1, keyid 4CB66C1B33FB59FC
>version 4, created 1364174035, md5len 0, sigclass 0x01
>digest algo 2, begin of digest a1 0d
>hashed subpkt 2 len 4 (sig created 2013-03-25)
>subpkt 16 len 8 (issuer key ID 4CB66C1B33FB59FC)
>data: [4093 bits]
> 
> This looks like a normal signature packet to me, and it does contain the used 
> digest algo. So why should it be necessary to write the used digest into the 
> cleartext part? Is that a compatibility issue with older OpenPGP versions? 
> Usually that is mentioned but not in the text I quoted.

It's an ordering issue.  Cleartext signatures are designed to be able to be 
read in a single pass - thus the need for the Hash header at the beginning of 
the document, so the receiving program doesn't have to read to the end, find 
out what hash is in use, then jump back to the beginning to actually hash the 
document.

David


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

Re: Confusion with signature digest type.

[David Shaw]

On Apr 26, 2013, at 12:18 PM, Mason Loring Bliss  wrote:

> On Thu, Apr 25, 2013 at 11:47:49PM -0400, Robert J. Hansen wrote:
> 
>> A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for
>> self-signatures is making sure to turn off the coffeepot.
> 
> While I agree with what you're saying, the big difference between this
> situation and your example is that it's trivially easy for me to say "use
> this digest method instead of this other one" and then forget about it. The
> coffee pot will take care of itself. The question becomes invisible to me as
> soon as I've set the default, and if the effort is so low to do it, I don't
> see any real reason *not* to do it. Security is about nudging up the bar.
> 
> Now, that said, I still don't understand why I was seemingly unable to change
> the digest algorithm I'm using for my old key. I'd be grateful if someone
> could enlighten me on that point, as I really want to grasp what was
> happening.

The answer to your question from your original mail is that you're using the 
"check if SHA-1 is in my preferences" test to instead of the "check if my 
selfsig is SHA-1" test.  The proper test for checking your selfsig from the 
document you were referencing is:

  gpg --export-options export-minimal --export  | gpg --list-packets 
|grep -A 2 signature|grep 'digest algo 2,'

David


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

Re: Privacy concerns

[David Shaw]

On Apr 17, 2013, at 11:12 PM, mirimir  wrote:

> On 04/17/2013 06:45 PM, NdK wrote:
> 
>> Il 17/04/2013 18:22, Doug Barton ha scritto:
>> 
>>> It's very safe to assume that e-mail address harvesting from the key
>>> servers is not anything to worry about.
>> At least for now.
>> But spam is just one of the possible issues...
>> 
>> Anyway I can see that the easiest and more versatile solution is to have
>> different identities for different communities (one for work, one for
>> personal use, one for hacking communities, ...). Eventually all
>> cross-signed.
> 
> Why would one cross-sign keys for identities used in different
> communities? That would link them, which seems counterproductive.

I think this could go either way, depending on the communities and identities 
(and people) involved.  For me, if I made a work key, I'd probably cross sign 
(or at least sign my work key using my personal key) as it would give a better 
path to the work key in the web of trust.  At the same time, though, if I made 
a key for a particular community where I wasn't directly known as "David Shaw", 
I'd probably not cross sign for the reason you imply - I wouldn't want the two 
identities linked.

David


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

Re: IDEA License

[David Shaw]

On Mar 25, 2013, at 8:46 AM, Jan Chaloupecky  wrote:

> Hi,
> is the IDEA algorithm licensed? Under which conditions am I allowed to use 
> the idea extension in a commercial product?

It was a patented algorithm which required a license.  The patent has since 
expired (and in fact it was difficult to even purchase a license for the past 
few years anyway), so there is no license required.

That said, IDEA is somewhat old technology at this point, and it has mostly 
been supplanted by newer algorithms like AES.  If you have don't have a need 
for IDEA specifically, you might want to look more widely.

David


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

Re: default keyring file formats

[David Shaw]

On Feb 19, 2013, at 9:27 PM, John A. Wallace  wrote:

> A lot of the documentation I see online includes references to files with 
> names like “foo.pub” or “foo.sec” as if these were public key rings and 
> secret key rings. However, I am accustomed to seeing keyrings like 
> “pubring.gpg” and “secring.gpg”. Were the former of these used as keyring 
> files in the past, but nowadays the latter format are used?

Keyrings of that type are just files with multiple keys concatenated together.  
The format is effectively the same no matter what the filename is.

I've often seen foo.pub / foo.sec as a single key (while the pubring.gpg, 
pubring.pgp, or pubring.pkr) is the keyring, but that's just convention.

David


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

Re: how to use invald e-mail?

[David Shaw]

On Feb 12, 2013, at 11:20 AM, refresh...@tormail.org wrote:

> When key is created gpg asks for e-mail address and it must be in proper
> format email@domain.
> 
> I saw keys without valid email already.
> 
> How to do it?

gpg --allow-freeform-uid --gen-key

   --allow-freeform-uid
  Disable all checks on the form of the user ID while generating a
  new one. This option should only be used in very  special  envi‐
  ronments  as  it does not ensure the de-facto standard format of
  user IDs.

David


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