Re: Arch Linux impacted by new defaults in 2.2.17

It's all about where they look for new/updated keys. There's folks out there who use a WKD setup, as you mentioned, then there's some who use a standalone (isolated, non-peering) SKS keyserver, etc. I do not think reverting the patch that causes issues for them is a smart move in the long run. [.

Arch Linux impacted by new defaults in 2.2.17

Hello, I just saw the following bug reported in Arch Linux repos: https://bugs.archlinux.org/task/63147 with the title "[gnupg] 2.2.17 release is broken by design and breaks pacman". It appears Arch's packages use Web of Trust for introducing new developers by adding 3 signatures out of 5 (o

Re: Defaults

On Thu, 19 Mar 2015 11:19, mue...@cryptobitch.de said: > Is there anything in this listing that would allow me to quickly copy and > paste > (e.g. double click and middle click) in order to further work with the key, > e.g. edit or encrypt to? Sorry, I do not understand you. This is a command l

Re: Defaults

specifically concentrating on defaults for new key generation, perhaps a fully comprehensive discussion of GnuPG defaults would be useful. This could be partly informed by people looking through their GnuPG.conf files at the options they have chosen to to change. - -- Best regards MFPA

Re: Defaults

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thursday 19 March 2015 at 10:19:45 AM, in , Tobias Mueller wrote: > I thought short keyids are dangerous and should not be > used, cf. . If that's the case > then it might be a good idea to fade them out as much > as poss

Re: Defaults

On Wed, Mar 18, 2015 at 09:09:30AM +0100, Werner Koch wrote: > Create a new key: > > $ gpg --no-options --quick-gen-key 'test key ' > About to create a key for: > "test key " > > Continue? (Y/n) y > public and secret key created and signed. > > pub rsa2048/50C4476F 2015-03-

Re: Defaults

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wednesday 18 March 2015 at 8:09:30 AM, in , Werner Koch wrote: > > created: 2015-03-18 expires: never Just wondering why we want keys to never expire by default. Why is that better than a default validity period of "X" years? - -- Best

Re: Defaults

On 03/18/2015 01:34 AM, Robert J. Hansen wrote: I think this shouldn't be supported; CAST5 should only be used if (a) it's in the recipient's key prefs and (b) it's explicitly listed in default-cipher-prefs. I don’t think that ignoring the recipient’s preferences should be the default behavio

Re: Defaults

On Tue, 17 Mar 2015 20:44, r...@sixdemonbag.org said: > Given that 2.1 introduces a lot of new capabilities (mostly with respect > to ECC), I think now, early on in the 2.1 series, would be a good time > to discuss changing the defaults for newly-generated certificates. Let's do a

Re: Defaults

> Some of the defaults you propose are already there. Yes. My list was comprehensive ("what the new set should be"), not differential ("what needs changing"). :) > So, AES256 is already the default symmetric cipher (CAST5 and IDEA > are not even in the lis

Re: Defaults

On 03/18/2015 12:28 AM, Daniel Kahn Gillmor wrote: On Tue 2015-03-17 18:53:42 -0400, Damien Goutte-Gattat wrote: Do you mean signatures in general, or key signatures (certifications)? For key signatures, SHA-1 is still the default for RSA keys Is this correct? I think we should be defaulting

Re: Defaults

On 3/17/2015 11:25 PM, Kristian Fiskerstrand wrote: > On 03/17/2015 10:58 PM, Pete Stephenson wrote: >> On 3/17/2015 8:44 PM, Robert J. Hansen wrote: > > ... > >> Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x >> also have that feature? > > > RFC6979 is used for gnupg 2.0 compi

Re: Defaults

On Tue 2015-03-17 18:53:42 -0400, Damien Goutte-Gattat wrote: > Do you mean signatures in general, or key signatures (certifications)? > For key signatures, SHA-1 is still the default for RSA keys Is this correct? I think we should be defaulting to SHA-256 for RSA certifications these days. If

Re: Defaults

On 03/17/2015 08:44 PM, Robert J. Hansen wrote: Given that 2.1 introduces a lot of new capabilities (mostly with respect to ECC), I think now, early on in the 2.1 series, would be a good time to discuss changing the defaults for newly-generated certificates. Some of the defaults you propose

Re: Defaults

and back it up then that changes things. > At any rate, changes are afoot, and i don't think we should be afraid to > update the defaults if we think a new set is reasonable. Hear hear. There are many times where GnuPG setting the pace would have helped those of us helping other

Re: Defaults

>> Looking over it again, it turns out the Canadians are distrustful >> of 128-bit crypto *in general*. None of them are approved for >> periods longer than seven days. > > True, but that's not uncommon: OpenVPN in TLS mode renegotiates a > new session key ever hour by default. GnuPG generates ne

Re: Defaults

> by this argument, you should have pushed for RSA 3072 during the > last defaults change, since it would have lasted longer than 2048 ;) You're absolutely right, I should have. :) I took my eye off the ball and didn't notice we were changing defaults, otherwise I would'v

