Re: s2k-cipher-mode default
Let's consider an adversary that can store as many OpenPGP-encrypted messages as it has access to. Maybe it sniffs SMTP traffic as well? If the attacker is interested in breaking the crypto of any *one* of these messages, it can reduce the amount of work it has to do significantly. I think this is a pretty unrealistic thought experiment. It requires two conditions to be met: 1. A very large number of intercepted OpenPGP messages 2. An extremely well-funded adversary who only needs to break one message, chosen at random, out of the very large ingestion set, in order for the entire endeavor to be considered a ringing success that justifies the billions of dollars spent collecting #1 We don't have #1, but in the (oft-forlorn) hope we'll see more OpenPGP adoption I'll give it to you. But #2 isn't the description of any real-world organization I've ever heard of. Honestly, it sounds more like a James Bond-style evil organization like SPECTRE or QUANTUM than like anything that exists in the world. (Quoting you quoting djb) There are standard attacks that break _all_ of 2^50 AES-128 keys using a _total_ of 2^128 easy computations. In other words, the likelihood of choosing one of the weak set by random is 10**-53. That's a one-in- 100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 chance. I'll take those odds. Happily. Twice on a Sunday. (Still quoting you quoting djb) Even worse, there are standard attacks that find _at least one_ of the keys using just 2^78 easy computations, a feasible computation today. So there's a 10**-88 chance that one of my keys can be broken in 10**53 computations? Sign me up. I have a lot of respect for djb, but on this one he's just way off in left field. Of course, there aren't 2^50 AES-128-encrypted known-plaintext OpenPGP messages today that such an attack would work on. but why would we want to leave users open to this? (Meant as humor, not snark:) I am much more concerned with the possibility of landing a hot date with Claudia Schiffer[*], which is rudely interrupted by the eruption of the Yellowstone Caldera that wipes out all life in North America, than I am with any AES-128 weakness. Landing a hot date with Claudia Schiffer and the end of the world happening before I pick her up for our night out is considerably more likely to happen. It would also probably make me considerably unhappier than a random AES key, somewhere, being broken. Given I've spent about half an hour of my time calmly considering the possibilities of your hypothetical, perhaps I might trouble you to spend a minute or two coming up with a plan for how I might enjoy an evening with Claudia even as the world ends? I will understand if your reaction is hysterical laughter. :) [*] You youngsters who have no idea who Claudia Schiffer is... when I was your age, she was The Awesomeness. Had a soft spot for her in my heart for about the last twenty-five years. smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: s2k-cipher-mode default
To be clear, it's not one of my keys in the asymmetric key sense, where you, rjh, have only a handful over your lifetime. Every time you send an encrypted message, GnuPG generates a new AES key to encrypt that message with. So one of my messages' keys is more accurate. Yes, I understood that. I think maybe you're misunderstanding: if it was a case of my asymmetric key being compromised, I'd take it more seriously. (Not much more seriously: it's still far out there.) If an asymmetric key is compromised then past and future traffic gets revealed, people can forge new signatures, the WoT can be abused and misused... it gets very nasty very quickly. But looking through my sent-mail folder, the last encrypted email I sent was to a friend offering to buy him a drink when we met up at a science fiction convention in Baltimore. The likelihood of a compromised asymmetric key leading to terrible consequences is high. The likelihood of a compromised symmetric key leading to terrible consequences... not so much. If someone breaks my RSA key I'm going to be extraordinarily upset. If someone learns I offered to buy a friend a drink in Baltimore, I'm going to be annoyed. I'm just fine with the per-message risk. And (sorry Rob) i don't care only about your keys (or your messages' keys). I care about all the messages ever generated by GnuPG. If an attacker can do 2^78 computations, I'd prefer it if they couldn't break even one of the messages ever created by GnuPG. Daniel, seriously: sit down and run the math. If you don't have a copy of Mathematica handy, Wolfram Alpha can do the arbitrary-precision math needed so you can be sure I'm not misleading you. Each message has a 10**-53 chance of being part of the weak set. The likelihood of a message being part of the strong set is (1 - 10**-53). Raise that to a power N and you get the probability of *all* keys being part of the strong set. Here's the takeaway: after 10^50 keys there's still a 99.9% chance all the keys are strong. [Note for UK/European readers: 'million' here denotes an American million: 1,000,000.] Do you think GnuPG will ever generate 10^50 keys? I certainly don't. Assuming there are a million GnuPG installations generating a million AES-128 keys a second, running continuously, that's only about 10^19 keys per year. You'd have to run these million machines for substantially longer than the lifetime of the universe to even have a statistically significant chance of generating a weak key. At this point the conversation is bikeshedding. IMO, there's absolutely no reason to think your scenario is likely, and many reasons to think it's not. 1. We can't generate 10^50 messages. 2. An adversary can't store 10^50 messages. 3. An adversary who has 10^50 messages will not be satisfied with a 0.1% chance of breaking just one of them. djb is a smart guy and I have no doubt that what he's talking about is real. It's also such an incredibly theoretical attack that it really doesn't deserve to be brought up in a conversation about real-world cryptography. Given this, I would feel much better if Werner were to spend his time reviewing the code for exploitable bugs than spending even five minutes changing the s2k default from AES-128 to AES-256. The five minutes spent reviewing code stand a very small chance of discovering something exploitable -- call it one in a billion -- but that's still so much more productive a use of time than using those same five minutes to defend against an attack of such vanishing small probability that we have to break out Mathematica to talk about it. I don't think so. He is thinking about the whole field, though, rather than thinking about what are the chances that a baseball will happen to land right where i'm standing right now? I also care about the whole field. I suggest you worry about the Yellowstone Caldera while you're at it. That has a far greater likelihood of taking out your entire baseball stadium. :) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: s2k-cipher-mode default
On Tue 2015-06-02 17:51:50 -0400, ved...@nym.hush.com wrote: The s2k default is also the default for symmetrically encrypted messages (which is fine, as long as people know about it). I mentioned the possible interoperability concern in my first post on this thread. If a person wants to symmetrically encrypt a message or file with AES 256, or any other symmetric algorithm, then the user will need to specify the option either in gnupg.conf or on the command line. This is not true. symmetric algorithm selection during decryption is done based on the metadata parameters stored in the SKESK packet, which indicate which cipher to use. As long as the peer can do AES256 (and all reasonably modern OpenPGP implementations can), no additional configuration is needed: 0 dkg@alice:~$ echo test | gpg2 --symmetric | pgpdump Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) New version(4) Sym alg - AES with 256-bit key(sym 9) Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - a1 bf fd 74 8e a4 07 7a Count - 23068672(coded count 230) New: Symmetrically Encrypted and MDC Packet(tag 18)(58 bytes) Ver 1 Encrypted data [sym alg is specified in sym-key encrypted session key] (plain text + MDC SHA1(20 bytes)) 0 dkg@alice:~$ Regards, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: s2k-cipher-mode default
On 6/2/2015 at 3:49 PM, Robert J. Hansen r...@sixdemonbag.org wrote: Given this, I would feel much better if Werner were to spend his time reviewing the code for exploitable bugs than spending even five minutes changing the s2k default from AES-128 to AES-256. = Agreed, but here's a consequence you might want to consider adding into your FAQ : The s2k default is also the default for symmetrically encrypted messages (which is fine, as long as people know about it). If a person wants to symmetrically encrypt a message or file with AES 256, or any other symmetric algorithm, then the user will need to specify the option either in gnupg.conf or on the command line. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: s2k-cipher-mode default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 2 June 2015 at 8:46:18 PM, in mid:556e080a.6070...@sixdemonbag.org, Robert J. Hansen wrote: [Note for UK/European readers: 'million' here denotes an American million: 1,000,000.] 10^6 is a million both sides of the pond, n'est-ce pas? The long and short scales only diverge from 10^9 upwards. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-gro...@riseup.net I hit the CTRL key but I'm still not in control! -BEGIN PGP SIGNATURE- iQF8BAEBCgBmBQJVbiUuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwBkAH/1CSRi8QgE/C1GYKREHXwl1C yFNu/r6S+qzFHsme5UoHZlARH4erXTsZbvokc6gUCHvpSPrhSlhqW7qTfIuTg26X QjZ/LzGhjh4ZqdiD40T1RHsFnnEK0EP4ulTrxmojefYwsrkNi7kPK8rjPUo6B5/9 jW9RNswwG6dSR626d/bdn9uJfCO+OuQzpskltG6dHKxRxTNuNoVjZn1Uo8GO44Ox jgFI67+CfqMILJOJB6G8gEwWXe1F01zwUeQ2Pm8keDdpvCbKRLhcvrU4lkG2y19+ czAk/4Bn6xi7l3shkpyyGDW37QLYcKOh3BIqYUBERHRy6UlwxyYZNcUvAtwl0xKI vgQBFgoAZgUCVW4lSV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45NZnAQCOtzJA9wyNAjefBG8qYCO9zJYI 8a0nYU2NYA/PK6//JwD/Q3FGHikKoc5WSnuGXPRNR4VL+OPYYxyj44VSseb4FAo= =yUpk -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Enigmail] Facebook and OpenPGP
You've been trusting FB by using this function, before you trust that app :-) On Mon, Jun 1, 2015 at 12:18 PM, Jason Antony alexander...@gmail.com wrote: On 2015-06-02 02:17, Melvin Carvalho wrote: Now we just need a facebook app to generate keys ... But would you trust that app? :-) -- Jason ___ enigmail-users mailing list enigmail-us...@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net -- Fan Jiang 蒋帆 Developer Thoughtworks, Inc. mobile +86-150-9189-3714 skype f...@torchz.net ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
man page refers to conventional encryption -- does this mean symmetric?
Hi GnuPG folks-- I just noticed that a couple places in doc/DETAILS and doc/gpg.texi refer to conventional encryption. Does this mean symmetric encryption or something else? More concretely, i'm assuming it refers to SKESK[0]-prefixed SEIPD[1] packets. Is this correct? In 2015, i'm not sure whether this is any more conventional than PKESK-prefixed SEIPD packets. Should the term be explained somewhere? --dkg [0] Symmetric-Key Encrypted Session Key Packets https://tools.ietf.org/html/rfc4880#section-5.3 [1] Symmetrically-Encrypted Integrity Protected Data packets https://tools.ietf.org/html/rfc4880#section-5.13 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] GnuPG 2.0.28 stable released
Hello! We are pleased to announce the availability of a new stable GnuPG-2.0 release: Version 2.0.28. This is a maintenance release which fixes a couple of bugs. Update to this version is suggested. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG modern (2.1) is the latest development with a lot of new features including support for ECC. - GnuPG stable (2.0) - which this is about - is the current stable version for general use. This is what most users are currently using. - GnuPG classic (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install modern (2.1) and stable (2.0) at the same time. However, it is possible to install classic (1.4) along with any of the other versions. What's New in 2.0.28 * agent: Added support for an external password manager. * gpg: New command --list-gcrypt-config. * gpg: Issue NEWSIG status lines during signature verification. * gpgsm: The default hash algo for a CSR is now SHA-256 and the default encryption algo is AES-128. * scdaemon: Allow PC/SC reader selection by partial name match. * gpgtar: Fix extracting files with a size of a multiple of 512. * Fixed several other bugs. * Libgcrypt 1.5 is now required. Getting the Software Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.0.28 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/. The list of mirrors can be found at https://gnupg.org/mirrors.html. Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org and on its mirrors you should find the following new files in the gnupg/ directory: - The GnuPG source code compressed using BZIP2 and its OpenPGP signature: gnupg-2.0.28.tar.bz2 (4332k) gnupg-2.0.28.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs for GnuPG-2. A Windows version will eventually be released at https://gpg4win.org . If you are new to GnuPG please consider to use the modern version 2.1.4. Checking the Integrity == In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.0.28.tar.bz2 you would use this command: gpg --verify gnupg-2.0.28.tar.bz2.sig gnupg-2.0.28.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either sha1sum or shasum. Assuming you downloaded the file gnupg-2.0.28.tar.bz2, you would run the command like this: sha1sum gnupg-2.0.28.tar.bz2 and check that the output matches the next line: 9a1050f72b6c9afe2b4a0a3f2e9dca2abba8e4ef gnupg-2.0.28.tar.bz2 Release Signing Keys To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) dshaw 'at' jabberwocky.com rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286
Re: man page refers to conventional encryption -- does this mean symmetric?
On Tue, 2 Jun 2015 16:43, d...@fifthhorseman.net said: I just noticed that a couple places in doc/DETAILS and doc/gpg.texi refer to conventional encryption. Does this mean symmetric encryption or something else? Yes. I changed it to read symmetricc encryption with passphrase, More concretely, i'm assuming it refers to SKESK[0]-prefixed SEIPD[1] packets. Is this correct? Yes. 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: s2k-cipher-mode default
Peers that do not support AES256 are either extremely rare or hopelessly out of date. Reducing the strength of the ciphers in use for the sake of preserving interop with these peers seems like a bad tradeoff. What do folks think about making this change to the defaults? At present I'm against it, but my mind's not made up. Right now pretty much everyone is content with RSA-3072, which has an estimated work factor comparable to AES-128. So if 128-bit crypto is enough, I don't understand the motivation behind jumping to AES-256. There needs to be something motivating this besides bigger is better. Let me turn the question around, dkg. (Completely serious here, not snark.) What problem do we have with AES-128 that switching to AES-256 will solve? smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: s2k-cipher-mode default
On Tue 2015-06-02 12:41:40 -0400, Robert J. Hansen wrote: Right now pretty much everyone is content with RSA-3072, which has an estimated work factor comparable to AES-128. So if 128-bit crypto is enough, I don't understand the motivation behind jumping to AES-256. There needs to be something motivating this besides bigger is better. I agree with you that these comparisons are a decent rough estimate when considering attacking a single ciphertext. But i don't think the argument holds looking at the bigger picture. Let's consider an adversary that can store as many OpenPGP-encrypted messages as it has access to. Maybe it sniffs SMTP traffic as well? If the attacker is interested in breaking the crypto of any *one* of these messages, it can reduce the amount of work it has to do significantly. As djb put it: There are standard attacks that break _all_ of 2^50 AES-128 keys using a _total_ of 2^128 easy computations. Even worse, there are standard attacks that find _at least one_ of the keys using just 2^78 easy computations, a feasible computation today. -- http://thread.gmane.org/gmane.ietf.irtf.cfrg/3427 Note that he's describing a known-plaintext attack; this might be relevant, for example, if there is a standard prefix of the data being encrypted (perhaps a common MIME header? or if you're doing regular backups of a standard filesystem, the beginning of the tar format?). Of course, there aren't 2^50 AES-128-encrypted known-plaintext OpenPGP messages today that such an attack would work on. but why would we want to leave users open to this? Let me turn the question around, dkg. (Completely serious here, not snark.) What problem do we have with AES-128 that switching to AES-256 will solve? Is the above argument enough for you? Remember that these AES128 ciphertexts are likely to exist well into the future, and attacks only get better with time. Regards, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
