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=index=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 r...@sixdemonbag.org 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 karda...@gmail.com 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 s.mur...@mykolab.com 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 3:10 AM, Werner Koch w...@gnupg.org 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: Vanity Keys

[David Shaw]

On Jan 13, 2015, at 2:53 PM, NdK ndk.cla...@gmail.com 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: DSA key sizes

[David Shaw]

On Nov 10, 2014, at 7:00 AM, Nicholas Cole nicholas.c...@gmail.com 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: DSA key sizes

[David Shaw]

On Nov 10, 2014, at 8:56 AM, Robert J. Hansen r...@sixdemonbag.org 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: 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
 mid:5418b3b1.4010...@dougbarton.us, 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 14, 2014, at 9:05 PM, Hauke Laging mailinglis...@hauke-laging.de 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: encrypting to expired certificates

[David Shaw]

On Sep 15, 2014, at 3:06 PM, Hauke Laging mailinglis...@hauke-laging.de 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: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 14, 2014, at 1:20 AM, Doug Barton do...@dougbarton.us 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 w...@gnupg.org 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 14, 2014, at 5:46 AM, Peter Lebbing pe...@digitalbrains.com 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: 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: what is correct for users' Preferred keyserver ?

[David Shaw]

On Aug 14, 2014, at 1:08 AM, Doug Barton do...@dougbarton.us 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: HP-UX and GnuPG

[David Shaw]

On Aug 13, 2014, at 4:20 PM, Bill HT htbi...@gmail.com 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: [openpgp] SHA-2 support should be mandatory – change defaults

[David Shaw]

On Aug 12, 2014, at 3:33 AM, Werner Koch w...@gnupg.org 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 joh...@vulcan.xs4all.nl 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 w...@gnupg.org 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
 mid:a2f8dba9-1da7-47a6-bc79-cfaea3b02...@jabberwocky.com, 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: riseup.net OpenPGP Best Practices article

[David Shaw]

On Jun 27, 2014, at 6:45 AM, Viktar Siarheichyk v...@eq.by wrote:

 On 26.06.2014 23:28, Paul R. Ramer wrote:
 On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor
 d...@fifthhorseman.net 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: 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 j...@enigmail.net 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: more bikeshedding about offline primary keys auth subkeys

[David Shaw]

On Jun 25, 2014, at 1:53 PM, Jérôme Pinguet jer...@jerome.cc 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 w...@gnupg.org 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 1, 2014, at 3:25 PM, Suspekt susp...@gmx.de 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 34 for everyday-usage. You use keys 12 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 2, 2014, at 11:30 AM, Suspekt susp...@gmx.de 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 6:54 AM, Suspekt susp...@gmx.de 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: Future inclusion of Threefish in Gnupg?

[David Shaw]

On May 14, 2014, at 9:35 AM, Sin Trenton sin.tren...@riseup.net 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 aaron.topo...@gmail.com 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 dan...@kickidle.com:
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) 
 ghac...@redhat.com:
fpr:8BFD3F436366D9820E9EAB2F4713D527ECE16009:
uid:George Hacker geor...@axian.com:
uid:George Hacker ghac...@axian.com:
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 mailinglis...@hauke-laging.de 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: Get expiration date by searching on keyservers

[David Shaw]

On Apr 29, 2014, at 6:40 PM, Koen koen.vani...@cudeso.be wrote:

 Hi,
 
 I use '--keyserver srv --search-keys key' 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: Access to www.gnupg.org only via TLS

[David Shaw]

On Apr 30, 2014, at 3:23 PM, Doug Barton do...@dougbarton.us 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: GPG cannot import public key

[David Shaw]

On Apr 23, 2014, at 3:24 PM, helices g...@mdsresource.net 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: 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 11:14 PM, David Shaw ds...@jabberwocky.com wrote:

 On Apr 23, 2014, at 3:24 PM, helices g...@mdsresource.net 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: Removing old preferences from exported key

[David Shaw]

On Apr 8, 2014, at 1:48 AM, Johan Wevers joh...@vulcan.xs4all.nl 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 joh...@vulcan.xs4all.nl 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 gn...@tim.thechases.com 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 b...@norbl.com 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, -- -- postpics...@gmail.com 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, -- -- postpics...@gmail.com 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 15, 2014, at 3:53 PM, Juha Heljoranta juha.heljora...@iki.fi 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: 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 d...@fifthhorseman.net 
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: Encrypting File with passphrase