Re: Defaults

On Tue 2015-03-17 18:37:40 -0400, Robert J. Hansen wrote: >> I agree that defaulting to brainpool-512 right now would be a >> mistake. >> >> Defaulting to RSA 3072 seems reasonable to me, though. > > I think it's best to minimize the number of times we change

Re: Defaults

wing curves: > > * NIST > o P-256 > o P-384 > o P-521 > * Brainpool > o P-256 > o P-384 > o P-512 > > I cannot in good conscience recommend changing the defaults to an

Re: Defaults

> I agree that defaulting to brainpool-512 right now would be a > mistake. > > Defaulting to RSA 3072 seems reasonable to me, though. I think it's best to minimize the number of times we change the defaults. If we change them too often it causes users to wonder if there&#

Re: Defaults

> I have reasons to prefer RSA, yes, but whether they'll convince you > is a different matter. :) D'oh! Forgot to mention an important one -- RSA-3072 keys can be moved to smart cards, and/or generated on the same. Very few smart cards support DSA. :) signature.asc Description: OpenPGP di

Re: Defaults

On Tue 2015-03-17 17:58:47 -0400, Pete Stephenson wrote: > Alas, a lot of Linux distributions are quite slow-moving: it's unlikely > that distributions like Debian and Ubuntu will have GnuPG 2.1.x > available (let alone installed by default) for several years. For debian stable, this is likely to

Re: Defaults

CC, why not use some other, more modern curve that's designed at a > high-security level? Because at present GnuPG supports the following curves: * NIST o P-256 o P-384 o P-521 * Brainpool o P-256

Re: Defaults

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/17/2015 10:58 PM, Pete Stephenson wrote: > On 3/17/2015 8:44 PM, Robert J. Hansen wrote: ... > Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x > also have that feature? > RFC6979 is used for gnupg 2.0 compiled with libgcrypt

Re: Defaults

On 3/17/2015 8:44 PM, Robert J. Hansen wrote: > Given that 2.1 introduces a lot of new capabilities (mostly with respect > to ECC), I think now, early on in the 2.1 series, would be a good time > to discuss changing the defaults for newly-generated certificates. > >

Re: Defaults

> I remember reading about an attack that works better against AES-256 > than AES-128: That one's a related-key attack, which requires the attacker to have a significant number of keys that have some mathematical relationship to each other. OpenPGP uses random nonces for symmetric keys (or itera

Re: Defaults

On Tue, 17 Mar 2015 15:44:47 -0400 Robert J. Hansen wrote: > [*] As I read the tea leaves, I'm more convinced of AES256's long-term > strength than I am of AES128's. However, the idea that either one of > them is somehow 'weak' is just ludicrous. If you use AES128, don't > panic. :) I remember

RE: Defaults

