Re: GPG's vulnerability to quantum cryptography
On Sun, Jul 06, 2014 at 12:53:26PM +0100, MFPA wrote: At the same time, would you advocate decrypting all your encrypted files and encrypting them to the new key? Or were you just referring to encrypted communications? It depends on how important the data is. Of course, if the data is so important, when the expiration time comes, all the data encrypted with the old key need to be decrypted and encrypted with the new generated key. Although it's not truly necessary to do this work when the data is no longer considered as important. For encrypted communication, it's better to use the new generated key when the expiration time comes. I don't enforce my idea to be applied by everyone. This is an advice for myself to do a good gpg practice. Someone may refer to a key revocation rather than enforcing an expiration time. That's also good practice. I believe everyone of you has a method to prevent quantum cryptodecryption on your public keys. pgpPmL4nIesuE.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smart card reader security
Hello Christian I bought a cyberJack go [1] to use it with my openPGP smart card for authentification. Since the firmware of that device is upgradeable and is capable of saving atleast 2 GB of data, how can I be sure it is not a security threat by saving sensitive data? May be done an encrypted partition on it. Best Regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On Sun, Jul 06, 2014 at 07:35:05PM +0200, gnupg-users-requ...@gnupg.org wrote: On 06-07-2014 9:36, The Fuzzy Whirlpool Thunderstorm wrote: Using GPG encryption is still good, although it's vulnerable to quantum cryptodecryption. It's a good idea to set an expiration for each of your GPG key. So that, when the expiration time comes, you'll be able to generate a new GPG key to address a possibility of your old keys being cracked. I don't see the relation between these two. You don't know when quantum computers who can break 1024 RSA will be a reality so when should you set the expiration date? And you can always revoke a key if something like this happens, no need for expiration dates there either. Since I don't know when I will consider a key compromised or weak, I don't work with expiry dates but revoke the key in such a case. This is also a good practice. Revoking a key which is suspected to be compromised seems a good gpg practice. Because we don't know when quantum computing will be ready to use. Maybe 50 years later, or maybe 10 years later? Just find out how Intel is shrinking miroprocessor die size every year. Quantum computing is still long way to go. For now, as long as we stick to good gpg practice, no need to worry of compromised keys. GPG is not perfect. It's just pretty good as the name suggest. At least, it'll be able to protect your secured data for the rest of your life or for the time specified at the expiration date. If a key expires data will not be automatically decrypted. Nor will it become unusable. I know that when the expiration time comes, the data will not be automatically decrypted. pgpk7c9ZD7fLa.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On 06/07/14 16:25, Johan Wevers wrote: I don't see the relation between these two. I agree. This conversation is still a mystery to me. The Fuzzy Whirlpool Thunderstorm, it seems to me you advocate revoking an encryption key, or letting it expire, when you suspect the key could be cracked by an adversary. This does not help at all for anything already encrypted to that key, it only prevents people (who have fetched the revocation) to encrypt any new data to that key. Any old data can still be decrypted by your adversary, who has computed your private key. The method works reasonably well for signature keys, apart from the fact that your adversary can still fake a signature in the past, when your signature key was still valid. Also, your correspondents still need to fetch the revocation before they realise new signatures are invalid. Could you explain what you mean? I'm really getting the impression we're talking about cracking an encryption key, and I don't see how revoking such a key would help significantly for that. 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
ECC and CMS (Re: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing)
On Thursday 03 July 2014 at 12:05:07, Werner Koch wrote: I just released the fifth *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out new features and to fix the bugs in the last beta. Congratulations on the new beta! About th ECC support in GnuPG 2.1: Does this work with OpenPGP and CMS? With the same algorithms? Best, Bernhard -- www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner 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: ECC and CMS (Re: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/07/2014 04:01 PM, Bernhard Reiter wrote: On Thursday 03 July 2014 at 12:05:07, Werner Koch wrote: I just released the fifth *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out new features and to fix the bugs in the last beta. Congratulations on the new beta! About th ECC support in GnuPG 2.1: Does this work with OpenPGP and CMS? ECC support for OpenPGP is defined in RFC6637[0] With the same algorithms? Only the NIST P-curves are currently defined for OpenPGP although some serpent and brainpool curves also works using the basic framework of RFC6637 - these are also included in SKS. See e.g. [1] for discussion on Ed25519 that is currently implemented in GnuPG 2.1 but does not yet have an RFC. References: [0] http://tools.ietf.org/html/rfc6637 [1] http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Docendo discimus We learn by teaching -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTuqnJAAoJEPw7F94F4Tagz3AP/2dlnuXLFFiRe4x88uwQda8n 293pqKs+O+7lu7P+SlQbrckGyDSqydl4r0PMeXj5eImwKFPbIPqmw1pOcmf5TpEs 65W6/dfq4jiXgc+qV+YiH0lJ7ER870uRrxBKJDKc98dmH/kAZWobgRrWHgqx+nNN LVW7UToosG2Z9hfAjvQlSXM1Ba9bcFgmnWsseYX9gpFFSY8+qATrvWHbv+TYUr3g wClqd/KbQ4lB25qRhHydA2GxQSG5uhgKAwItIe42IGp6htBKsaXGE0nbegSXa8Ng m01Xv/H/w3OlIOnRhKl5NwR36CO5QTXkFnix7lzxpWzn9Lx9qandL+n5iWvNKHF9 pF/n7rjuJ8jG8T0WdIUmHGJ4kkm0qI5efOGHLtF+5wzyLLezH0c8Ev7nls9OOp1c vLXcXW1ttq7+g85+TYAzAHn4e7SU3mhFL7RC5m1mXcbtktWFxP4RBXsOtUxF9m0Z 5d/Q1X6nEeJ34+JYGBytQWt0UYj/C4NAmA6SyLFpfbvFB867dQgH/al50NGVvryI TgYgNQnspkZ+MbEO0bPQBWulo7QYNVIqy3Vf2jPk4F3r3wN5EEJtBvBC5HVMhKgA B8n9yE+o4QfvS6CA4E5cC+Ivi0Q6i2WfBQJQSDBIUih0B34LvmTwWSu/vreLUgTY 8zfmZAFg+nAODmUn2gp6 =kAPT -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encrypt a signed text
On 7/7/2014 at 10:42 AM, Walter Lange tr...@gmx.org wrote: I would like to encrypt a signed (with ASCII armor) text. It should take two steps, because I want to use two different machines, a local one to sign and a remote machine which encrypts. The result should be the same as the encrypted and signed one in one step. Is that possible? = Not the way you want it. It will have the same end result, in that the signature can be verified, on the same text, and the decryption will show the text and verify the signature, But in the case where it is a one step process, the decrypted plaintext will not have the signature as part of the text. The other way is possible. It is possible to encrypt and sign as one step, and then armor the signature and attach it to the decrypted plaintext to make it look like it was first clearsigned, or armored signed, and then encrypted. The problem with doing it the way you want, is that while it is possible to remove the signature and save it as a detached signature, it is not (afaik) possible to bind that detached signature to the plaintext and have it encrypted as one process. I would need to be zipped together or otherwise connected first. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
secret key vs pubblic key
Hi. I once encountered the following situation. One of my contacts did send his/her private key on the public key server. Claiming that this was his/her public key. Funnily enough I did import that key and did not get aware it was a secret key. And as far as I remember it worked to decrypt her messages. First question: was this possible because you can decrypt messages from a counterpart also with his/her private key (having it imported from a key server) using your private key? Or (I do sincerely not remember) did s(he) send me the public key separately maybe and this is why I was able to decrypt) Kgpg has a very strange policy in communicating the import of a key. It always speaks of secret key imported whether this is a public or private key At least in opensuse when you do export your public key and export your secret key both will have the same aspect AFAIC (name.asc). Is this intentional and could this be changed to make things like this happen less? (Note: more people will use encryption so the level of knowledge of the program is to be expected to lower not to get higher at least statistically. It is true that in the most recent version of kgpg this has changed and a dialogue should make people understand they are exporting a private key (at least when exporting to a file, however, I do not know if this warning happens also when people export to a key-server). That brings me to this question: is there a way, once I have to keys let us say Paul.asc a public one and Paul.asc a private one that should not have been exported, to understand immediately what kind of key is this. What would be the command on the command line? Last question: why a does a key server for public keys accept private keys anyway? Isn't there a way in the infrastructure to block those errors from the very origin? Thank, you. --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On July 6, 2014 4:40:13 PM PDT, MFPA 2014-667rhzu3dc-lists-gro...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 6 July 2014 at 3:25:57 PM, in mid:53b95c75.5030...@vulcan.xs4all.nl, Johan Wevers wrote: Since I don't know when I will consider a key compromised or weak, I don't work with expiry dates but revoke the key in such a case. I don't know quite what /The Fuzzy Whirlpool Thunderstorm/ had in mind, but I would say setting expiry dates can maybe act as a reminder to consider such matters from time to time. Of course, it could just come around when you are too busy to consider any such thing, so you blindly extend the expiry date anyway. Or you set them too short, so extending becomes run-of-the-mill. Uh, yeah. That can happen. I will not say that I did that once upon a time but ... :-) Cheers, -Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On 07-07-2014 10:09, The Fuzzy Whirlpool Thunderstorm wrote: It depends on how important the data is. Of course, if the data is so important, when the expiration time comes, all the data encrypted with the old key need to be decrypted and encrypted with the new generated key. However, if your communication lines are bugged the attacker already has the data encrypted with the old key. This is only valid if cold storage data is at risk. In such cases an encrypted disk using some symmetric algorithm that is likely not vulnerable to quantum computers is a safer option. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
one key/pair for multiple email accounts
in practice, do users of gnupg find that having multiple email account id's added to one key/pair using that key/pair to sign and/or encrypt emails files more efficient to manage? i have mulitple email accounts and in the past had generated a key/pair for each, each with its own unique passphrase. i'm rethinking that approach. curious how other uses in this situation manage their gnupg? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On Sun, Jul 06, 2014 at 12:21:13PM -0400, Robert J. Hansen wrote: On 7/6/2014 3:36 AM, The Fuzzy Whirlpool Thunderstorm wrote: Using GPG encryption is still good, although it's vulnerable to quantum cryptodecryption. In point of fact, we don't know this. Theoretically, science-fiction level breakthroughs in quantum computation would break RSA. But the problem with theory is some of the things that theory permits turn out to be impossible in reality. For instance, there's nothing in the laws of physics that prohibit things from having negative mass, but we've never encountered negative-mass material anywhere: not in the lab, not in the world, not in deep space, not anywhere. Wasn't there an experiment running, one or two years ago, about trying to make anti-electrons anti-gravitate? I don't remember of having read any result, though... It's good to be skeptical of quantum computation. It's interesting to read up on, but be immensely skeptical of all predictions. Weren't you the one who preached to assume the worst? It seems rather reasonable to assume that somewhere in the future quantum cryptography (or any other kind or huge advance in science) will break whatever cipher we are currently using... after all, vigenere-like ciphers are almost ridiculous nowadays, while they were once state-of-the-art. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On 7/7/2014 5:52 PM, Leo Gaspard wrote: Wasn't there an experiment running, one or two years ago, about trying to make anti-electrons anti-gravitate? I don't remember of having read any result, though... It's been done a few times but without results, which is unsurprising: on an atomic level gravity is ridiculously weak. It's still being researched. Smart money is that antimatter has a gravitic attraction just like regular matter: if it doesn't, a whole lot of our commonsense notions of reality have to get thrown out. Weren't you the one who preached to assume the worst? Yes, but there's a big difference between saying it is possible that RSA will be susceptible to quantum computation in the near future, so let's account for that in our threat model, and saying, RSA is susceptible to quantum attacks. Reality should always be described as accurately as possible. Threat models should be constructed under a pessimistic interpretation of that accurately-stated reality. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Greetings everybody, new user here
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone. I just signed up to this list and thought to introduce myself. I've been aware of gpg for a long time, but seldom have I had occasion to actually use it. Well, now I do, so I'm all signed up and introducing myself. As you can probably see, my name is Christ. I work in the web development industry and have ties to the security sector. Surprising as it is, most people I communicate with simply don't use GPG, so I've never had occasion to use it beyond the occasional verification of a package or download. Well, now I have my own key, 389B07F6, published to the local keyservers, and I joined the list. I have a few minor issues I'll post about separately as occasion arises. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTu15mAAoJEFiHuRCpy1pBNrIIANJnpETE/AtFGJyzeFEcvvD/ CwBC7clA6Wl2SkqSTU8sV140YwtcmDhWoFDG1qav5hCUjqwOyxX/yprwBoj12T+I egghupb2pQHPOW2ZzDL83w2hZuk/uQcqQ0+TxUDQAR8dD1jxM7rc2Ew1pc7sje8Z yEN3TXlvFynL++CeFBy/eVXVhhymDF+NKWnHjsrE8zGBXdg5527fZOyxOegmSzHV AH6aAXl83USBQyJZafo2+s4TR1ijOWxB6cNVx+Di9RpROJsOeN3gyf1g7lBsgG5i zrTfjnlEJYZJ7ZB6d08cL/zlx5rv2Tt88/zGX2GyvCLlPYZteDXG0t9eSNsSj4o= =zVNz -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Key server long propagation delays?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was recently setting up my new keys along with some other people, and I discovered that as soon as one of my cohorts sent their keys and recieved confirmation, I could retrieve the keys and they showed up. When I sent stuff to the key servers, however, they couldn't retrieve them for upwards of several minutes. Later in the evening, we both sent each other's signed certificates back to the key servers, and that propagation delay was several HOURS in duration. We made sure to both send to the same key servers, and we tried multiple different keyservers, but ultimately the only solution was to wait. Furthermore, I failed in attempts to google this problem, and couldn't find any documentation on key server change propagation delays. I wanted to know if what we've observed is Normal, and if so, if there's any way we can reduce the time it takes our keys to be visible to each other. Thanks in advance! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTu1+fAAoJEFiHuRCpy1pB6CYH/iYgqoJqNwV+nsLdUNX+OT5c i9fKkkkDcigmHAIOONyed4MCTyyAs2GWwwIoMyNSc3jA4SnSun7qL+jZ/ujsppzL z9mGwEHbe7DmO2GcWUNfX9cW014tRB1wnBQ1k4Z9jvEiGXHR1vDr/wx4MFitwDr6 hkjIqpizLE1xbh4JuSX70ESMlSyLE3fk+cqs10lD1KOGKizlLEoR1QZ9zs1YmLQR MxZQGFhJjruO+z3gpT+xnr6GoamkgWXgiORec9b0mnG6du6ioGX+mvRv38pC6PYE M5qOAolcOFOLN8+K1/ZAR/9uVdJiKpFKO8UCIlCLwbGa9AVRGOuh4NrViWkqbmQ= =a6pQ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Greetings everybody, new user here
Hi everyone. I just signed up to this list and thought to introduce myself. Welcome to the community! We're a pretty friendly bunch here. Hasn't been any blood drawn in quite a while, honestly. :) With respect to delays in the keyserver network, the major address that people tend to use (pool.sks-keyservers.net) is not a single box but a confederation of them. It's sort of like how when you visit google.com you're visiting one of thousands of boxes configured to respond to that address. If by some chance you and your correspondent happen to hit the exact same keyserver the propagation delay will be measured in milliseconds. Otherwise the certificate has to be propagated from one machine's database to another. This process, while normally very quick (sub-minute), sometimes has problems. Imagine there's Box A and Box B and then the Big Cloud of Boxes that represents the keyserver network. A gets all its updates from B, and B gets its updates from the Big Cloud of Boxes. If for some reason the network link from A to B goes down, A will fall behind B (and the rest of the Big Cloud of Boxes) in synchronization. The good news is that most of the time propagation speed is extremely fast. Network problems do occur, but generally they're not significant enough to be a major worry. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