[David Shaw]

On Mar 12, 2014, at 9:07 AM, Kumar, Vikash X vikash.x.ku...@in.tesco.com 
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: 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
 mid:1730446.9J4b6oayU7@inno, 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: GPG key trust after a signing party

[David Shaw]

On Feb 26, 2014, at 8:43 AM, Óscar Pereira burn.till.s...@gmail.com 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 2:33 AM, Laurent Jumet laurent.ju...@skynet.be 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: Size of main key...

[David Shaw]

On Feb 23, 2014, at 10:54 AM, Laurent Jumet laurent.ju...@skynet.be wrote:

 
 Hello David !
 
 David Shaw ds...@jabberwocky.com 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: Newbie problem

[David Shaw]

On Feb 21, 2014, at 7:06 PM, john s. jrs...@cogeco.ca 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 o...@mat.ucm.es 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:02 PM, Uwe Brauer o...@mat.ucm.es 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: pgp export private key with password

[David Shaw]

On Jan 27, 2014, at 3:26 PM, Uwe Brauer o...@mat.ucm.es wrote:

 David == David Shaw ds...@jabberwocky.com writes:
 
 On Jan 27, 2014, at 3:02 PM, Uwe Brauer o...@mat.ucm.es 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: Import Raw RSA Secret Key?

[David Shaw]

On Dec 19, 2013, at 7:10 PM, Eric Swanson eswan...@alloscomp.com 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 w...@gnupg.org 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 11:31 AM, Matt D md...@nycap.rr.com 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: encryption algorithm

[David Shaw]

On Dec 17, 2013, at 1:53 PM, Matt D md...@nycap.rr.com 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 md...@nycap.rr.com 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 12:41 PM, Matt D md...@nycap.rr.com 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: Theoretical and maybe stupid questions about security

[David Shaw]

On Nov 20, 2013, at 1:21 PM, Josef G. Bauer josef.ba...@web.de 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: Setting encryption algorithm for specific key

[David Shaw]

On Nov 20, 2013, at 5:33 PM, Johan Wevers joh...@vulcan.xs4all.nl 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: How to add information about purpose/security of sub keys?

[David Shaw]

On Nov 13, 2013, at 6:08 PM, adrelanos adrela...@riseup.net 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: 2048 or 4096 for new keys? aka defaults vs. Debian

[David Shaw]

On Oct 24, 2013, at 3:05 PM, Sylvain b...@beuc.net 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: (GnuPG) 1.4.2 - Signature Verification Issue

[David Shaw]

On Oct 24, 2013, at 4:47 PM, VINEETA DESHMUKH (CRGL-THIRDPARTY.COM) 
vineeta_deshm...@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: better handling of importing local signatures

[David Shaw]

On Oct 15, 2013, at 7:30 PM, Hauke Laging mailinglis...@hauke-laging.de 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 br...@interlinx.bc.ca 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 ptau...@gmail.com 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 ptau...@gmail.com 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 r...@sixdemonbag.org 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 d...@fifthhorseman.net 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 csabi@gmail.com 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 9:56 AM, Robert J. Hansen r...@sixdemonbag.org 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: Serpent?

[David Shaw]

On Aug 22, 2013, at 10:15 AM, Daniel Kahn Gillmor d...@fifthhorseman.net 
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: Issue with --sign option

[David Shaw]

On Aug 18, 2013, at 11:45 AM, ashish tiwari ashishtewariash...@gmail.com 
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 m4rtn...@gmail.com 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 eye.of.the.8ehol...@gmail.com 
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 ds...@jabberwocky.com 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 eye.of.the.8ehol...@gmail.com 
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 6:38 AM, Kenneth Jones kenten...@me.com 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: Identifying your private key by the public KeyID

[David Shaw]

On Aug 6, 2013, at 9:22 AM, Kenneth Jones kenten...@me.com 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: 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 phi...@foolip.org 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
 http://foolip.org/2013/08/02/signing-policy/ 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 1, 2013, at 6:58 PM, Martin T m4rtn...@gmail.com 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 j...@example.net
 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 mailinglis...@hauke-laging.de 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 ma...@blisses.org 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 keyid | 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 miri...@riseup.net 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: default keyring file formats

[David Shaw]

