Re: [openpgp] SHA-2 support should be mandatory – change defaults
On 8/12/2014 at 11:46 PM, David Shaw ds...@jabberwocky.com wrote: 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? = As a pgp 2 user, I agree with all the above, and taking whatever steps are felt to be easier to maintain and move GnuPG forward. Those who insist on using pgp2.x for whatever things (actually very very few) they feel cannot be accomplished with GnuPG, will do so anyway. I ask only, that acceptance of V3 keys be maintained, as many of us have used our V3 keys in GnuPG, (with SHA 2 and 64 bit algorithms), Otherwise, all our encrypted messages will not be able to be decrypted in later versions of GnuPG, and if the encrypted messages were signed, they would no longer be able to be verified, (as even Disastry's version, while able to decrypt everything except Camellia, cannot verify a V4 key signature). vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
what is correct for users' Preferred keyserver ?
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 ? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[2] cipher when viewing key prefs
i recently saw [2] listed as the last cipher in somebody's public key the key didn't specify 3DES neither - that goes against the RFC but how is that possible ? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg --verify email.eml
lately some recipients have not been able to decrypt some emails ie. some can decrypt them; some can't every time i send a signed+encrypted email, enigmail reports signature verification failed but the status bar is green ! but when i send just signed emails, no problem with sig verification (status bar is still green) if thunderbird and enigmail were used to construct emails, and enigmail debug output reports everything ok: [GNUPG:] GOODSIG [GNUPG:] VALIDSIG [GNUPG:] TRUST_ULTIMATE [GNUPG:] DECRYPTION_OKAY [GNUPG:] GOODMDC [GNUPG:] END_DECRYPTION but gpg --verify -vv email.eml gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Charset: utf-8 :pubkey enc packet: version 3, algo 1, keyid data: [4093 bits] gpg: verify signatures failed: unexpected data how should i proceed to debug this ? i downgraded enigmail to enigmail 1.6 because i couldn't sign or encrypt at all with the recent update ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Different signing encryption keys
On Wed, 13 Aug 2014 06:29, r...@sixdemonbag.org said: Look at the right hand side. For each subkey (including the main signing key) there will be an entry for usage. This field can contain the letters S, C, A, or E. Using --edit-key is a bit cumbersome and --with-colons is hard to read. Thus what about this new option: $ gpg2 -k --list-options show-usage 1e42b367 pub dsa2048/1E42B367 2007-12-31 [SC ] [expires: 2018-12-31] uid [ unknown] Werner Koch w...@gnupg.org uid [ unknown] Werner Koch uid [ unknown] Werner Koch xxx sub dsa1024/77F95F95 2011-11-02 [S ] sub rsa2048/664D7444 2014-01-02 [E ] [expires: 2016-12-31] However, it might be better to use a variable length field because the column position depends on the algorithm anyway: pub dsa2048/1E42B367 2007-12-31 [SC] [expires: 2018-12-31] uid [ unknown] Werner Koch w...@gnupg.org uid [ unknown] Werner Koch uid [ unknown] Werner Koch xxx sub dsa1024/77F95F95 2011-11-02 [S] sub rsa2048/664D7444 2014-01-02 [E] [expires: 2016-12-31] Salam-Shalom, 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: [openpgp] SHA-2 support should be mandatory – change defaults
On Wed, 13 Aug 2014 08:09, ved...@nym.hush.com said: Otherwise, all our encrypted messages will not be able to be decrypted in later versions of GnuPG, and if the encrypted messages were signed, they would no longer be able to be verified, Being abke to decrypt is important and thus this will not be removed. 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: Requesting public key with GnuPG 1.4.18
On Wed, 13 Aug 2014 06:24, laurent.ju...@skynet.be said: I see key 0x05E136A0 is about to be requested from server, but what's that secundary number FC3B17DE05E136A0? That is the same key. The first is the short and the second the long key id: 05E136A0 FC3B17DE05E136A0 Salam-Shalom, 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: [openpgp] SHA-2 support should be mandatory – change defaults
On Wed, 13 Aug 2014 05:41, ds...@jabberwocky.com said:
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?
Fine with me.
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'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.
okay.
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: Different signing encryption keys
On 12/08/14 21:05, Werner Koch wrote: On Tue, 12 Aug 2014 19:50, ps...@ubuntu.com said: We used to use different keys for signing and encrypting ( DSA El Gammel ), but these days just seem to use a single RSA key by default. That is not the case. GnuPG creates an RSA signing key and an RSA encryption subkey by default. These are different keys because the common wisdom is to use one key for one purpose. The important here must be 'by default'. Last year, I followed a thread on the gpg4win forum and created an 8192 key using gpg --batch command. The key produced was a single RSA8192 key for encrypt, sign, certify, authenticate, probably because I did not specify any sub-key. (I still have it but have never used it nor released it to the world). I don't recall having been prompted by gpg to specify a sub-key so I could say that gpg produced a single key 'by default'. It was a year ago so I could be mistaken. 0x23543A63.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Gnupg-users Digest, Vol 131, Issue 15
I'm not sure, but didn't discrete-logarithm keys scale roughly equivalently to RSA? I think so, but I'm not sure... and The guidance from NIST is: [1] shannons of entropy needed [2] bits of symmetric key [3] bits of RSA/DSA/ELG [4] bits of ECDSA/ECetc. [1] [2] [3] [4] 80 80 1024160 112 112 2048224 128 128 3072256 256 256 ~15k512 The entropy of symmetric and ECDSA/ECetc. keys scales linearly with key length; the entropy of RSA/DSA/ELG keys scales logarithmically with key length. and However, I've also been cautioned by some big names in crypto that I shouldn't put too much stock in this: we know DLP must be at least as hard as integer factorization, but we don't have precise numbers for how much harder it has to be, and the tendency over the years has been for the two to slowly converge in difficulty. As of now the best guidance is to think DLP is at least as hard as IFP, but to be skeptical about how much harder. No witchcraft, just some simple math. Baltimore published: (http://www.nsa.gov/business/programs/elliptic_curve.shtml) symm. RSA ECC 80 1024160 112 2048224 128 3072256 192 7680384 256 15360 521 The generalized number field sieve(-RSA factoring) scales with bitlength to the 1/3 (http://en.wikipedia.org/wiki/General_number_field_sieve), new improvements by Joux et al (http://eprint.iacr.org/2013/400.pdf) set it to 1/4 but this so far seems limited to smaller numbers. ECC security scales with bitlength to the 1/2 (General DLP methods) If you set the scale to 160 bit ECC being at the same security level as 1024 bit RSA (presently considered marginal security) you arrive at the formula for the generalized number field sieve: n(RSA) = ((n(ECC)^1/2)/1.25)^3 The resulting table would look like this ECC(bitlength) RSA/elGamal 160 1024 256 2072 384 3807 512 5862 768 10769 1024 16579 If you presume Joux's results would apply to RSA factoring, the formula would look like: n(RSA) = ((n(ECC)^1/2)/15.9)^4 Now the resulting table would look like this ECC(bitlength) RSA/elGamal 160 1024 256 2621 384 5898 512 10486 768 23593 1024 41943 Interestingly NIST arrives at an estimate even in excess of the second table! So we might speculate that they either know of some improvement compared to the publicly known methods to factor RSA moduli, expect such improvement from other sources or else just want to push ECC. (I like ECC - google open source elliptic curve cryptography.)) Cheers Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: checking created signature failed: Bad signature
The plot thickens. I have just generated a new keypair on the Arch Linux box where I'm having the problem and I can use this new key (repeatedly) to gpg2 --clearsign doc and it works every time. So, it seems that the 'Bad signature' issue is related solely to my 'primary' key, which would suggest that hardware is not to blame? As another test, I have also deleted the primary keypair, exported it from the (working) Windows machine and re-imported it on the Linux machine but I still get the intermittent 'Bad signature' error. Any additional thoughts? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
keys.gnupg.net - Refresh all public keys never completes in Enigmail, some servers down?
Please CC me in etc, I'm not subscribed to the list. Haven't been able to 'refresh all public keys' on keys.gnupg.net in Enigmail for a while now (only have two keys), so I had a look at the servers responsible (host keys.gnupg.net) - the following appear to be bad for me accessing from the UK: 131.155.141.70: No response to pings 63.230.134.161: Destination Host Unreachable 173.175.198.28: No response to pings I'm guessing Enigmail/Icedove is consistently using a bad server. -- Libre software on Github: https://github.com/OmegaPhil FSF member #9442 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Requesting public key with GnuPG 1.4.18
Hello Werner ! Werner Koch w...@gnupg.org wrote: I see key 0x05E136A0 is about to be requested from server, but what's that secundary number FC3B17DE05E136A0? That is the same key. The first is the short and the second the long key id: 05E136A0 FC3B17DE05E136A0 I had a doubt, as I didn't notice before that the long KeyID has the same last 8 digits than the short. Did always GPG get the key from a server with the long KeyID? I was thinking it used the 0x8 -- Laurent Jumet KeyID: 0xCFAF704C ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Seeking clarification with a few GPG concepts
Hello, I'm new to GPG, and after having read the documentation, I still have a few questions: Suppose Alice generates a new master signing key, and along with it the UID Alice u...@alice.com. Then, she issues adduid to add Alice u...@company.com, her company mailing address. After some time, she leaves the company, invalidating her email address. Consequently, she revokes her UID u...@company.com and sends her updated public key to everyone she's in contact with. Then, for some reason, Alice joins aforementioned company again, re-gaining control of her mail address u...@company.com. Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I understand that she would not be able to re-use signatures she collected on her old UID on her new one, but would have to start building trust from scratch. But still, is it possible to do so, or would the revocation of the old uid2 also immediately apply to the new uid2? In another scenario, Alice not only has a master key, but also subordinate keys, say for her notebook and mobile phone. First, can she say that the mobile phone should be able to sign/decrypt only for u...@alice.com? How so? Second, if her notebook subordinate key can sign/decrypt for both UIDs, and someone sends a mail to u...@alice.com, which pubic key does he encrypt the message with? I assume the sender, by default, would simulatenously use all encryption keys (master or subordinate) he knows of, so that the message can be decrypted with any one private key. Is that the case? Can the sender choose to only encrypt using one of the keys, e.g. to make sure Alice doesn't read the message on her phone, but waits until she gets home to her notebook (in case the sender considers it more trustworthy, and the sender knows how the keys are associated with Alice's machines)? What happens if a subordinate key of mine expires? Can I just generate a new one and let people know? Or would I also have lost trust/signatures of my identities gathered in the past? Phrased differently, if Bob signes Alice's UID X, what does he sign exactly? Just that he trusts UID X belongs to the name and address given in UID X, and that UID X is associated with Alice's master key, or does Bob's signature also say something about subordinate keys of Alice's gpg key and/or other UIDs of Alice which Bob did not intend to verify? Finally, I am wondering how I should organise my UIDs. I could either have one gpg key and add each UID to that one, or I could have multiple seperate gpg keys, one for each UID. The latter approach seems more flexible to me, in terms of choosing how much information I want to disclose to recipients of my gpg keys, and, depending on the answers to the questions above, also in terms of control I have over how my keys are used. Does having all UIDs in one gpg key have any advantages, except for being easier to organise for me and for people who want to sign my identities? Would it be considered strange, or even rude of some sort, if I asked someone to sign a number of identities of mine scattered across multiple gpg keys, instead of just handing them one gpg key and asking them to sign UIDs x, y and z? I know these are a lot of questions, but I honestly couldn't find satisfactory answers in the documentation or using search engines. I would be very grateful if you could attempt to enlighten me. :) Thank you very much in advance! P.S.: It seems like my previous attempt to post this message failed. I hope the mail won't come through twice now. I'm sorry if it does. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Seeking clarification with a few GPG concepts
Hello, I'm new to GPG, and after having read the documentation, I still have a few questions: Suppose Alice generates a new master signing key, and along with it the UID Alice u...@alice.com. Then, she issues adduid to add Alice u...@company.com, her company mailing address. After some time, she leaves the company, invalidating her email address. Consequently, she revokes her UID u...@company.com and sends her updated public key to everyone she's in contact with. Then, for some reason, Alice joins aforementioned company again, re-gaining control of her mail address u...@company.com. Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I understand that she would not be able to re-use signatures she collected on her old UID on her new one, but would have to start building trust from scratch. But still, is it possible to do so, or would the revocation of the old uid2 also immediately apply to the new uid2? In another scenario, Alice not only has a master key, but also subordinate keys, say for her notebook and mobile phone. First, can she say that the mobile phone should be able to sign/decrypt only for u...@alice.com? How so? Second, if her notebook subordinate key can sign/decrypt for both UIDs, and someone sends a mail to u...@alice.com, which pubic key does he encrypt the message with? I assume the sender, by default, would simulatenously use all encryption keys (master or subordinate) he knows of, so that the message can be decrypted with any one private key. Is that the case? Can the sender choose to only encrypt using one of the keys, e.g. to make sure Alice doesn't read the message on her phone, but waits until she gets home to her notebook (in case the sender considers it more trustworthy, and the sender knows how the keys are associated with Alice's machines)? What happens if a subordinate key of mine expires? Can I just generate a new one and let people know? Or would I also have lost trust/signatures of my identities gathered in the past? Phrased differently, if Bob signes Alice's UID X, what does he sign exactly? Just that he trusts UID X belongs to the name and address given in UID X, and that UID X is associated with Alice's master key, or does Bob's signature also say something about subordinate keys of Alice's gpg key and/or other UIDs of Alice which Bob did not intend to verify? Finally, I am wondering how I should organise my UIDs. I could either have one gpg key and add each UID to that one, or I could have multiple seperate gpg keys, one for each UID. The latter approach seems more flexible to me, in terms of choosing how much information I want to disclose to recipients of my gpg keys, and, depending on the answers to the questions above, also in terms of control I have over how my keys are used. Does having all UIDs in one gpg key have any advantages, except for being easier to organise for me and for people who want to sign my identities? Would it be considered strange, or even rude of some sort, if I asked someone to sign a number of identities of mine scattered across multiple gpg keys, instead of just handing them one gpg key and asking them to sign UIDs x, y and z? I know these are a lot of questions, but I honestly couldn't find satisfactory answers in the documentation or using search engines. I would be very grateful if you could attempt to enlighten me. :) Thank you very much in advance! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Different signing encryption keys
On 13/08/14 10:56, Philip Jackson wrote: I don't recall having been prompted by gpg to specify a sub-key so I could say that gpg produced a single key 'by default'. You say you generated it with the --batch command, and go on to say you weren't prompted. Since --batch, unattended key generation, is for non-interactive use, you will not be prompted because you are expected not to interact. If I look at the docs for unattended key generation, it seems that indeed not specifying a Key-Usage: implies all usages are enabled. Unattended key generation is not normally a user-facing interface. Many people will probably not even know it's there. I don't think it helps to call it what GnuPG works like by default. 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: Different signing encryption keys
On 13/08/14 09:37, Werner Koch wrote: Thus what about this new option: That sounds like a nice thing to have. 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: Seeking clarification with a few GPG concepts
Hello, Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I'm pretty sure that, yes, you can. In another scenario, Alice not only has a master key, but also subordinate keys, say for her notebook and mobile phone. First, can she say that the mobile phone should be able to sign/decrypt only for u...@alice.com? For decryption: No. UID's are always bound to the primary key. If someone encrypts data to you, they are free to choose whatever non-expired encryption-capable subkey or master key they want. In practice, you'll usually see that it will be encrypted to the last created non-expired key. You choose which key you use to sign with; your peers will accept signatures from any non-expired signing-capable key. There is no proper way to say to your peers encrypt to this subkey if you want me to read it on the move and encrypt to that subkey if you want I can only read it on my super-secure computer. What happens if a subordinate key of mine expires? Can I just generate a new one and let people know? Or would I also have lost trust/signatures of my identities gathered in the past? You can simply generate a new one. Certifications are done on the pair of an UID and your master key. Subkeys don't play a role in certifications. Just that he trusts UID X belongs to the name and address given in UID X, and that UID X is associated with Alice's master key Precisely. Although you are actually a bit too specific. A certification means what the signing party wants it to mean. Some people will not verify the e-mail address. Some will decline to sign a key with a comment they can't properly verify or otherwise object to. Some will have their signature mean I've seen multiple e-mails from this person signed with this key, others will want to hire a private investigator and interrogate your parents (obviously only after a DNA test). Finally, I am wondering how I should organise my UIDs. There is no single best way. Both all UIDs on one key and separate keys per UID are done. Both have their pros and cons. Would it be considered strange, or even rude of some sort, if I asked someone to sign a number of identities of mine scattered across multiple gpg keys No, I wouldn't think so. But obviously someone might say I'm sorry, that's too much effort for me :). P.S.: It seems like my previous attempt to post this message failed. I hope the mail won't come through twice now. I'm sorry if it does. It did come through twice; the time it takes for your message to be circulated to all the members can vary quite a bit. 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: Seeking clarification with a few GPG concepts
Am Mi 13.08.2014, 11:57:12 schrieb pze...@hushmail.com: updated public key to everyone she's in contact with. Then, for some reason, Alice joins aforementioned company again, re-gaining control of her mail address u...@company.com. Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I understand that she would not be able to re-use signatures she collected on her old UID on her new one, but would have to start building trust from scratch. But still, is it possible to do so, or would the revocation of the old uid2 also immediately apply to the new uid2? The UID is not the packet data in the OpenPGP certificate but the string Alice u...@company.com i.e. the same string is the same UID and cannot be created twice in a certificate. You can create a different UID by changing a single char though (e.g. add a comment). But it is possible to reactivate the old UID. You can delete the signature (i.e. the revocation) and create a new one. The signature is newer than the revocation thus the UID is valid again. Unfortunately you cannot rely on this as the RfC does not enforce using the newest signature but GnuPG behaves this way. If you reactivate a UID then you have the old third party signatures again (if they haven't expired yet). subordinate keys, say for her notebook and mobile phone. That does not make sense, at least not with the current version of OpenPGP. she say that the mobile phone should be able to sign/decrypt only for u...@alice.com? Signing and decrypting are key operations not UID operations. Subkeys belong to a certificate as UIDs do. You cannot enforce an association with a certain UID. It is a bad idea to mix e.g. private and business addresses in the same certificate anyway. That should be done with equal addresses only to (also) avoid such problems. which pubic key does he encrypt the message with? Usually the valid subkey (if there is one) with the newest self- signature. But the RfC does not enforce this. assume the sender, by default, would simulatenously use all encryption keys (master or subordinate) he knows of, so that the message can be decrypted with any one private key. Is that the case? No. Though – again – I think it would not violate the standard. But usually there is only one valid subkey at a time anyway. You can enforce the usage of certain (sub)keys but this is not going to work with current mail clients: gpg --armor -r 0x12345678! -r 0x87654321! --encrypt Can the sender choose to only encrypt using one of the keys, e.g. to make sure Alice doesn't read the message on her phone, This is IMHO an urgently needed feature but not possible (i.e. there is no standard for it) today. I have written a German article about that: http://www.crypto-fuer-alle.de/wishlist/securitylevel/ What happens if a subordinate key of mine expires? Can I just generate a new one and let people know? Or would I also have lost trust/signatures of my identities gathered in the past? You can replace subkeys or extend their validity period. Subkeys and third party signatures are not related (today – one more problem). The signatures are made over the combination of public mainkey and one of the UIDs. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: Seeking clarification with a few GPG concepts
Am Mi 13.08.2014, 12:23:24 schrieb Peter Lebbing: Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I'm pretty sure that, yes, you can. Give it a try... practice, you'll usually see that it will be encrypted to the last created non-expired key. Not the last created but the last self-signed one (may differ e.g. after expiration). Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: Seeking clarification with a few GPG concepts
Thanks for your helpful answers, Hauke and Peter! I have a followup question, if you don't mind: How much history is saved in a gpg key? Say, for example, I have a gpg key with uid1 associated, and I publish that. Then, I add uid2, but before handing out my updated gpg key to anybody, I decide to do things differently, e.g. change the comment or email in uid2, or remove uid2 altogether. Maybe I add a subordinate key only to remove it afterwards, say, because I consider it to be too weak after all. After these operations, I publish my key again. Can other people see the full history of what I did in the meantime, or do they just see what I ended up with? If parts of the history can be retrieved, what would I have to do to see what's saved? Thanks again! On 8/13/2014 at 1:19 PM, Hauke Laging mailinglis...@hauke-laging.de wrote: Am Mi 13.08.2014, 12:23:24 schrieb Peter Lebbing: Can she add a new UID of the same name Alice u...@company.com to her gpg key again? I'm pretty sure that, yes, you can. Give it a try... practice, you'll usually see that it will be encrypted to the last created non-expired key. Not the last created but the last self-signed one (may differ e.g. after expiration). Hauke -- Crypto für alle: http://www.openpgp- schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seeking clarification with a few GPG concepts
On 13/08/14 12:30, Hauke Laging wrote: the same string is the same UID The signature is newer than the revocation thus the UID is valid again. Unfortunately you cannot rely on this as the RfC does not enforce using the newest signature but GnuPG behaves this way. The RFC says very little on a lot of important things. What is the use of not being able to double back on a UID revocation? For key revocations, it's obvious: compromise means an attacker is able to re-enable your key. I don't think there is an analogous UID compromise. So why would an OpenPGP implementation choose to treat a UID revocation as final? Are there any that do? By the way, small correction: The UID is not the packet data in the OpenPGP certificate but the string Alice u...@company.com I take it you refer to the precise form of the data that is signed. In fact, what is signed does have a header, it's not just the bytes from the UID string. The header is somewhat unusual. It is an old-style packet header for packet tag 13 (User ID packet) with a length-of-length 0. It is followed by a 4-octect scalar length and then the UID string. The unusual thing is that length-of-length 0 means a 2-octet length, but in actuality it is a 4-octet length. 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: Seeking clarification with a few GPG concepts
On 13/08/14 12:37, Hauke Laging wrote: Give it a try... OK. $ gpg2 --homedir gpgtest -k DCDFDFA4 pub 1024R/DCDFDFA4 2012-03-17 [expires: 2014-08-15] uid [ full ] Test Teststra test@work.invalid uid [ full ] Test Teststra (Koning van Wezel) test@example.invalid sub 1024R/77A3395A 2012-03-17 Revoking the work UID... ~$ gpg2 --homedir gpgtest --list-options show-unusable-uids -k DCDFDFA4 pub 1024R/DCDFDFA4 2012-03-17 [expires: 2014-08-15] uid [ full ] Test Teststra (Koning van Wezel) test@example.invalid uid [ revoked] Test Teststra test@work.invalid sub 1024R/77A3395A 2012-03-17 Had to add a list-options flag to show it. Re-adding the UID... -8--8- $ gpg2 --edit-key DCDFDFA4 [...] gpg adduid [...] Real name: Test Teststra Email address: test@work.invalid Comment: You selected this USER-ID: Test Teststra test@work.invalid Such a user ID already exists on this key! Change (N)ame, (C)omment, (E)mail or (Q)uit? q -8--8- Okay, the UI doesn't let us do it that easily. Delete that old one. -8--8- gpg uid 2 [...] gpg deluid [...] gpg adduid Real name: Test Teststra Email address: test@work.invalid Comment: You selected this USER-ID: Test Teststra test@work.invalid Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o -8--8- So far so good. I'm redistributing the key to my peer. -8--8- $ gpg2 --export DCDFDFA4|gpg2 --homedir gpgtest --import gpg: key DCDFDFA4: Test Teststra test@work.invalid 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 $ gpg2 --homedir gpgtest --list-options show-unusable-uids -k DCDFDFA4 pub 1024R/DCDFDFA4 2012-03-17 [expires: 2014-08-15] uid [ full ] Test Teststra test@work.invalid uid [ full ] Test Teststra (Koning van Wezel) test@example.invalid sub 1024R/77A3395A 2012-03-17 -8--8- And look, it's back in action. It is precisely as you said, GnuPG does allow reinstigating a revoked UID. However, there is a slight hitch in the UI that means you can't do it completely straight-forwardly. You need to delete the offending UID before re-adding it, but other than that, it works, and the certifications are even carried over. Not the last created but the last self-signed one (may differ e.g. after expiration). Ah, right, thanks for the correction! 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: Seeking clarification with a few GPG concepts
On 13/08/14 13:30, pze...@hushmail.com wrote: How much history is saved in a gpg key? Pretty much everything. You can edit what you give others to your heart's content, but old data will still linger in a lot of places and can recombine with your new data. Keyservers in particular never throw any data out (I think), but only add new data to the existing data. Similarly, unless explicitly instructed, GnuPG will keep old signatures and uid's and stuff around. Can other people see the full history of what I did in the meantime They usually can, especially if the key is on the keyserver network. what would I have to do to see what's saved? The most information is given by a command like: $ gpg2 --export KEYID | gpg2 --list-packets There might be switches to be even more verbose, but this already shows all old signatures and stuff. You might want to import your own key from the keyserver to see anything you have deleted locally. But in general, assume that anything you send out will be uploaded by someone to the keyserver, and stay there indefinitely. 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: Seeking clarification with a few GPG concepts
On 13/08/14 14:22, Peter Lebbing wrote: Okay, the UI doesn't let us do it that easily. Delete that old one. Alternatively, delete only the revocation signature and the self-signature using delsig and resign using sign. That way, you keep certifications in your local copy. The delsig interface can be a pain with many signatures, so more straightforward is to do an --export before you delete and re-add the UID, and an --import afterwards. 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: Seeking clarification with a few GPG concepts
Hi, and thanks again for your answer. I have the feeling I may have formulated my question badly. I do know that data that has been out in the open cannot be made forgotten. What I wanted to ask was this, basically: Assume I generate a completely new gpg key and play around with it. Say I add some UIDs and some subordinate keys, and then remove a subset of those. Only after having done all this, I upload this key's public info, for the first time, to a keyserver and tell you about it. Could you now, from this one snapshot, tell which UIDs and subkeys I added and then deleted again? I tried playing with list-packets and pgpdump, and to me it looks like no such information is available, but then again, I'm not familiar with the inner workings of gpg. Thanks! On 8/13/2014 at 2:30 PM, Peter Lebbing pe...@digitalbrains.com wrote: On 13/08/14 13:30, pze...@hushmail.com wrote: How much history is saved in a gpg key? Pretty much everything. You can edit what you give others to your heart's content, but old data will still linger in a lot of places and can recombine with your new data. Keyservers in particular never throw any data out (I think), but only add new data to the existing data. Similarly, unless explicitly instructed, GnuPG will keep old signatures and uid's and stuff around. Can other people see the full history of what I did in the meantime They usually can, especially if the key is on the keyserver network. what would I have to do to see what's saved? The most information is given by a command like: $ gpg2 --export KEYID | gpg2 --list-packets There might be switches to be even more verbose, but this already shows all old signatures and stuff. You might want to import your own key from the keyserver to see anything you have deleted locally. But in general, assume that anything you send out will be uploaded by someone to the keyserver, and stay there indefinitely. 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: Gnupg-users Digest, Vol 131, Issue 15
On 8/13/2014 4:38 AM, Michael Anders wrote: Baltimore published: Fort Meade is actually closer to Laurel than it is to Baltimore. (http://www.nsa.gov/business/programs/elliptic_curve.shtml) symm. RSA ECC 801024160 112 2048224 128 3072256 192 7680384 256 15360 521 Which shouldn't be any surprise, since NIST collaborates with them on determining these numbers. You'll notice that they exactly match NIST's recommendations, except that NIST doesn't list a 192-bit entry. Also, I think your 521 is actually 512. :) The generalized number field sieve(-RSA factoring) scales with bitlength to the 1/3 Nope. That's the computational complexity in a computational-theory sense, not the complexity in a cryptanalytic sense. Be real careful about thinking the two of them are connected; they're probably not. If it scaled with bit length to the 1/3 power, and if a 3072-bit RSA key corresponds to 128 shannons of entropy, a 15360-bit RSA key would only have 211 shannons -- not 256. Coming up with these tables is black magic at the best of times. For that reason, I hope you'll understand if I choose to rely on NIST rather than your numbers. :) smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seeking clarification with a few GPG concepts
Am Mi 13.08.2014, 14:54:40 schrieb pze...@hushmail.com: Say I add some UIDs and some subordinate keys, and then remove a subset of those. Only after having done all this, I upload this key's public info, for the first time, to a keyserver and tell you about it. Could you now, from this one snapshot, tell which UIDs and subkeys I added and then deleted again? No. -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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
James Mickens on security
Microsoft Research's James Mickens wrote several humorous columns for USENIX in which he interspersed brilliant insights with side-splitting humor. I just found his This World We Live In, which has a good bit about PGP in it. You can find his original at: http://research.microsoft.com/en-us/people/mickens/thisworldofours.pdf [C]onstructing a public-key infrastructure is incredibly difficult in practice. When someone says 'assume that a public-key cryptosystem exists,' this is roughly equivalent to saying 'assume that you could clone dinosaurs, and that you could fill a park with these dinosaurs, and that you could get a ticket to this Jurassic Park, and that you could stroll throughout this park without getting eaten, clawed, or otherwise quantum entangled with a macroscopic dinosaur particle.' With public-key cryptography there's a horrible, fundamental challenge of finding somebody, *anybody*, to establish and maintain the infrastructure. For example, you could enlist a well-known technology company to do it, but this would offend the refined aesthetics of the vaguely Marxist but comfortably bourgeoisie hacker community who wants everything to be decentralized and who non-ironically believes that Tor is used for things besides drug deals and kidnapping plots. Alternatively, the public-key infrastructure could use a decentralized 'web of trust' model; in this architecture, individuals make their own keys and certify the keys of trusted associated, creating chains of attestation. 'Chains of Attestation' is a great name for a heavy metal band, but it is less practical in the real, non-Ozzy Osbourne-based world, since I don't just need a chain of attestation between me and some unknown, filthy stranger -- I also need a chain of attestation *for each link in that chain*. This recursive attestation eventually leads to fractals and H.P. Lovecraft-style madness. Web-of-trust cryptosystems also result in the generation of emails with incredibly short bodies (e.g., 'R U gonna be at the gym 2nite?!?!?!?') and multi-kilobyte PGP key attachments, leading to a packet framing overhead of 98.5%. PGP enthusiasts are like your friend with the ethno-literature degree whose multi-paragraph email signature has fourteen Buddhist quotes about wisdom and mankind's relationship to trees. It's like, I GET IT. You care deeply about the things that you care about. Please leave me alone so that I can ponder the inevitability of death. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Gnupg-users Digest, Vol 131, Issue 15
Hi Robert, You are both correct. The hash strength=512 curve is called P-521. Thanks, Bob Cavanaugh -Original Message- From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Robert J. Hansen Sent: Wednesday, August 13, 2014 6:08 AM To: gnupg-users@gnupg.org Subject: Re: Gnupg-users Digest, Vol 131, Issue 15 On 8/13/2014 4:38 AM, Michael Anders wrote: Baltimore published: Fort Meade is actually closer to Laurel than it is to Baltimore. (http://www.nsa.gov/business/programs/elliptic_curve.shtml) symm. RSA ECC 801024160 112 2048224 128 3072256 192 7680384 256 15360 521 Which shouldn't be any surprise, since NIST collaborates with them on determining these numbers. You'll notice that they exactly match NIST's recommendations, except that NIST doesn't list a 192-bit entry. Also, I think your 521 is actually 512. :) The generalized number field sieve(-RSA factoring) scales with bitlength to the 1/3 Nope. That's the computational complexity in a computational-theory sense, not the complexity in a cryptanalytic sense. Be real careful about thinking the two of them are connected; they're probably not. If it scaled with bit length to the 1/3 power, and if a 3072-bit RSA key corresponds to 128 shannons of entropy, a 15360-bit RSA key would only have 211 shannons -- not 256. Coming up with these tables is black magic at the best of times. For that reason, I hope you'll understand if I choose to rely on NIST rather than your numbers. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Back to normal now
Hauke, Yesterday whilst figuring out what to do, I found that I was logged out - my Linux box refused to accept my password. Anyway having copied the contents of my home directory - I reinstalled LXDE. Then slowly configured. I installed gpg2 - created the directory and associated files and then copied over my files. All works perfectly now - thanks to being locked out!! David -- “See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com 0x8716853A.asc Description: application/pgp-keys ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: FAQ change, final draft
Hi Robert, This looks great. One very minor point (possibly not germane, please comment): Are you discussing the reliability of the NIST P curves for ECC? What is GPG planning as the default curves? NIST, Brainpool or ? Thanks, Bob Cavanaugh -Original Message- From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Robert J. Hansen Sent: Monday, August 11, 2014 10:19 AM To: gnupg-users@gnupg.org Subject: FAQ change, final draft A few weeks ago on -devel I made a proposal for a FAQ change. So far I've received feedback from three people, all of it fairly positive, all suggesting mild changes. The following represents a final draft, which I'm now presenting on -users to get the most visibility/feedback. If the community approves, I'll be submitting this to Werner for inclusion into the FAQ. = Q: Why does GnuPG default to 2048-bit RSA? A: At the time the decision was made, 2048-bit RSA was thought to provide reasonable security for the next decade or more while still being compatible with the overwhelming majority of the OpenPGP ecosystem. Q: Is that still the case? A: Largely, yes. According to NIST Special Publication 800-57, published in July 2012, 2048-bit RSA is believed safe until 2030. At present, no reputable cryptographer or research group has cast doubt on the safety of RSA-2048. That said, many are suggesting shifting to larger keys, and GnuPG will be making such a shift in the near future. Q: What do other groups have to say about 2048-bit RSA? A: In 2014, the German Bundesnetzagentur fuer Elektrizitaet, Gas, Telekommunikation, Post und Eisenbahnen recommended using RSA-2048 for long-term security in electronic signatures. In 2012, ECRYPT-II published their Yearly Report on Algorithms and Keysizes wherein they expressed their belief RSA-1776 will suffice until at least 2020, and RSA-2432 until 2030. In 2010, France's Agence Nationale de la Securite des Systems d'Information stated they had confidence in RSA-2048 until at least 2020. Q: Is there a general recommendation that 3072-bit keys be used for new applications? A: No, although some respected people and groups within the cryptographic community have made such recommendations. Some even recommend 4096-bit keys. Q: Will GnuPG ever support RSA-3072 or RSA-4096 by default? A: Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we'd like to see it deployed as soon as humanly possible. Q: I think I need larger key sizes. A: By all means, feel free to generate certificates with larger keys. GnuPG supports up to 4096-bit keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ change, final draft
Hi Robert, This looks great. One very minor point (possibly not germane, please comment): Are you discussing the reliability of the NIST P curves for ECC? No, because that's the first time anyone's asked that question on the list -- so it's not a frequently asked question. :) What is GPG planning as the default curves? NIST, Brainpool or ? Beats me, you'd have to ask Werner, I have no involvement with the code, and I can't even tell you which curves I'd personally recommend. Due to my father being a U.S. federal judge, I think a lot of the GnuPG community would react very badly to me ever touching the GnuPG code. In deference to their wishes, I limit myself to maintaining the FAQ and answering routine questions. Which curves will we use and why? is not within my remit. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Back to normal now
You could have just booted in from the lxde DVD and reset your password... On Aug 13, 2014 11:22 AM, da...@gbenet.com da...@gbenet.com wrote: Hauke, Yesterday whilst figuring out what to do, I found that I was logged out - my Linux box refused to accept my password. Anyway having copied the contents of my home directory - I reinstalled LXDE. Then slowly configured. I installed gpg2 - created the directory and associated files and then copied over my files. All works perfectly now - thanks to being locked out!! David -- “See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ change, final draft
On Wed, 13 Aug 2014 19:46, robe...@broadcom.com said: This looks great. One very minor point (possibly not germane, please comment): Are you discussing the reliability of the NIST P curves for ECC? What is GPG planning as the default curves? NIST, Brainpool or ? For signing Ed25519 which used the EdDSA algorithm (a Schnorr signature variant). For encryption most likely plain Curve25519. But it is not yet defined by OpenPGP. Salam-Shalom, 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: Seeking clarification with a few GPG concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 13 August 2014 at 1:45:20 PM, in mid:53eb5de0.20...@digitalbrains.com, Peter Lebbing wrote: On 13/08/14 14:22, Peter Lebbing wrote: Okay, the UI doesn't let us do it that easily. Delete that old one. Alternatively, delete only the revocation signature and the self-signature using delsig and resign using sign. That way, you keep certifications in your local copy. The delsig interface can be a pain with many signatures, so more straightforward is to do an --export before you delete and re-add the UID, and an --import afterwards. Won't a simple setpref do the trick? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Can you imagine a world with no hypothetical situations? -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlPr2aVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5px08EAKVlpSQUo6/WcZ19GEvkh+S0D/KIk5OatbTR lxGWYtX/Oqsk9yHPkQjre6qHkAjVxnEchI4Cnio2oh6zuvDx/PTo7JjN4TGDuKws VK6SjIs3vHpf+Ly/y7A/qDCHVSIy9UW4NBOCBTtI7OYoNs0YgTcoxPJ1KFTyHLaY LHkcQJQK =uLeU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.gnupg.net - Refresh all public keys never completes in Enigmail, some servers down?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/12/2014 09:21 PM, OmegaPhil wrote: Please CC me in etc, I'm not subscribed to the list. Haven't been able to 'refresh all public keys' on keys.gnupg.net in Enigmail for a while now (only have two keys), so I had a look at the servers responsible (host keys.gnupg.net) - the following appear to be bad for me accessing from the UK: 131.155.141.70: No response to pings 63.230.134.161: Destination Host Unreachable 173.175.198.28: No response to pings Using ping is not a reliable way to check availability, the icmp protocol is often blocked by the firewall, you should do a HTTP get request. As for your issues, try using --keyserver hkp://p80.pool.sks-keyservers.net:80 to rule out any firewall blocking 11371 etc. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - The best way to predict the future is to invent it (Alan Kay) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT69TnAAoJEPw7F94F4TagkhsQAIziYE9wRai+hAB92eDBAQPQ I1JQYOK5UB/4UWHRp30/nZUBo2u5c8sm8YTe3GrH5Xqxsuw7IUmFv3QADmP0Kz7O PkRgjKm/g1/6svpQxDX1ujVJHqZpUS54FcZKldUiUAdjletJlFF38GZ9KyQPc2Mo RSK++85tyt+eWv/8SzCLPhC7TLEpucFCTDK/o0QAGRAPX5U+PSxG46wSWJYIh7Jy 7vrIvYsjilDjVRpw4ic4+R/pWtlg70Y8P5mhQ8sYcU8tbVrFePCphhLrn1qxi/Em C/gLfbEHdtuzreMumHUCEFhSB0hRcEy3aNQ+S2iNtNLVUrpvF2SxNyIcTWZCi9yb XmoforaqQmxEPOIgTxgV0TXcsJmbLIaOR4pEvDa7jstLWzcEG6ES2d1KlDiZrW5o BoGi3dIzYWH4ngO1fRR2Cd6Gg5yB/2kVIRgNtB/MBSGR8nqehbszqmswNamU/tr/ rJq2o9it2g7EzK2i84zlUxZMA1WQuPR2pJ5fiWGHNayw7h2GfL8p7/oZyI4JuS8L drNYisat4x88Jf9jXdI/+/+0Dm+vB8y3fSFyBM0EtqTO1Bn/6WUoHcd+uFVhysTw rQM956RuwOIMwBnzXGvZA2AnD/Q3YKIHs1rCMwWwj2EgRmrMur/L4TflEW7d6dyb rez0qCQRoO6LyS6uN/y6 =6cLs -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seeking clarification with a few GPG concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 13 August 2014 at 11:30:00 AM, in mid:1548063.zPPlaFDMEL@inno, Hauke Laging wrote: i.e. the same string is the same UID and cannot be created twice in a certificate. Interesting. When I tested, GnuPG allowed me to add another UID with exactly the same string. When viewed in a GUI key manager or via gpg - -listkeys 0x, I could see two UIDs with the same string, but only until I edited the key again. Subkeys and third party signatures are not related (today – one more problem). Why is that a problem? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net During an eruption - move away from the volcano - not towards it -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlPr3BNXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pHd8EAK8SEyqxplRG2t+7W7ycMtDZTKRfX14MKJSB g3430NUEvjoaGYl72jo22hmPZzGpJx0SFln2onxPSsE7JEmadaK0Qigu5Wtaou0t MiA4P6TtqoLYqRFUUgRogB8HR/2R60P9gmRSdaUejavwFErgpMIAFU/V3q2UuEwn EVpachpC =r31a -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seeking clarification with a few GPG concepts
Am Mi 13.08.2014, 22:43:41 schrieb MFPA: Subkeys and third party signatures are not related (today – one more problem). Why is that a problem? Because of that OpenPGP (at least in a useful form) is not compatible with (probably not only) German signature law. I know that this will be replaced by new EU law in a few years but I don't know whether that makes any change to the current requirement that the key which has a qualified certificate must be stored on a smartcard (i.e. inaccessible even to the key owner). This problem could be solved by adding a critical signature notation which contains the fingerprint(s) of the key(s) which the CA has created on a smartcard. That way the key owner could create new subkeys which would not be recognized as part of a qualified certificate. If you want to use OpenPGP today then the CA would have to create the private mainkey for you and throw it away after signing the subkeys. That would render OpenPGP quite useless. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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
HP-UX and GnuPG
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? ~ Bill ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ change, final draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 13.08.2014 um 20:43 schrieb Robert J. Hansen: Hi Robert, This looks great. One very minor point (possibly not germane, please comment): Are you discussing the reliability of the NIST P curves for ECC? No, because that's the first time anyone's asked that question on the list -- so it's not a frequently asked question. :) To bad, I was about to suggest to adept some of these questions* to the elliptic curve cryptography and answer them if possible or at least state that an answer is not possible at this time. Because they probably will become frequently asked questions in the future**. ;) But I can understand if that is going to be dealt with, when we are at that point in time. regards Martin * What will be a good default key length and why e.g. ** maybe true for some of the other questions already in the FAQ as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEAREKAAYFAlPr1xEACgkQ/6vdZgk46sj0xwCgutbhFXSHpZZg3uu6yFQ5EV4j L/4AnjYmvhzbCv4mqTB7IuLU8mqy9gRH =SsU4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ change, final draft
On 8/13/2014 5:22 PM, Martin Behrendt wrote: Because they probably will become frequently asked questions in the future. The questions experts think will be frequently asked are usually rarely asked. :) smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: what is correct for users' Preferred keyserver ?
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. There is no good reason to use this option, and the public key servers are vastly preferable in any case. Doug ___ 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
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. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