My vote is for the defaults Robert is proposing. Definitely in keeping with what else I have been reading. Thanks, Bob Cavanaugh > -Original Message- > From: Gnupg-users [mailto:gnupg-users- > bounces+robertc=broadcom@gnupg.org] On Behalf Of Robert J. > Hansen >

Defaults

Given that 2.1 introduces a lot of new capabilities (mostly with respect to ECC), I think now, early on in the 2.1 series, would be a good time to discuss changing the defaults for newly-generated certificates. In a nutshell: * Offer Brainpool-512 and RSA-3072 as options for

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Aug 14, 2014, at 4:23 AM, David Shaw wrote: > On Aug 14, 2014, at 1:20 AM, Doug Barton wrote: > >> On 08/12/2014 08:41 PM, David Shaw wrote: >>> Maybe the answer is to remove the things to generate PGP 2 messages >>> specifically, and leave the other stuff? >> >> Yes please. :) >> >> Not

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Aug 14, 2014, at 1:20 AM, Doug Barton wrote: > On 08/12/2014 08:41 PM, David Shaw wrote: >> Maybe the answer is to remove the things to generate PGP 2 messages >> specifically, and leave the other stuff? > > Yes please. :) > > Not being able to encrypt/sign with PGP 2 at this point is total

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Aug 13, 2014, at 3:56 AM, Werner Koch wrote: >> state. One place that comes to mind is in --gen-revoke. GPG can >> import a bare revocation certificate. No version of PGP can, so there >> is code to push out a minimal public key before the revocation >> certificate. We'd need to add some s

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Wed, 13 Aug 2014 05:41, ds...@jabberwocky.com said: > Maybe the answer is to remove the things to generate PGP 2 messages > specifically, and leave the other stuff? That feels a bit messy. Did this for 2.1. The options --pgp2 and --rfc1991 are completely gone. Unless --allow-weak-digest-alg

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On 13.08.2014, Johan Wevers wrote: > Most people, inclusing me, have stopped using it. However, I still have > a lot of mail archives from those days. Removing support would mean I > have to start using pgp 2 again to access them. Or the most recent version of gnupg with support for those mail a

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 toolc

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

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

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On 8/12/2014 at 11:46 PM, "David Shaw" 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 maint

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On 12-08-2014 0:08, David Shaw 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? Why? It would make checking old mail archives more complicated. Further, since a fix only requires a reordering of the sequen

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Aug 12, 2014, at 3:33 AM, Werner Koch wrote: > On Tue, 12 Aug 2014 00:08, ds...@jabberwocky.com said: > >> Rather than fixing RFC-1991 support, why not go in the other direction >> and make it clear that it isn't supported, and won't work? I did a >> bunch of work to make --pgp2 work well an

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Tue, 12 Aug 2014 00:08, ds...@jabberwocky.com said: > Rather than fixing RFC-1991 support, why not go in the other direction > and make it clear that it isn't supported, and won't work? I did a > bunch of work to make --pgp2 work well and interoperate with PGP 2.x > over a decade ago. Even th

Re: [openpgp] SHA-2 support should be mandatory – change defaults

> 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? Sounds like an excellent plan to me. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Aug 11, 2014, at 1:31 PM, Johan Wevers wrote: > On 11-08-2014 8:49, Robert J. Hansen wrote: > >> On Enigmail, I recently had a frustrating >> experience helping a user who was trying to use GnuPG to exchange >> traffic with a PGP *2.6* user... a codebase which is about 20 years old now. > >

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On Mon, 11 Aug 2014 19:31, joh...@vulcan.xs4all.nl said: > Fixing the packet order when --pgp2 or --rfc1991 are used would help a Too complicated and breaks too much. > lot. And now I assume that pgp 2 will not pass away before the It is quite funny that some people here demand a ban of SHA-1 w

Re: [openpgp] SHA-2 support should be mandatory – change defaults