On Feb 19, 2013, at 9:27 PM, John A. Wallace jw72...@verizon.net 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

Re: Best way to catch INSECURE unverified sig status when shelling out to gpg?

[David Shaw]

On Feb 9, 2013, at 6:09 PM, Grant Olson k...@grant-olson.net wrote:

 I'm currently writing a plugin that allows you to OpenPGP sign/verify
 ruby software packages:
 
 https://github.com/grant-olson/rubygems-openpgp
 
 Right now I'm just shelling out to gpg and checking the status code to
 determine success or failure.  When I have an unverified but good
 signature I don't get an error code.
 
 What is the best way to check for this?  I presume something like
 stdout.include?(INSECURE) is not localization friendly.

The option you're looking for is --status-fd.  Using that, you can get a 
stream of localization-safe string tags that can tell you the exact status of a 
signature.  See the DETAILS file from the GnuPG distribution for the specific 
tags.

David


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

Re: influence of signature type on trustdb

[David Shaw]

On Feb 7, 2013, at 5:12 AM, Niels Laukens ni...@dest-unreach.be wrote:

 Hi,
 
 I'm trying to figure out what the influence is of the different
 signature types (0x10-0x13). As far as I can tell, they only _indicate_
 the signers trust in his own sig, but isn't used in any way by GPG. Is
 this correct?

Basically correct.  All of the signature types are equal except for the 
influence of --min-cert-level.  By default, that's set to 2, so the 0x11 
persona signature is ignored when building the trustdb.  A signature whose 
very definition indicates that the person didn't check before making it, is 
probably one you want to skip :)

David


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

Re: gpg: WARNING: message was not integrity protected - MDC

[David Shaw]

On Jan 31, 2013, at 8:29 AM, perhop per.hopstad...@logica.com wrote:

 Hi
 
 This has been discussed before and I have an question referring to this.
 Short summary:
 
 A customer encrypts data with our public key, we receive the file and we
 attempt to decrypt it. The decrypt step seems to work but we get a warning
 message while validating the file (gpg: WARNING: message was not integrity
 protected).  The question is how to avoid the warning message.
 
 After reading the forum I believe this has to do with mdc, that mdc is not
 forced in this case and that is causing the warning message.
 
 I would like to know how you enable mdc. Do I tell the customer to force mdc
 or is that controlled from my side, automatic controlled depending on what
 cipher method I use? 
 We run GPG version 1.4.9 and customer PGP 7.1

Note that the message you see is just a warning.  It does not affect decryption 
- it's just telling you that the sender didn't protect the message.

There are several ways to enable MDC.  The most common way is a flag on your 
key that instructs the customer's PGP to enable MDC (i.e. I can handle MDC, so 
you're free to use it).  So the first thing you should do is check your key to 
see if it has the MDC flag on it.  To do this, run:

  gpg --edit-key (yourkey)

and enter showpref at the prompt.  The final line is Features.  If MDC is 
on that line, then you have the MDC flag, and anyone communicating with you 
should use a MDC if they support it.  That said, I see that your customer is 
using PGP 7.1, which is incredibly old at this point.  I don't recall offhand 
if it supports MDC or not (I have a vague recollection that PGP only started 
supporting it in PGP 8 - which is itself very old at this point).

If your key has the MDC flag, then the problem is most likely that the 
customer's PGP doesn't support MDC.  Since you probably can't upgrade the 
customer, you can use the --no-mdc-warning on your side.  This doesn't change 
the fact that the message you got isn't protected, but does prevent the warning 
from being printed.

David


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

Re: Paperkey 1.3

[David Shaw]

