Re: The best practice of master/sub key capabilities
On 22/08/15 17:25, Dongsheng Song wrote: Now I want to create my new key like this: sec rsa4096/93D374EB 2015-08-22 [C] uid [ultimate] example exam...@someone.xyz ssb rsa2048/466D08E1 2015-08-22 [S] ssb rsa2048/AD92E667 2015-08-22 [E] ssb rsa2048/07DEFA25 2015-08-22 [A] ssb ed25519/AE83BE7C 2015-08-22 [S] ssb cv25519/0FACE148 2015-08-22 [E] ssb ed25519/610E5096 2015-08-22 [A] Sorry I forgot to answer earlier. This seems a reasonable setup. If this makes you feel happy, go for it :). I still think RSA-4096 is a bit much, though. People who have your public key and use an underpowered system will see that building the trust database can take significantly longer in checking your certifications. I don't know when GnuPG checks subkey bindings, but that takes significantly longer as well. Subkey bindings verify the correspondence between a primary key and a subkey, and are part of your public key. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
On Fri, Aug 21, 2015 at 6:49 PM, Peter Lebbing pe...@digitalbrains.com wrote: On 21/08/15 11:31, Dongsheng Song wrote: But I still did't know why the master key have sign and certify capabilities in the default ? I suppose because it doesn't hurt. They're both signatures in essence; cryptographically they are the same and exchangable. The difference only lies in the interpretation. Also note that anyone who has access to the primary key material can issue data signatures at will. They could either add the Sign capability to the key or (easier) create a new subkey with which to issue signatures. The actual reason why the default is as it is can probably best be answered by someone else, though, since I can only guess. Maybe create more subkey need more entropy, gain enough entropy need very long time ? Now I want to create my new key like this: sec rsa4096/93D374EB 2015-08-22 [C] uid [ultimate] example exam...@someone.xyz ssb rsa2048/466D08E1 2015-08-22 [S] ssb rsa2048/AD92E667 2015-08-22 [E] ssb rsa2048/07DEFA25 2015-08-22 [A] ssb ed25519/AE83BE7C 2015-08-22 [S] ssb cv25519/0FACE148 2015-08-22 [E] ssb ed25519/610E5096 2015-08-22 [A] If something bad happened to my subkeys, I can create new subkeys as well. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
On 21/08/15 11:31, Dongsheng Song wrote: But I still did't know why the master key have sign and certify capabilities in the default ? I suppose because it doesn't hurt. They're both signatures in essence; cryptographically they are the same and exchangable. The difference only lies in the interpretation. Also note that anyone who has access to the primary key material can issue data signatures at will. They could either add the Sign capability to the key or (easier) create a new subkey with which to issue signatures. The actual reason why the default is as it is can probably best be answered by someone else, though, since I can only guess. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
Dongsheng Song dongsheng.s...@gmail.com writes: Hi all, When I create new master/sub key, in the following 2 choice, I'm wondering which is better? 1) master key have SCEA capabilities sec rsa4096/A19676A1 created: 2015-08-20 expires: never usage: SCEA trust: ultimate validity: ultimate ssb rsa4096/27ADD750 created: 2015-08-20 expires: never usage: SEA 2) master key have only Certify capability sec rsa4096/1F8AFCAD created: 2015-08-20 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/8E1D2A87 created: 2015-08-20 expires: never usage: SEA I would use a SC master key because I would want to use it to certify other's keys, and would also be able to use it to sign statements in case something bad happened to my sub-keys. I would use three separate sub-keys, one each for the three SEA usages. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
On 20/08/15 17:01, Peter Lebbing wrote: Most importantly, it's generally advised not to do encryption and signing with the same key material. This is just a general recommendation, and abusing the fact a key is used for both encryption and signatures is an intricate matter. But since OpenPGP supports subkeys, the matter is easily avoided completely by using a separate subkey for encryption, so it's a good idea to do so. But it suddenly dawned on me you might have an actual issue when you assign both Sign and Authenticate capabilities to a key! Authentication is pretty much proving that you can sign what the server sends you. It might be the case that these signatures can actually pass for data signatures or key certifications! I don't think RFC 4880 says anything about authentication (except when used to refer to data signatures and key certifications). Checking the OpenPGP Card Specification 3.0, it would seem that the key in the Authenticate command can indeed issue signatures, since the PKCS#1 padding is identical to the Sign command, and there is no check on the signed data. It seems like a genuinely bad idea to assign Authenticate capability to a key that has Certify or Sign set. Even if GnuPG or GPG-Agent does checks to catch abuse, it's just asking for trouble that is easily avoided, in my opinion. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
Thanks, now I see why I should use a exclusively subkey for authenticate capability. But I still did't know why the master key have sign and certify capabilities in the default ? I think the sign capability should move to a exclusively subkey. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
The best practice of master/sub key capabilities
Hi all, When I create new master/sub key, in the following 2 choice, I'm wondering which is better? 1) master key have SCEA capabilities sec rsa4096/A19676A1 created: 2015-08-20 expires: never usage: SCEA trust: ultimate validity: ultimate ssb rsa4096/27ADD750 created: 2015-08-20 expires: never usage: SEA 2) master key have only Certify capability sec rsa4096/1F8AFCAD created: 2015-08-20 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/8E1D2A87 created: 2015-08-20 expires: never usage: SEA Regards, Dongsheng ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
When I create new master/sub key, in the following 2 choice, I'm wondering which is better? I'd recommend the defaults as best practice. They're there for a reason. Why are you restricting yourself to the following 2 choices? They both seem ill-advised (and unusual as well). Most importantly, it's generally advised not to do encryption and signing with the same key material. Furthermore, it is disputed whether RSA-4096 offers a useful cost/benefit tradeoff. Personally, I'm on the side that thinks it does not. But who am I. You also didn't indicate what your usage scenario is, so without that information, the defaults again seem like a pretty solid answer. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reading key capabilities information before importing a key
On Fri, 12 Apr 2013 03:00, mailinglis...@hauke-laging.de said: That is an inconsistent explanation. If --list-packets can show data from signatures without checking the signatures then obviously --with-colons It does not show that. It dumps the packets. The key capabilities need to be computed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reading key capabilities information before importing a key
On Thu, 11 Apr 2013 00:28, mailinglis...@hauke-laging.de said: 2) You import the key but direct it to a different keyring, see --keyring --secret-keyring --primary-keyring --no-default-keyring You better use a temporary directory. This is far easier than to play with all the options and it allows you to use gpgme. Another option is to import the key and then delete it if you don't want it. However, we have a --merge-only option but not a --only-new-key-option. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reading key capabilities information before importing a key
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Branko Majic asked: I'm trying to find a way to list the key capabilities of a key before importing it. I can obtain some basic information by using the command (I've seen this one in the mailing list archives): In addition to the other suggestions, I prefer using --dry-run and a double verbose: gpg --dry-run --import --verbose --verbose test.key - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201304112056 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlFnZdcACgkQvJuQZxSWSsj/SwCgkcU/jWIFphT5t4zIL4eHKDya 9gAAn22R0GMK5ltureFUecNOgbFz/EJy =WvD+ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reading key capabilities information before importing a key
Hello all, I'm trying to find a way to list the key capabilities of a key before importing it. I can obtain some basic information by using the command (I've seen this one in the mailing list archives): gpg2 --with-colons test.key The only catch being that the above command will not list the key capabilities for the keys contained in a file. Any way to obtain this information without importing the key into keyring? I'm using GnuPG 2.0.19 with libgcrypt 1.5.0 on Debian Wheezy 64-bit. Best regards -- Branko Majic Jabber: bra...@majic.rs Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: bra...@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reading key capabilities information before importing a key
Am Mi 10.04.2013, 22:57:53 schrieb Branko Majic: Hello all, I'm trying to find a way to list the key capabilities of a key before importing it. I can obtain some basic information by using the command (I've seen this one in the mailing list archives): gpg2 --with-colons test.key The only catch being that the above command will not list the key capabilities for the keys contained in a file. Any way to obtain this information without importing the key into keyring? Two possibilities: 1) gpg --list-packets hauke__0x1a571df5.asc [...] :public sub key packet: version 4, algo 1, created 1352000413, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: 486B17AB3F96AD8E :signature packet: algo 1, keyid BF4B8EEF1A571DF5 version 4, created 1352000413, md5len 0, sigclass 0x18 digest algo 2, begin of digest c1 78 hashed subpkt 2 len 4 (sig created 2012-11-04) hashed subpkt 27 len 1 (key flags: 02) [...] Subpacket class 27 is the key capabilities. [http://www.ietf.org/rfc/rfc4880.txt] First octet: 0x01 - This key may be used to certify other keys. 0x02 - This key may be used to sign data. 0x04 - This key may be used to encrypt communications. 0x08 - This key may be used to encrypt storage. 0x10 - The private component of this key may have been split by a secret-sharing mechanism. 0x20 - This key may be used for authentication. 0x80 - The private component of this key may be in the possession of more than one person. 2) You import the key but direct it to a different keyring, see --keyring --secret-keyring --primary-keyring --no-default-keyring Hauke -- ☺ PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Capabilities
Christoph Anton Mitterer wrote: Cryptographically it is about the same as normal signing, it simly denotes that a key may be used to sign other keys. Jep, I just stumbled on GPG not displaying it (because I was just creating a key that will mainly be used to sign other keys). Thanks, Christoph and David for enlighting me... Olaf -- Dipl.Inform. Olaf Gellert PRESECURE (R) Senior Researcher, Consulting GmbH Phone: (+49) 0700 / PRESECURE [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Key Capabilities
Hi, I have read about the following key capabilites: - sign - encrypt - authenticate - certification When I generate an RSA key, GPG provides the capabilities sign, encrypt and authenticate (in expert mode), but not certification. Is certification somethin that is actually implemented or planned for the near future? What usage is expected to depend on this capability? Cheers, Olaf -- Dipl.Inform. Olaf Gellert PRESECURE (R) Senior Researcher, Consulting GmbH Phone: (+49) 0700 / PRESECURE [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Capabilities
On Thu, Nov 17, 2005 at 02:34:06PM +0100, Olaf Gellert wrote: Hi, I have read about the following key capabilites: - sign - encrypt - authenticate - certification When I generate an RSA key, GPG provides the capabilities sign, encrypt and authenticate (in expert mode), but not certification. Is certification somethin that is actually implemented or planned for the near future? What usage is expected to depend on this capability? Certification is just the ability to sign other keys. All primary keys, by definition, are able to certify, so the flag is not very meaningful there. In GPG 1.4.2 the key generation menu doesn't show you certification as an option, but it does automatically set the flag behind the scenes. 1.4.3 is a little different. To make things clearer, 1.4.3 does show certification in the list of flags, but you can't turn it off (as this would violate OpenPGP). David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Capabilities
Olaf Gellert wrote: When I generate an RSA key, GPG provides the capabilities sign, encrypt and authenticate (in expert mode), but not certification. Certification is always used automatically for the primary (signing) key. If you edit your key (gpg --edit-key foo) you'll see a Usage: CS for the primary key. Is certification somethin that is actually implemented or planned for the near future? It is actually implemented (its one of the most basic features: signing keys What usage is expected to depend on this capability? Cryptographically it is about the same as normal signing, it simly denotes that a key may be used to sign other keys. Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton org:Munich University of Applied Sciences;Department of Mathematics and Computer Science adr;quoted-printable;quoted-printable:;;Lothstra=C3=9Fe 34;M=C3=BCnchen;Freistaat Bayern;80335;Federal Republic of Germany email;internet:[EMAIL PROTECTED] tel;home:+49 89 24409568 tel;cell:+49 172 8617341 x-mozilla-html:TRUE url:http://fhm.edu/ version:2.1 end:vcard ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key capabilities usage meanings
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 David Shaw wrote: | Authentication is signing a challenge (like ssh does). The | Authentication stuff can be used to log in to a machine using your GPG key. | Is there any public documentation on how to implement this? The only way I've seen thus far to implement this is to use patched versions of the SSH daemon which I'm rather loathe to do if there's an easier/more-supported way. Thx! - -- Cheers! J. Wren Hunt Cambridge, MA. USA - In theory, there is no difference between theory and practice. But, in practice, there is. - Jan L.A. van de Snepscheut +--+ | v-card http://wrenhunt.homelinux.org/data/wren.vcf | | x.509http://wrenhunt.homelinux.org/data/thawte_wren_hunt.cer | | OpenPGP ADF5 1432 A59E 8F4D 4AE7 4DFE 03FA 91E1 4A24 D6F4 | +--+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFCWSFLA/qR4Uok1vQRAy3rAJ9QqFnVlQHrbyMyAxDGvRywffnw3QCgleSy 9xBD8WIaJjSp4yPcziXKh/A= =1QSy -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key capabilities usage meanings
On Fri, Apr 01, 2005 at 06:33:13PM +0200, [EMAIL PROTECTED] wrote: What is the meaning of usage/capabilities listings for keys(shown, for example, during edit-keys interactive sessions)? S - sign E - encrypt C - ? A - ? looking at doc/DETAILS I found C - certification A - authentication But I dont' understand the difference between certification, authentication and signing. I have different keys, each for a different internet personality, and I noticed that one primary key is listed as CSA and another CS. The two keys were generated with the same options (DSA for signing +ElGamal subkey for pubkey encryption), so why this difference? Probably they were generated with two different versions of GnuPG. The A authentication type is fairly recentl. Signing is signing data (i.e. gpg --sign the_file) Certification is signing a key (i.e. gpg --sign-key the_key) Authentication is signing a challenge (like ssh does). The Authentication stuff can be used to log in to a machine using your GPG key. The signature math is the same however you do it. The key usage flags are just to classify things. Another question: I read in manpage that MDC is enabled by default with newer ciphers(blocksize64bit) and with CAST5. So why when you decipher a symmetrically encrypted message you get WARNING: message was not integrity protected and only with --force-mdc the warning goes away? Not with CAST5. CAST5 has a blocksize of 64 bits. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