On 11-08-2014 8:49, Robert J. Hansen wrote: > On Enigmail, I recently had a frustrating > experience helping a user who was trying to use GnuPG to exchange > traffic with a PGP *2.6* user... a codebase which is about 20 years old now. Fixing the packet order when --pgp2 or --rfc1991 are used woul

Re: [openpgp] SHA-2 support should be mandatory – change defaults

(Since this has taken a turn for the GnuPG-specific, I have migrated this thread to GnuPG-Users. It was originally found on the IETF OpenPGP working group page.) >> even though it's not default, you can change your gpg.conf(5) to >> use a specific hashing algorithm > > In particular, set the fol

Re: FAQ? Re: please give us safer defaults for gnupg

On Wed, 18 Dec 2013 16:09, bernh...@intevation.de said: > What about placing this as an FAQ in the wiki.gnupg.org? We have a FAQ which answers a lot of questions around key sizes in “Advanced Topics” section. If something is missing it can easily be added. Salam-Shalom, Werner -- Die Ged

FAQ? Re: please give us safer defaults for gnupg

Am Montag, 16. Dezember 2013 20:42:54 schrieb Werner Koch: > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of using SHA-512 are missing the point.  Some > folks here must have bleeding fingertips from repeating the arguments > over and over. What a

Re: please give us safer defaults for gnupg

;> > >> >Cheers, >> >adrelanos >> > >> >[1] http://secushare.org/PGP > = > > All of his reasons are easily countered. I don't want to discuss them here in this thread to avoid distraction. My topic: "please give us safer defaults for gnupg&

Re: please give us safer defaults for gnupg

All of his reasons are easily countered. Looking over it, my impression is that his principal criticism is, "It is not all things to all people." To which my response is -- nothing in this world is, so why should OpenPGP be any different? OpenPGP provides a useful set of capabilities an

Re: please give us safer defaults for gnupg

On Tuesday, December 17, 2013 at 12:49 PM, "adrelanos" wrote: >The person who agreed with me: >carlo von lynX > >Also the autor of "15 reasons not to start using PGP". [1] > >Cheers, >adrelanos > >[1] http://secushare.org/PGP = All of his reasons are easily countered. In the interests of

Re: please give us safer defaults for gnupg

Robert J. Hansen: >> We think... > > If you're writing on behalf of a group, I would love to know the name of > the group and the names of its members. Otherwise, I can only assume > you are suffering a mental illness and are speaking for the multiple > voices in your head -- either that or else

Re: please give us safer defaults for gnupg