On Jan 7, 2013, at 11:05 AM, David Smith dave.sm...@st.com wrote:

 On 01/04/13 17:31, David Shaw wrote:
 Sure, paperkey supports piping the output into whatever code generator you 
 like:
 
 gpg --export-secret-key mykey | paperkey --output-format raw | 
 your-bar-code-generator
 
 However, 2D bar codes have some of the problems that paperkey is intended to 
 address.  You need a 'thing' (a process, a device, etc) to read them, and 
 part of the point of paperkey is that it's supposed to be the backup of last 
 resort, and thus readable by a human without any special hardware involved.
 
 True, but OTOH, whilst hardware devices do tend to become obsolete
 relatively quickly, the algorithms tend to have more longevity.  For
 example, you might struggle to find one of the earlier 1d bar code
 reader pens that I remember from the 1980s around now, and even the
 software used for reading and interpreting them will probably have
 disappeared, but the overall mechanism is still widely used.
 
 I would suggest that we are going to have devices for scanning paper to
 a digital image for quite a few years yet (whether they are SCSI-based
 ones from years ago, through USB-connected multi-function printers, to
 digital cameras and beyond.  2d bar codes (and the algorithms needed to
 process them) are well-specified, so even if the existing software
 becomes unusable, it could be re-written for a new platform.

This is exactly the point.  Algorithms may stay around, but if have to 
reconstruct printed data given only knowledge of the encoding algorithm 
(without the hardware intended to read it, or the software intended to 
reconstruct the data), well, it's possible, but sure as heck won't be quick or 
cheap for someone with image processing experience, or even possible for the 
majority of people without that knowledge.

Paperkey often spawns this discussion about how we could use scannable paper 
images using x, y, or z encoding, or favorite brands of burnable CDs that will 
last, etc. No doubt, favorite flash brands will be discussed in the future.  
These are all interesting discussions, but it's sort of missing the point.  
Paperkey is a way to store your key in a way that needs nothing more than eyes 
and a keyboard to restore, and uses a medium that can last for many times the 
greatest human lifespan.  The disadvantage is that it's potentially annoying to 
recover a key from paper (i.e. typing in a several hundred hex bytes without 
error).  There are per line checksums to make this easier, so you know where a 
mistake is, and you can use OCR to save on typing, but still, you have to get 
the bytes from paper into a computer somehow.  All that is fine, as paperkey 
does not, and is not intended to, replace a backup of your secret keys. It's 
not where you should be going if your primary storage goes poof.

 I'm not saying that there isn't a place for printing the key out in
 ASCII; just that it might be a good idea to print it out as a 2d barcode
 as well

Exactly.  Keep proper backups!  Paperkey is for when that backup fails, for 
when your CD stops working, for when the driver for your scanning pen isn't 
maintained on your new computer, or for when cosmic rays have rendered your 
flash corrupt.  It's the backup of last resort, and as such should need nothing 
other than nothing other than the ability to read numbers and type them in 
again to restore, hence my comment about not favoring a 2D barcode paperkey.

David


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

Re: gnupg not working with RHEL 4

[David Shaw]

On Jan 3, 2013, at 2:37 PM, Anilkumar Padmaraju apadmar...@prounlimited.com 
wrote:

 Hi,
 
 This is an important issue for me.  I would really appreciate, if any one can 
 help.
 
 Server 1:
 I have a server with Red Hat Enterprise Linux AS release 4 (Nahant Update 5) 
 and having gnupg version 1.2.6.
 
 
 When I am trying to import a key, I am getting below problem and the key is 
 not getting imported.  The key is 2048 bits.
 
 
 
 # gpg --import /key.asc
 gpg: DSA requires the use of a 160 bit hash algorithm

This means that you are trying to import a key with a version of GnuPG that is 
too old to understand it.  That key uses a feature (called DSA2) that didn't 
exist in version 1.2.6 of GnuPG.

 Unfortunately, I cannot upgrade Linux on Server 1.  What I have to do to 
 solve the problem with gpg import on Server 1?  

While you don't have to upgrade Linux on server 1, you do need to at least 
upgrade GnuPG.

Go to http://www.gnupg.org/download/ and grab the latest 1.4 version of GnuPG 
(at the moment, it's 1.4.13).  That is the easiest replacement for 1.2.6, and 
will handle that DSA2 key just fine.

David


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

Re: New packet headers and gpg

[David Shaw]

On Jan 4, 2013, at 9:39 AM, Stephen Paul Weber singpol...@singpolyma.net 
wrote:

 Somebody claiming to be David Shaw wrote:
 On Jan 3, 2013, at 9:53 PM, Stephen Paul Weber singpol...@singpolyma.net 
 wrote:
 tell gpg or gpg2 to produce new packet length headers for output?  
 
 No.  GPG automatically uses the old packet headers for those packets that 
 can be described that way
 
 Hmm, ok.  I was hoping that with all the advanced mode, you probably don't 
 care about this features, there would be one for this.

You could patch the code (look in build-packet.c) fairly easily if you need 
this.  Out of curiosity, why do you want to use only new packet headers?

David


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