On Tue, 17 Dec 2013 00:11, adrela...@riseup.net said: > compatibility, you can never reduce complexity. Less complexity means > more simplicity, thus perhaps more usability. In my experience, projects [ You may want to start getting rid of software which is run on your computer without you bein

Re: please give us safer defaults for gnupg

On 12/16/2013 6:11 PM, adrelanos wrote: > When I searched for this on search engines, I haven't found one in a > project's character. (I.e. were it's open for debate/pull > requests/changes.) Perhaps not, but you *did* find them. Your original email referenced, for instance, the Debian GnuPG mig

Re: please give us safer defaults for gnupg

g for OpenSSL encrypted messages. >> it is a somewhat usable >> racing car but it unfortunately comes with a limiter and you need to >> find out how to get rid of the limiter first. > > Although you chose this metaphor, I'm not sure that it's a metaphor you > rea

Re: please give us safer defaults for gnupg

Werner Koch: > On Mon, 16 Dec 2013 18:37, adrela...@riseup.net said: > >> [This was originally planed as an open letter, but I thought it might >> be better to hear your arguments beforehand.] > > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of u

Re: please give us safer defaults for gnupg

ead driver and a smoking wreck that used to be worth half a million quid. What you call "limits" are, in reality, carefully chosen behaviors meant to keep new users safe from their own mistakes. I do not believe it is wise or ethical to tell new users they need to erase their m

Re: please give us safer defaults for gnupg

On Mon, 16 Dec 2013 18:37, adrela...@riseup.net said: > [This was originally planed as an open letter, but I thought it might > be better to hear your arguments beforehand.] May I suggest to read the archives of just a few weeks to collect the reasons why suggestions of using SHA-512 are missing

please give us safer defaults for gnupg

poor defaults and since it is of that much importance, that is a problem. We even have a recommended gpg.conf in torbird's git repo. [2] [3] The fact that we even need such a thing is bad. For example cert-digest-algo why is it in gpg still sha1 and not sha256 or sha512? Now that a few people know,

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/31/2013 4:31 PM, Daniel Kahn Gillmor wrote: > ENISA (the European Union Agency for Network and Information Security) > recently issued a report recommending that non-legacy systems using RSA > start with keys that are >= 3072 bits (see page 30 of the PDF): Huh -- fascinating! Thank you for

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 31/10/13 22:02, Hauke Laging wrote: > But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia > article for AES) claims that AES-256 was down to 99.5 bits. I just glanced over the abstract, but didn't you glance over the term "related key"? I.e., not generally applicable.

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia article for AES) claims that AES-256 was down to 99.5 bits. If memory serves that's a related-key attack. (Hmm. When you've gotten to the point where you can recognize academic papers by their URLs, maybe that's a si

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On Thu, Oct 31, 2013 at 10:02 PM, Hauke Laging wrote: > Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor: > >> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable >> s/algorithms-key-sizes-and-parameters-report > > There is one point I don't understand: > > [3.6 Reco

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor: > http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable > s/algorithms-key-sizes-and-parameters-report There is one point I don't understand: [3.6 Recommendations] "there is general agreement this should be above the

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On Thu 2013-10-24 15:05:45 -0400, Sylvain wrote: > I saw a lot of activity in the Debian project about upgrading to a > 4096 RSA key, > e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg3.html > > However GnuPG's default is 2048. ENISA (the European Union Agency for Network and Inf

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.10.2013 19:47, schrieb Peter Lebbing: > On 27/10/13 19:09, Filip M. Nowak wrote: >> 1) Specialized microcontrollers with crypto capabilities are >> available and used for years now (AVR XMEGA which is 8 bit for >> example) > > AVR XMEGA has DES

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On Sun, 27 Oct 2013 21:28, gn...@oneiroi.net said: > I don't think 1 second threshold is real no-go here. I would say you > have quite high requirements. Also some MUAs can contribute to such Start working with encrypted mails and slow smartcards on a regular base and you would soon see what I me

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 4:21 PM, Mark Schneider wrote: > Are there formal reasons why the max length of the RSA key is limited in > gnupg[2] linux packages to 4096 Bits only? Yes; because past 3072 bits it's time to go to something other than RSA. Several respectable organizations (not only NIST) have done

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

nly one 4k key. Run these tests again on an average netbook. Are there formal reasons why the max length of the RSA key is limited in gnupg[2] linux packages to 4096 Bits only? One thing are the available performance and sane defaults, the other one the available security. (without patching the s

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

"Robert J. Hansen" wrote: >Let's say that tomorrow I lose my passphrase and make a new keypair. >Then in 25 years someone approaches me with a signed OpenPGP message >dated Christmas 2013, saying "I agree to pay you one million dollars at >Christmas 2038." I scream it's a forgery, they scream it'

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

Hello, On 10/27/2013 08:41 PM, Werner Koch wrote: > On Sun, 27 Oct 2013 17:47, gn...@oneiroi.net said: > >> Numbers please? Or are you talking about personal/subjective impressions? > > What about you running some benchmarks for us? Let's say: a 4k RSA key > signed by 90 other 4k RSA keys, 8 2k

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On Sun, 27 Oct 2013 17:47, gn...@oneiroi.net said: > Numbers please? Or are you talking about personal/subjective impressions? What about you running some benchmarks for us? Let's say: a 4k RSA key signed by 90 other 4k RSA keys, 8 2k RSA keys, and one 8k RSA key. For security reasons key signa

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27-10-2013 18:36, Robert J. Hansen wrote: > Consumer-grade hardware is a decadent Garden of Eden. However, the tiny > little processor that monitors chemical levels at your local water > treatment plant is going to be embarrassingly low-powered. That's fine, but I doubt I'll ever email such a

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

Hi, On 10/27/2013 07:47 PM, Peter Lebbing wrote: > On 27/10/13 19:09, Filip M. Nowak wrote: >> 1) Specialized microcontrollers with crypto capabilities are available >> and used for years now (AVR XMEGA which is 8 bit for example) > > AVR XMEGA has DES and AES, no asymmetric acceleration. Also, I

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27/10/13 19:09, Filip M. Nowak wrote: > 1) Specialized microcontrollers with crypto capabilities are available > and used for years now (AVR XMEGA which is 8 bit for example) AVR XMEGA has DES and AES, no asymmetric acceleration. Also, I think the market of XMEGA is phenomenally tiny compared t

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

those installations need confidentiality, > integrity and assurance even more than I do!), I'm happy the GnuPG > defaults are the way they are. This is your holy right I think. I would say exactly the same to the people who are dissatisfied with those settings or hardwired limits. &g

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

e than I do!), I'm happy the GnuPG defaults are the way they are. > On the other hand, one of the conclusions that Mr Schneier... Just once, I'd love to hear someone say "Kelsey advises" or "Boneh thinks" or "Ferguson has opined that..." The world of comp

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 10:41 AM, MFPA wrote: > Couldn't a cryptographically broken algorithm also raise the problem > of forged digital signatures? Yes and no. The mistake people make when discussing digital signatures is to treat them as a purely mathematical exercise rather than as something that exist

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 10:04 AM, MFPA wrote: > Which raises the question in my mind: was SHA really flawed, or was it > advantageous to NSA's purposes to have people use SHA-1 instead? It's amazing what you can discover by checking Wikipedia. SHA was deeply flawed. The civilian cryptanalytic community br

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 8:21 AM, Johan Wevers wrote: > Well, both are not broken after substantial research. Further, a break > of ElGamal would also break RSA but not the other way around. If you can compute discrete logs in a finite field, then you can factor, yes, and the reverse is not guaranteed to be

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 7:15 AM, Johan Wevers wrote: > Does RSA have any advantages over ElGamal/DSA? It's simpler to implement. That's a nontrivial benefit. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 10/27/2013 01:32 PM, Peter Lebbing wrote: > (...) > But the following layout is sensible on some level: Which more or less means exactly nothing. > 3072-bit RSA primary for certification (C) > 2048-bit RSA subkey for data signatures (S) > 3072-bit RSA subkey for encryption (E) > > (...)

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

Hi, On 10/26/2013 02:13 PM, Werner Koch wrote: > On Sat, 26 Oct 2013 11:35, b...@beuc.net said: > >> Plus, following this principle, why doesn't gnupg default to 4096 if >> there isn't any reason not to? I would suppose that if gnupg defaults > > 4k primary

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 26 October 2013 at 12:39:58 AM, in , Paul R. Ramer wrote: > Well, this assumes that you need 25 years of security. > If your messages *must* remain uncrackable for that > length of time, you may want to take many more measures > t

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 26 October 2013 at 4:16:32 PM, in , Hauke Laging wrote: > Why should anyone 25+ years from now spend a huge > amount of resources in order to read a tiny part of > today's everyday communication (or a big part in 40 > years)? That

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 27 October 2013 at 6:42:31 AM, in , Robert J. Hansen wrote: > The NSA never went public with the precise > vulnerability in SHA that caused them to develop and > release SHA-1, but they were quite open and public > about SHA being in

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27/10/13 12:53, Johan Wevers wrote: > But the few encrypted messages people get via email can easily be handled by > a much slower CPU than I have now. My reading speed is the limiting factor > there, not the computers decrypting speed. I was thinking of automated systems doing verifications,

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27/10/13 13:21, Johan Wevers wrote: > Which makes me think, is it possible to generate a 2048 bit RSA signing > key combined with a 3072 or 4096 bit encryption key? Yes, although I don't think it makes sense to create an X-bit primary key with a Y-bit subkey if X is smaller than Y as the attack

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27-10-2013 13:11, Peter Lebbing wrote: > I think RSA has seen more cryptanalysis than DSA and ElGamal, which is in > favour > of RSA. Well, both are not broken after substantial research. Further, a break of ElGamal would also break RSA but not the other way around. The rest of the arguments

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27/10/13 13:11, Peter Lebbing wrote: > A signature by a 2048-bit DSA key is twice as large as a signature by a > 2048-bit > RSA key, but offers the same order of strength. Oops. I just read Werners message, and I had it reversed :). Taking a look at RFC 4880, I see that a 2048-bit key has a 25

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

> Yes, which leads to another question: why has the default switched from > ElGamal/DSA to RSA after the RSA patent expired? Okay, first of all, I'm doing something wrong here, I should group my responses and think a little longer about it. This is mail, not chat. My apologies. I think RSA has se

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On Sun, 27 Oct 2013 12:15, joh...@vulcan.xs4all.nl said: > ElGamal/DSA to RSA after the RSA patent expired? Does RSA have any > advantages over ElGamal/DSA? The only one I can think of is less It is in general faster and there are OpenPGP implementations which only support RSA (despite that the s

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27-10-2013 12:30, Peter Lebbing wrote: > But I can think of another one: much more hardware support. Both smartcards > and > crypto-accelerators either in a general purpose CPU or as a module in a > computer. I had not thought of the crypto cards, but the only crypto hardware acceleration in

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 2013-10-27 12:30, Peter Lebbing wrote: I think this is a very important one Hmmm you press Send and you think: I might have overstated that. Where's unsend? I think it's a real advantage of RSA. I don't think it's a very important one, because other broken parts can compromise stuff just

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27/10/13 12:15, Johan Wevers wrote: > The only one I can think of is less dependence of a correctly functioning > RNG. I think this is a very important one, as we've seen with the debacle with OpenSSL in Debian where DSA keys were compromised even when just used to create a signature[1]. But I

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 26-10-2013 14:13, Werner Koch wrote: > 4k primary RSA keys increase the size of the signatures and thus make > the keyrings longer and, worse, computing the web of trust takes much > longer. Yes, which leads to another question: why has the default switched from ElGamal/DSA to RSA after the RS

Re: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch]

Hi, On Sat, Oct 26, 2013 at 06:29:26PM -0400, Robert J. Hansen wrote: > On 10/26/2013 3:40 PM, Sylvain wrote: > > Thanks for your answer. To foster spending less time on these > > discussions, how about this? :) > > Hi! I'm the quasi-official FAQ maintainer. You can read the current > text of

Re: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch]

On Sun, 27 Oct 2013 00:29, r...@sixdemonbag.org said: > Hi! I'm the quasi-official FAQ maintainer. You can read the current > text of the FAQ at: While we are at it. What about making it the official one, i.e. change the licenses to CC-by-ca/GPL? Given the importance of a FAQ I think we shoul

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

> Often there is also value in breaking crypto so that the targeted > crypto users don't know it has been broken and thus continue to use > it (the algorithm and/or the specific key). If a big government > organization (take your pick) had broken algorithm/keysize xyz, would > they tell anybody? H

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

On 27.10.2013 2:09, Robert J. Hansen wrote: > The name of the game is economics. How much is the secret worth? If > it's worth $50,000 of computer equipment and cryptanalysis, then it's > also worth a $50,000 bribe, a $50,000 payment to a professional thief to > break in and plant keyloggers, $50

  1   2   >