Thunderbird dealing with signed messages and mailing lists [was: Re: Best practices for obtaining a new GPG certificate]

[Daniel Kahn Gillmor via Gnupg-users]

On Fri 2021-03-19 15:30:51 -0700, Mark via Gnupg-users wrote:
> It also has issues with signed messages and lists. For example you
> signed this message but it says "uncertain digital signature".  I don't
> remember this being an issue in the older TB/Enigmail.

Signed messages on mailing lists that modify message bodies (and
headers) in the way that gnupg-users@gnupg.org does should *not* show as
a valid digital signature.

See
https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-01.html#name-mailing-list-wrapping
for a bit more information on the problem, and
https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-01.html#name-exception-mailing-list-foot
for a proposed method for MUAs to responsibly render such a message.

--dkg

PS fwiw, "uncertain digital signature" probably shouldn't show at all in
   any reasonable end-user-facing MUA unless the user is in some sort of
   special-cased debug mode.  In typical operation, a message either is
   protected by a valid signature or it is not.  Displaying an
   intermediate status like "uncertain" is likely only to cause
   confusion.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Daniel Kahn Gillmor via Gnupg-users]

On Fri 2021-03-19 08:29:12 +0100, Werner Koch via Gnupg-users wrote:
> You may also skip the menu thing and use
>
>   gpg --quick-gen-key b...@example.com future-default

I agree with Werner's recommendation of using --quick-gen-key and
future-default.

If you're going to provide an e-mail address-only User ID, though, i'd
also recommend wrapping it in angle-brackets, as raw e-mail addresses
are still liable to trigger some minor bugs in various pieces of older
OpenPGP tooling.  So that'd be:

gpg --quick-gen-key '' future-default

Using the defaults (or the future defaults, as here) is a good
practice.  Most people shouldn't need anything fancier.

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Mark via Gnupg-users]

It also has issues with signed messages and lists. For example you
signed this message but it says "uncertain digital signature".  I don't
remember this being an issue in the older TB/Enigmail.

On 3/19/2021 10:42 AM, Werner Koch via Gnupg-users wrote:

On Fri, 19 Mar 2021 03:33, Robert J. Hansen said:


Last I checked, Thunderbird 78 did not support ed25519+cv25519
keys. That's not a niche implementation.

I did extensive test with Ribose to make sure that RNP (the crypto
engine now used by TB) is compatible with GnuPG.  Thus I wonder why TB
gets things wrong again.

There are also so many regressions in TB new OpenPGP support compared to
the long standing TB+Enigmail OpenPGP support that I wonder come it is
at all possible to send encrypted OpenPGP mails with TB.


Shalom-Salam,

Werner


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


--
PGP Key Upon Request

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Mark via Gnupg-users]

It "does and it doesn't" I have some that were created in Kleopatra and
then imported into Thunderbird 78. As for creating them, no You
don't get to choose any options when generating ECC keys.

On 3/19/2021 12:33 AM, Robert J. Hansen via Gnupg-users wrote:

The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations.  Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.


Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys.
That's not a niche implementation.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


--
PGP Key Upon Request


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Werner Koch via Gnupg-users]

On Fri, 19 Mar 2021 03:33, Robert J. Hansen said:

> Last I checked, Thunderbird 78 did not support ed25519+cv25519
> keys. That's not a niche implementation.

I did extensive test with Ribose to make sure that RNP (the crypto
engine now used by TB) is compatible with GnuPG.  Thus I wonder why TB
gets things wrong again.

There are also so many regressions in TB new OpenPGP support compared to
the long standing TB+Enigmail OpenPGP support that I wonder come it is
at all possible to send encrypted OpenPGP mails with TB.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Neal H. Walfield]

On Fri, 19 Mar 2021 08:33:17 +0100,
Robert J. Hansen via Gnupg-users wrote:
> 
> > The next default is ECC (ed25519+cv25519) which is supported by most
> > OpenPGP implementations.  Only if you have a need to communicate with
> > some niche implementaions you need to use rsa3072.
> 
> Last I checked, Thunderbird 78 did not support ed25519+cv25519
> keys. That's not a niche implementation.

Thunderbird 78's default OpenPGP implementation is rnp.  According to
the interoperability test suite, rnp is able to use the "Alice" key
from the "OpenPGP Example Keys and Certificates" I-D.

  https://tests.sequoia-pgp.org/#Encrypt-Decrypt_roundtrip_with_key__Alice_
  https://tools.ietf.org/html/draft-bre-openpgp-samples-00#section-2

The "Alice" certificate uses:

  Primary key algorithm: Ed25519
  Subkey algorithm: Curve25519

Neal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Robert J. Hansen via Gnupg-users]

The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations.  Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.


Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys. 
That's not a niche implementation.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Werner Koch via Gnupg-users]

On Thu, 18 Mar 2021 19:34, David Mehler said:

> in the output there's ECC output should I go with an ECC-style key or
> RSA? As regards RSA keysize I typically use 4096.

The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations.  Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.

You may also skip the menu thing and use

  gpg --quick-gen-key b...@example.com future-default


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[Robert J. Hansen via Gnupg-users]

I'd like to know current best practices for obtaining a new one?


This question gets asked so often that it has its own FAQ entry.  Yes, 
parts of the FAQ are outdated, but this particular one is very current.


https://www.gnupg.org/faq/gnupg-faq.html#tuning

* You don't need to "tune" GnuPG before using it
* The defaults for key generation are conservative and safe
* Don't overthink things.  :)

My sometimes-snarky (but completely-sincere) opinion on this evergreen 
question is, "unless you know what you're doing and why you're doing it, 
stick with the defaults."


The other piece of sometimes-snarky (but also completely-sincere) advice 
is that a good 90% of the web pages you find that talk about how to 
create the "perfect" GnuPG key are absolutely full of it.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for obtaining a new GPG certificate

[David Mehler via Gnupg-users]

Hello,

Thanks all. I am definitely wanting a new key.

With regards the info John posted:

gpg --expert --full-gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card

in the output there's ECC output should I go with an ECC-style key or
RSA? As regards RSA keysize I typically use 4096.

Thanks.
Dave.


On 3/18/21, Werner Koch  wrote:
> On Thu, 18 Mar 2021 00:06, David Mehler said:
>
>> My existing GPG certificate is going to expire in less than a month.
>> I'd like to know current best practices for obtaining a new one? In
>
> Do you really want a new one?  Usually it is easier to prolong your key.
> By default a new key has an expire data so that unused keys and those
> with forgotten passphrase will eventually expire.  In general you just run
>
>   gpg --quick-set-expire FINGERPRING EXPIREDATE
>
> Expire dat may be something like 5y for 5 years or an explicit date like
> 2024-12-31.
>
> Here is an example
>
>   $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>
>   sec   ed25519 2021-03-15 [SC] [expires: 2023-03-15]
> A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>   uid   [ unknown] f...@example.de
>   ssb   cv25519 2021-03-15 [E]
> 989ABB95E888956DBD5D7F66C376233B98457556
>
>   $ gpg --quick-set-expire A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8 4y
>
>
>   $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>
>   sec   ed25519 2021-03-15 [SC] [expires: 2025-03-17]
> A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>   uid   [ unknown] f...@example.de
>   ssb   cv25519 2021-03-15 [E]
> 989ABB95E888956DBD5D7F66C376233B98457556
>
>
> Send the public key then to your peers, keyserver, web key directory, or
> wherever.
>
>
> 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: Best practices for obtaining a new GPG certificate

[Werner Koch via Gnupg-users]

On Thu, 18 Mar 2021 00:06, David Mehler said:

> My existing GPG certificate is going to expire in less than a month.
> I'd like to know current best practices for obtaining a new one? In

Do you really want a new one?  Usually it is easier to prolong your key.
By default a new key has an expire data so that unused keys and those
with forgotten passphrase will eventually expire.  In general you just run

  gpg --quick-set-expire FINGERPRING EXPIREDATE

Expire dat may be something like 5y for 5 years or an explicit date like
2024-12-31.

Here is an example

  $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8

  sec   ed25519 2021-03-15 [SC] [expires: 2023-03-15]
A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
  uid   [ unknown] f...@example.de
  ssb   cv25519 2021-03-15 [E]
989ABB95E888956DBD5D7F66C376233B98457556
  
  $ gpg --quick-set-expire A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8 4y


  $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
  
  sec   ed25519 2021-03-15 [SC] [expires: 2025-03-17]
A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
  uid   [ unknown] f...@example.de
  ssb   cv25519 2021-03-15 [E]
989ABB95E888956DBD5D7F66C376233B98457556


Send the public key then to your peers, keyserver, web key directory, or
wherever. 


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Peter Lebbing]

On 27/11/15 12:41, Andrew Gallagher wrote:
> There's a post about how to do this in the list archives:
> 
> https://lists.gnupg.org/pipermail/gnupg-users/2009-May/036505.html

Thanks for the pointer!

> ... but it's really not worth your while. So long as your primary key
> doesn't have E usage set*, you can create new A and S subkeys and simply
> refrain from using the primary key for those functions.

I agree for the most part. I'm not so sure about how easy it is to refrain from
using an A-capability. I think when an SSH server indicates it accepts a
signature from my primary key, and that primary key is on a smartcard, GnuPG
will try to do that. So that is in the hands of the server, not the client.
Although you might be able to disable it with an sshcontrol file, I'm not sure
of the exact way it all interacts.

> The only problem you might run into is if one of your correspondents is
> using broken client software that doesn't check signatures against
> multiple subkeys. I've no idea how likely this is though.

Kill that client software until dead. Then some more.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Peter Lebbing]

On 23/11/15 21:31, James wrote:
> It appears that information I had read previously was erroneous. I was
> under the impression the capabilities (at least for the primary key)
> were set in stone, hence my apprehension at avoiding those insatiable
> knobs and gears I like to tinker with. ;)

Well, GnuPG doesn't provide an easy means to change them; it could be
that you would need to edit the source. However, that is hardly an
obstacle for an attacker who can write C code...

It shouldn't be difficult to write an ugly little hack to replace your
capabilities. The first thing that comes to mind is changing the code
creating the signature that extends the expiration date to create the
signature that sets capabilities. Compile, run, throw away.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[James]

Thank you Robert and Peter.

It appears that information I had read previously was erroneous. I was
under the impression the capabilities (at least for the primary key)
were set in stone, hence my apprehension at avoiding those insatiable
knobs and gears I like to tinker with. ;)

This thread has been tremendously insightful. My thanks to all who
responded and shared their perspectives.

James

On Mon, Nov 23, 2015 at 12:05 PM, Robert J. Hansen  wrote:
>> The same can be said for almost any complex system, software or not.
>
> Absolutely.  Please don't misinterpret what I said as trying to dissuade
> you from curiosity.  I'm just urging you to not let your curiosity lead
> you into making poor decisions from the get-go.
>
> The following anecdote is meandering, but if you'll bear with me for two
> paragraphs it'll make sense:
>
> I live in the United States, in a state which allows private citizens,
> under incredibly close regulation, to own military firearms.  When I
> visit the rifle range, sometimes I'll spend some time with a suppressed
> German-made MP5SD3 submachinegun.  (It's not mine: a friend owns one and
> we sometimes hit the range together.)  It's a nice piece of kit; I like
> it.  And quite often, other people who are at the range want to talk
> shop about it.  We get into discussions about roller-locked firearms
> like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how
> annoying it is when people get the terminology wrong, whether it's a
> good thing or a bad thing the MP5 uses a fluted chamber, how anyone who
> thinks it's okay to fire subsonic 9mm from the MP5 needs their head
> examined, and so on and so on.  And it's fun, as far as it goes, and
> it's often educational for the people who've never seen an MP5 before
> and are fascinated to learn more about its inner workings.
>
> It's great -- up until they think they know enough to use an MP5 on the
> range, despite the fact they've never fired a weapon before.  At that
> point we have to explain to them that look, yes, they know a lot more
> about the MP5 than most people do, but really, they need to start off
> with something small, like a nice .22 Ruger Mk II, develop the basic
> skills, learn trigger discipline and proper usage of safeties, learn how
> the range operates and what the various calls by the Range Safety
> Officers mean, etcetera.  There's a huge amount to learn: they don't
> need to make things worse by leaping straight over this stuff straight
> to firing fully-automatic military hardware.  That's just imprudent, and
> we'd be awful human beings if we permitted them to do that.
>
> That's what we're talking about here.  The knobs and dials on GnuPG are
> great fun to learn about: you're in good company!  But there's a big
> reason why we're urging you to not do what you want to do, and that's
> because you're not yet competent to do what you want to do.  We'd rather
> see you start off with small steps, and from there move on to the big
> ones, than have you start off big.
>
> Admittedly, it's highly unlikely that screwing up with GnuPG will lead
> to a magazine of 9mm being sprayed around the room.  But it's the
> principle of the thing.  :)
>
> So: for now, please stick with the defaults.
>
>> It seems to me that, perhaps, making these sorts of decisions up front
>> is of some value.
>
> Not really.  It's probably not worth worrying about.
>
>> If you create a primary key, upload it to a public
>> keyserver and later decide: "hrm, my public key should really only
>> certify, not sign," it's a bit too late.
>
> No.
>
> One of the important skills to learn early on is about how to migrate a
> certificate.  You're going to make mistakes.  You'll forget passphrases,
> you'll compromise your keys, you'll realize you made a hash of it and
> need to start over again.  How do you recover from this?  How do you
> communicate a change-of-certificate with your correspondents?  Etc.
>
> The only reason to think "it's a bit too late" is if
>
> a) you're not allowed to change your certificate -- you
>*must* keep the same one for the next X years
> b) you don't know how to migrate to a new certificate
>
> There are almost certainly people and groups for whom (a) applies.  If
> you're one of them, please let me know.  But if (b) applies, then I
> suggest learning the skill, because it's important.  :)
>
>> It's also worth noting that the suggestion to remove the primary key
>> from your laptop isn't thrown up on a few random blogs; instead it is
>> something that other projects[1] encourage.
>
> That wiki page is guidance *for Debian*.  Debian has some very specific
> operating restrictions which are unlikely to apply to you.  The
> guidelines Debian put together apply to them, in their environment,
> facing their threat model, which they defend with their particular set
> of resources.
>
> It is not guidance for you, unless you're part of Debian.
>
> By all means, 

Re: best practices for creating keys

[James]

All,

I'm pleasantly surprised by the warm and helpful reception of this
community to my many questions. Thank you all in advance for your
detailed and thorough responses. The conversation thus far has been
quite thought-provoking.

I thoroughly read and re-read the responses in this thread, tinkered
with GPG for many hours and poured over the documentation (again). I
still have a few questions:

- I believe that GPG has sane settings out-of-the-box, but prefer to
verify that trust. ;) Why doesn't GPG set the digest algorithm to
SHA512 instead of 256 out of the box?
- I'm also curious why the default-preference-list isn't set to
something more secure, as suggested here[1]:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed

To be perfectly clear, I am sure the folks who made the decision to
choose SHA256 is _far_ more intelligent than I am and there is sound
reason behind these default choices. I simply would like to better
understand these design decisions.

I'm also looking for some clarification around the primary key. Out of
the box it appears that GPG will create a private key for signing and
certification. Some documentation around the web indicates that the
primary key can be stripped of all capabilities, leaving _only_
certify. What are the pros and cons of allowing the private key only
to certify, then creating a subkey to sign (and another to encrypt)?

To go a bit further down that rabbit hole, let's say I want to create
a primary key (with certify-only capabilities), several subkeys and
then remove the private key (as has been discussed ad nauseam in this
thread); it appears that stripping the capabilities of the primary key
to the bare minimum (i.e., no signing, no encrypting, no
authenticating) would be "safer," no?

My concern is that if my primary key is for certification only, how
would it sign other people's certificates to expand the web of trust?
I suspect that if the capabilities are set to _only_ certify, I would
need to sign other people's keys using my subkey. How would this
affect the notion of "even if you lose your subkeys, your identity and
web of trust are not impacted as long as your primary key is not
compromised?"

Seems to me that the primary key /should/ have both certify and sign
capabilities to really be useful, no?

Any thoughts and ideas regarding these questions is greatly appreciated.

James

1 https://help.riseup.net/en/security/message-security/openpgp/best-practices

On Wed, Nov 18, 2015 at 7:35 PM, da...@gbenet.com  wrote:
> On 18/11/15 12:08, Peter Lebbing wrote:
>> On 17/11/15 15:33, Andrew Gallagher wrote:
 https://alexcabal.com/creating-the-perfect-gpg-keypair/
>>>
>>> This is a fairly good article - I've used it myself for reference in the
>>> past. Also have a look at:
>>
>> I disagree, I'd recommend people not to read that article, let alone
>> follow its advice.
>>
>> HTH,
>>
>> Peter.
>>
>> [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html
>>
>
> Peter,
>
> When you think about it - if a person stole your laptop with your private and 
> public key on
> it - they still could not use your private key to do anything. Security is in 
> the passphrase
> one sets to use your key. Without it your buggered and so is anyone who has 
> acquired your
> private and public key. They could spend a great deal of time and money - but 
> essentially a
> good passphrase is secure. Brute force - beating the shit out of you - may 
> work - the human
> link is the weakest in the chain.
>
> There is no perfect key - they are all "perfect" their security depends on 
> your passphrase.
>
> Be Happy
>
> 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

Re: best practices for creating keys

[James]

Robert,

I appreciate the input and hear you loud and clear.

I respect that GPG makes sane, technically secure and well-thought-out
decisions. As I mentioned in my previous response, the folks that
designed and coded GPG are likely far more intelligent than I. This
does not assuage my deep curiosity to understand the various knobs and
gears that can be tweaked. Said deep understanding also puts me in a
position whereby I can more easily deal with various issues or
complexities down the line.

The same can be said for almost any complex system, software or not.

It seems to me that, perhaps, making these sorts of decisions up front
is of some value. If you create a primary key, upload it to a public
keyserver and later decide: "hrm, my public key should really only
certify, not sign," it's a bit too late. (although not impossible,
difficult to change ex post facto).

It's also worth noting that the suggestion to remove the primary key
from your laptop isn't thrown up on a few random blogs; instead it is
something that other projects[1] encourage.

If one's primary key is his or her identity, I'd like to be certain
that I correctly create the key(s). Thus being meticulous and careful
in creating primary key seems like a reasonable step, IMHO.

Finally, I do appreciate the list of things that I should focus on --
there are several I had not contemplated and will now do so.

James

https://wiki.debian.org/Subkeys

On Mon, Nov 23, 2015 at 10:52 AM, Robert J. Hansen  wrote:
>> - I believe that GPG has sane settings out-of-the-box, but prefer to
>> verify that trust. ;) Why doesn't GPG set the digest algorithm to
>> SHA512 instead of 256 out of the box?
>
> For the same reason it doesn't default to RSA-4096: because the authors
> are unconvinced there's a need.  Longer is not the same as better.  At
> some point there's such a thing as enough.
>
> SHA-256 is (a) safe enough for essentially all purposes, (b) more
> interoperable with other OpenPGP implementations, and (c) better for
> human readability.
>
>> I'm also looking for some clarification around the primary key. Out of
>> the box it appears that GPG will create a private key for signing and
>> certification. Some documentation around the web indicates that the
>> primary key can be stripped of all capabilities, leaving _only_
>> certify. What are the pros and cons of allowing the private key only
>> to certify, then creating a subkey to sign (and another to encrypt)?
>
> I'm going to repeat my earlier advice: learn to walk before you run.
> The defaults are safe.  Use them.  We can have this conversation at
> great length, but I don't want to encourage you to start doing this.
> Quite the opposite.  Please don't.
>
>> thread); it appears that stripping the capabilities of the primary key
>> to the bare minimum (i.e., no signing, no encrypting, no
>> authenticating) would be "safer," no?
>
> The last word in your sentence is the answer.
>
> It's not safer.  You're talking about making a bank vault door "safer"
> by adding a single millimeter of armor plate.  Your attention is better
> spent elsewhere, especially right now when you're just starting out.
> Focusing on the technical components of the system is ... I hate to say
> "you're doing it wrong," but IMO, you are.  The stuff you're paying
> attention to right now is pretty much irrelevant and unimportant.  The
> stuff you're ignoring is relevant and important.  Start focusing on
> that.  I'd start with:
>
> * Do you have a revocation certificate generated?
> * Is it stored safely?
> * Who has access to your revocation certificate and/or private key?
> * How would you know if someone else had access?
> * How strong is your passphrase?
> * How do you know how strong it is?
> * What will you do if you forget your passphrase -- what's your
>   fallback?
> * If you revoke your certificate, how will you rebuild your personal
>   web of trust?
> * Is GnuPG integrated into your email workflow?  If not, how can it
>   be integrated?
> * Have you considered storing your certificate on a smartcard?
>
> These are the places where GnuPG fails in the real world.  In 20+ years
> of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever --
> encountered anyone who has said, "man, I really wish I'd stripped my
> certificate, that would've saved me no end of grief," and a lot of
> people who have said, "man, I really wish I'd safely stored a revocation
> certificate, that would've saved me no end of grief."
>
>
> ___
> 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: best practices for creating keys

[Robert J. Hansen]

> The same can be said for almost any complex system, software or not.

Absolutely.  Please don't misinterpret what I said as trying to dissuade
you from curiosity.  I'm just urging you to not let your curiosity lead
you into making poor decisions from the get-go.

The following anecdote is meandering, but if you'll bear with me for two
paragraphs it'll make sense:

I live in the United States, in a state which allows private citizens,
under incredibly close regulation, to own military firearms.  When I
visit the rifle range, sometimes I'll spend some time with a suppressed
German-made MP5SD3 submachinegun.  (It's not mine: a friend owns one and
we sometimes hit the range together.)  It's a nice piece of kit; I like
it.  And quite often, other people who are at the range want to talk
shop about it.  We get into discussions about roller-locked firearms
like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how
annoying it is when people get the terminology wrong, whether it's a
good thing or a bad thing the MP5 uses a fluted chamber, how anyone who
thinks it's okay to fire subsonic 9mm from the MP5 needs their head
examined, and so on and so on.  And it's fun, as far as it goes, and
it's often educational for the people who've never seen an MP5 before
and are fascinated to learn more about its inner workings.

It's great -- up until they think they know enough to use an MP5 on the
range, despite the fact they've never fired a weapon before.  At that
point we have to explain to them that look, yes, they know a lot more
about the MP5 than most people do, but really, they need to start off
with something small, like a nice .22 Ruger Mk II, develop the basic
skills, learn trigger discipline and proper usage of safeties, learn how
the range operates and what the various calls by the Range Safety
Officers mean, etcetera.  There's a huge amount to learn: they don't
need to make things worse by leaping straight over this stuff straight
to firing fully-automatic military hardware.  That's just imprudent, and
we'd be awful human beings if we permitted them to do that.

That's what we're talking about here.  The knobs and dials on GnuPG are
great fun to learn about: you're in good company!  But there's a big
reason why we're urging you to not do what you want to do, and that's
because you're not yet competent to do what you want to do.  We'd rather
see you start off with small steps, and from there move on to the big
ones, than have you start off big.

Admittedly, it's highly unlikely that screwing up with GnuPG will lead
to a magazine of 9mm being sprayed around the room.  But it's the
principle of the thing.  :)

So: for now, please stick with the defaults.

> It seems to me that, perhaps, making these sorts of decisions up front
> is of some value.

Not really.  It's probably not worth worrying about.

> If you create a primary key, upload it to a public
> keyserver and later decide: "hrm, my public key should really only
> certify, not sign," it's a bit too late.

No.

One of the important skills to learn early on is about how to migrate a
certificate.  You're going to make mistakes.  You'll forget passphrases,
you'll compromise your keys, you'll realize you made a hash of it and
need to start over again.  How do you recover from this?  How do you
communicate a change-of-certificate with your correspondents?  Etc.

The only reason to think "it's a bit too late" is if

a) you're not allowed to change your certificate -- you
   *must* keep the same one for the next X years
b) you don't know how to migrate to a new certificate

There are almost certainly people and groups for whom (a) applies.  If
you're one of them, please let me know.  But if (b) applies, then I
suggest learning the skill, because it's important.  :)

> It's also worth noting that the suggestion to remove the primary key
> from your laptop isn't thrown up on a few random blogs; instead it is
> something that other projects[1] encourage.

That wiki page is guidance *for Debian*.  Debian has some very specific
operating restrictions which are unlikely to apply to you.  The
guidelines Debian put together apply to them, in their environment,
facing their threat model, which they defend with their particular set
of resources.

It is not guidance for you, unless you're part of Debian.

By all means, study it!  It's a well-written policy.  Learn what goes
into their policy and why they make the decisions they do.  But don't
think that what they recommend will automatically apply to you.  Some of
it will be applicable; a lot of it won't be.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s).

Yes.  And, as several people here have told you, you correctly create it
by running "gpg --gen-key" and accepting the defaults.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Peter Lebbing]

On 23/11/15 17:20, James wrote:
> If you create a primary key, upload it to a public
> keyserver and later decide: "hrm, my public key should really only
> certify, not sign," it's a bit too late. (although not impossible,
> difficult to change ex post facto).

Okay, so let me answer this one detail:

Separating encryption from signing is a general advice (and done by
default) because there is a range of subtleties that are avoided by this
simple action. This affects how your keys are actually *used*, not *usable*.

However, one who has access to the private part of the primary key can
easily change the capabilities of the primary key to add signing as a
capability, even if you had it removed. There is not enough reason to
separate certifications from data signatures to make it the default.
Whether there is reason at all from a cryptographic standpoint, I do not
know. But it is certainly nothing to be worried about, or it would have
been dealt with in the defaults.

Also, let me quote and answer a part from an earlier mail you wrote:

> My concern is that if my primary key is for certification only, how
> would it sign other people's certificates to expand the web of trust?
> I suspect that if the capabilities are set to _only_ certify, I would
> need to sign other people's keys using my subkey.

No, signing other people's keys is known as certification, and is
something that can *only* be done by the primary key. If you have an
offline primary key, you would use an offline system that has the secret
part available to sign other people's keys, and then transfer the
signature from that offline system.

Or if you only delete the primary key from your laptop but still have it
on your desktop, you'd use the latter. For that setup, you could create
a signing subkey for your laptop to use without removing signing
capability from your primary key.

> It's also worth noting that the suggestion to remove the primary key
> from your laptop isn't thrown up on a few random blogs; instead it is
> something that other projects[1] encourage.

Yes, well, most importantly, maybe their threat model is different. In
this specific case, note that a signature by a Debian developer means
that, by and large, any Debian machine on the planet will trust the
software update that that signature validates and install it on the next
system upgrade. That's quite an important signature.

Normally, a Debian dev can only upload source code, not binaries, but
it's still a significant amount of power.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s). Thus being meticulous and careful
> in creating primary key seems like a reasonable step, IMHO.

Yes, but the defaults are sane, so there's no need to fiddle with things
that are different from the defaults. It's all the other stuff you
should be meticulous about.

Furthermore, all is not lost if you wish to swap your primary key. Many
people will accept a transition statement and issue a signature on your
new key. Also; the Web of Trust is overrated, and you can probably
persuade your friends more easily to recertify.

Cheers,

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Robert J. Hansen]

> - I believe that GPG has sane settings out-of-the-box, but prefer to
> verify that trust. ;) Why doesn't GPG set the digest algorithm to
> SHA512 instead of 256 out of the box?

For the same reason it doesn't default to RSA-4096: because the authors
are unconvinced there's a need.  Longer is not the same as better.  At
some point there's such a thing as enough.

SHA-256 is (a) safe enough for essentially all purposes, (b) more
interoperable with other OpenPGP implementations, and (c) better for
human readability.

> I'm also looking for some clarification around the primary key. Out of
> the box it appears that GPG will create a private key for signing and
> certification. Some documentation around the web indicates that the
> primary key can be stripped of all capabilities, leaving _only_
> certify. What are the pros and cons of allowing the private key only
> to certify, then creating a subkey to sign (and another to encrypt)?

I'm going to repeat my earlier advice: learn to walk before you run.
The defaults are safe.  Use them.  We can have this conversation at
great length, but I don't want to encourage you to start doing this.
Quite the opposite.  Please don't.

> thread); it appears that stripping the capabilities of the primary key
> to the bare minimum (i.e., no signing, no encrypting, no
> authenticating) would be "safer," no?

The last word in your sentence is the answer.

It's not safer.  You're talking about making a bank vault door "safer"
by adding a single millimeter of armor plate.  Your attention is better
spent elsewhere, especially right now when you're just starting out.
Focusing on the technical components of the system is ... I hate to say
"you're doing it wrong," but IMO, you are.  The stuff you're paying
attention to right now is pretty much irrelevant and unimportant.  The
stuff you're ignoring is relevant and important.  Start focusing on
that.  I'd start with:

* Do you have a revocation certificate generated?
* Is it stored safely?
* Who has access to your revocation certificate and/or private key?
* How would you know if someone else had access?
* How strong is your passphrase?
* How do you know how strong it is?
* What will you do if you forget your passphrase -- what's your
  fallback?
* If you revoke your certificate, how will you rebuild your personal
  web of trust?
* Is GnuPG integrated into your email workflow?  If not, how can it
  be integrated?
* Have you considered storing your certificate on a smartcard?

These are the places where GnuPG fails in the real world.  In 20+ years
of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever --
encountered anyone who has said, "man, I really wish I'd stripped my
certificate, that would've saved me no end of grief," and a lot of
people who have said, "man, I really wish I'd safely stored a revocation
certificate, that would've saved me no end of grief."


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Benjamin Black]

Among the privacy-concerned, there is a strong impulse to use the hardest
possible cryptography. The truth is that 2048-bit keys and a 256-bit hash
algorithm are completely secure against brute force attacks, and barring
any surprising developments in cryptanalysis, will remain so for a good
long time.

If someone is really motivated to invade your privacy, they are not going
to attack crypto, they are going to do an end-run around it by attacking
the rest of the system.  The choice of key size has never been the weak
point: it doesn't matter what size key you use if there is a key logger
installed on your system.

Watch this excellent presentation by Peter Gutmann about this subject at
Linux.conf.au 2015:
https://www.youtube.com/watch?v=_ahcUuNO4so


On Mon, Nov 23, 2015 at 9:25 AM James  wrote:

> All,
>
> I'm pleasantly surprised by the warm and helpful reception of this
> community to my many questions. Thank you all in advance for your
> detailed and thorough responses. The conversation thus far has been
> quite thought-provoking.
>
> I thoroughly read and re-read the responses in this thread, tinkered
> with GPG for many hours and poured over the documentation (again). I
> still have a few questions:
>
> - I believe that GPG has sane settings out-of-the-box, but prefer to
> verify that trust. ;) Why doesn't GPG set the digest algorithm to
> SHA512 instead of 256 out of the box?
> - I'm also curious why the default-preference-list isn't set to
> something more secure, as suggested here[1]:
>
> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> CAST5 ZLIB BZIP2 ZIP Uncompressed
>
> To be perfectly clear, I am sure the folks who made the decision to
> choose SHA256 is _far_ more intelligent than I am and there is sound
> reason behind these default choices. I simply would like to better
> understand these design decisions.
>
> I'm also looking for some clarification around the primary key. Out of
> the box it appears that GPG will create a private key for signing and
> certification. Some documentation around the web indicates that the
> primary key can be stripped of all capabilities, leaving _only_
> certify. What are the pros and cons of allowing the private key only
> to certify, then creating a subkey to sign (and another to encrypt)?
>
> To go a bit further down that rabbit hole, let's say I want to create
> a primary key (with certify-only capabilities), several subkeys and
> then remove the private key (as has been discussed ad nauseam in this
> thread); it appears that stripping the capabilities of the primary key
> to the bare minimum (i.e., no signing, no encrypting, no
> authenticating) would be "safer," no?
>
> My concern is that if my primary key is for certification only, how
> would it sign other people's certificates to expand the web of trust?
> I suspect that if the capabilities are set to _only_ certify, I would
> need to sign other people's keys using my subkey. How would this
> affect the notion of "even if you lose your subkeys, your identity and
> web of trust are not impacted as long as your primary key is not
> compromised?"
>
> Seems to me that the primary key /should/ have both certify and sign
> capabilities to really be useful, no?
>
> Any thoughts and ideas regarding these questions is greatly appreciated.
>
> James
>
> 1
> https://help.riseup.net/en/security/message-security/openpgp/best-practices
>
> On Wed, Nov 18, 2015 at 7:35 PM, da...@gbenet.com 
> wrote:
> > On 18/11/15 12:08, Peter Lebbing wrote:
> >> On 17/11/15 15:33, Andrew Gallagher wrote:
>  https://alexcabal.com/creating-the-perfect-gpg-keypair/
> >>>
> >>> This is a fairly good article - I've used it myself for reference in
> the
> >>> past. Also have a look at:
> >>
> >> I disagree, I'd recommend people not to read that article, let alone
> >> follow its advice.
> >>
> >> HTH,
> >>
> >> Peter.
> >>
> >> [1]
> https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html
> >>
> >
> > Peter,
> >
> > When you think about it - if a person stole your laptop with your
> private and public key on
> > it - they still could not use your private key to do anything. Security
> is in the passphrase
> > one sets to use your key. Without it your buggered and so is anyone who
> has acquired your
> > private and public key. They could spend a great deal of time and money
> - but essentially a
> > good passphrase is secure. Brute force - beating the shit out of you -
> may work - the human
> > link is the weakest in the chain.
> >
> > There is no perfect key - they are all "perfect" their security depends
> on your passphrase.
> >
> > Be Happy
> >
> > 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
> >
>
> 

Re: best practices for creating keys

[Peter Lebbing]

On 17/11/15 15:33, Andrew Gallagher wrote:
>> https://alexcabal.com/creating-the-perfect-gpg-keypair/
> 
> This is a fairly good article - I've used it myself for reference in the
> past. Also have a look at:

I disagree, I'd recommend people not to read that article, let alone
follow its advice.

He sounds convincing, but I'd much rather point people to Rob's answer
in this very thread[1] instead.

And just stick with the defaults.

By the way, this "Creating the perfect keypair" webpage has come up
multiple times on this list already. If you want some more thoughts
about it, use your favourite search engine.

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html

-- 
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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Robert J. Hansen]

> Is this accurate?

Not really, no.

One of the weirdest things about OpenPGP (and, by extension, GnuPG) is
that it provides a great deal of mechanism and very little in the way of
policy.  As a result, it's incredibly difficult to speak about best
practices in specific terms.  What's good practice for one person isn't
so for another.

> Below is an article that seems to discuss precisely this subject. It's
> a bit dated (2013), so am looking for clarification on whether or not
> this is the _best_ way to deal with GPG, key pairs, etc.
>
> https://alexcabal.com/creating-the-perfect-gpg-keypair/

The phrase 'perfect' in that link is a warning.  There is no such thing
as a perfect keypair.  Everything will always involve tradeoffs.  Those
who claim otherwise are usually charlatans.

It's worth noting, BTW, that the official guidance of the GnuPG project
is, "unless you know what you're doing and why you're doing it, stick
with the defaults."

8.1: Q.  Does GnuPG need to be 'tuned' before use?
 A.  No.  GnuPG has sensible defaults right out of the box.  You
 don't need to tune GnuPG before you can use it.

> I've seen a few other StackOverflow questions about this matter and
> they all seem to recommend the same thing: create one master key, a
> subkey (or more than one) and use those instead of the master key for
> signing as needed.

Don't.  Stick with the defaults.  You'll be happier, the learning curve
(which is already steep!) will be easier, and you'll enjoy wildly more
safe communications with people.  Once you've used GnuPG for a while,
have become familiar with how it does things and why, learned what
tradeoffs go into different decisions, and so on... at that point you
can generate a new keypair that's made just perfectly, exactly, the way
you like it.  :)

> (b) is this all really necessary? Aren't your private keys, when
> secured via a password, encrypted via AES256? If you have a super
> secure password / passphrase, is this all really necessary?

It depends.  For some people in particularly high-security applications,
yes, it's necessary.  For instance, the website kernel.org was
compromised a few years ago.  The prospect of an attacker being able to
insert a backdoor into the Linux kernel was so dramatic that a lot of
the kernel developers decided taking extreme steps was appropriate.
Can't fault them for it a bit.

On the other hand, if you're trading fantasy football picks with your
friends, those extreme steps would just be overkill.

> (b2) can someone please explain what sort of situation would be
> necessary for a private key that's been secured via a password is
> actually compromised? Are we talking about keyloggers, etc. here?
> Brute force? etc.

Keyloggers are a possibility.  So are $10,000-a-night hookers.  It all
depends on your enemy and how much in the way of resources they're
willing to throw at the task of acquiring your passphrase.

Everyone always thinks I'm joking about $10,000-a-night hookers,
incidentally.  I'm not.  If someone were to give me a $100,000 budget to
acquire a secret worth $1,000,000, hiring a high-class call girl for two
weeks would be a *damned* tempting attack vector.  People spend so much
time obsessing over technical minutiae of crypto, and so little time
realizing the weakest part of the system is always the human being... so
why not hire an expert in manipulating human beings?

This said, brute force isn't something you need to worry about.  A
strong passphrase will resist brute force for, quite possibly, longer
than the earth will exist.

> (c) if your "laptop keypair" (terminology from article above) is
> compromised, data encrypted against that subkey will be compromised as
> well, correct? The only benefit to creating subkeys is that you can
> then revoke the subkey using your original signing key and let the
> world know that you're still "in control" of your identity, correct?

That's the idea.  That said, this is just one way to solve the problem
of how to recover from a key compromise event.  There are many others.

> (d) let's say you've used the laptop keypair to encrypt a wide swath
> of data (emails, actual files, etc.). If you revoke the laptop subkey
> because it's been compromised, can you still use that compromised
> keypair to _decrypt_ the data, or is it lost forever?

You can use it to decrypt the data.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Pete Stephenson]

On 11/17/2015 1:32 PM, James wrote:
> All,
> 
> I'm just dipping my toes into GPG and am making a significant effort
> to "do things right" out of the gate.

Welcome!

> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offline" computer and then used only to revoke particular subkeys
> if needed.
> 
> Is this accurate?

At the risk of being vague, "best practices" depend on your situation.

The recommendations for someone wishing to exchange private love letters
with their spouse is far different than someone who would be subject to
physical harm, torture, etc. if the content of their messages were
revealed, or if an adversary were able to spoof messages appearing to
come from that person.

That said, using encryption and signing subkeys for day-to-day
operations and keeping your primary key safely stored and backed-up
offline is a reasonable and sensible thing to do in nearly all
circumstances.

> Below is an article that seems to discuss precisely this subject. It's
> a bit dated (2013), so am looking for clarification on whether or not
> this is the _best_ way to deal with GPG, key pairs, etc.
> 
> https://alexcabal.com/creating-the-perfect-gpg-keypair/
> 
> I've seen a few other StackOverflow questions about this matter and
> they all seem to recommend the same thing: create one master key, a
> subkey (or more than one) and use those instead of the master key for
> signing as needed.

Yes, this is a reasonable thing to do.

> I'm particularly confused regarding the lexicon used in the article
> above, mostly because of my ignorance (as the article is rather
> clearly written). The author indicates that:
> 
> - we create a keypair
> - added signing subkey
> - exported complete keypair _to TWO files_ (along with a revocation 
> certificate)
> - removed original signing subkey and stash that away safely (in a
> safe, offline)
> 
> My questions (and please forgive my ignorance):
> (a) when you create a the original keypair and export, it exports to
> _two_ files; how then, after adding another signing subkey, does the
> export also result in two files? Are both signing subkey keys
> (original and additional) embedded in your private key when exported?

The two files consist of, respectively, the (a) private and (b) public
components of that keypair.

In the directions provided at the link you mentioned, one creates the
primary key (which consists of the primary signing key and an encryption
subkey) and later creates a second signing subkey.

This bundle of three (sub)keys is exported for offline storage and
backup. There are separate exported files for the private components and
public components.

Later, the primary signing key is removed from the online system and
only the subkeys remain. If one later wished to backup this subkey-only
set of keys, they would be able to export the public components of all
three keys but only the private component to the subkeys. The private
component of the primary key would not be available for export since it
only exists in offline storage.

> (b) is this all really necessary? Aren't your private keys, when
> secured via a password, encrypted via AES256? If you have a super
> secure password / passphrase, is this all really necessary?

Yes, your private keys are encrypted and protected with your password.

However, this does little good if an adversary is able to compromise
your computer, copy the encrypted keyfile, and install a keylogger so
they know what password to use to decrypt it.

For typical users, this may not be an issue, but you never know.

In the case where a subkey is compromised, it can be easily revoked and
a new one generated.

In the case where one's primary key is compromised, it would also need
to be revoked and a new one generated, but it also means that one would
need to start from scratch to verify their identity to correspondents
and gain signatures from others -- the primary key represents one's
identity and reputation, so to speak, and rebuilding that can be
time-consuming and tedious.

Far better to take a few extra minutes generating a signing subkey and
moving the primary key to offline storage than dealing with the headache
of re-bootstrapping a new primary key.

> (b2) can someone please explain what sort of situation would be
> necessary for a private key that's been secured via a password is
> actually compromised? Are we talking about keyloggers, etc. here?
> Brute force? etc.

Assuming one has a strong password, brute force should be infeasible.

Keyloggers are a definite risk.

> (c) if your "laptop keypair" (terminology from article above) is
> compromised, data encrypted against that subkey will be compromised as
> well, correct? The only benefit to creating subkeys is that you can
> then revoke the subkey using your original signing key and let the
> world know that 

Re: best practices for creating keys

[Andrew Gallagher]

On 17/11/15 12:32, James wrote:
> 
> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offline" computer and then used only to revoke particular subkeys
> if needed.
> 
> Is this accurate?

Pretty much. You also need your primary private key if you want to
update the details of your public key (as it needs a self-signature) and
for certifying other keys (web of trust).

> Below is an article that seems to discuss precisely this subject. It's
> a bit dated (2013), so am looking for clarification on whether or not
> this is the _best_ way to deal with GPG, key pairs, etc.
> 
> https://alexcabal.com/creating-the-perfect-gpg-keypair/

This is a fairly good article - I've used it myself for reference in the
past. Also have a look at:

https://help.riseup.net/en/security/message-security/openpgp/best-practices
http://spin.atomicobject.com/2013/11/24/secure-gpg-keys-guide/

> My questions (and please forgive my ignorance):

Nothing to forgive!

> (a) when you create a the original keypair and export, it exports to
> _two_ files; how then, after adding another signing subkey, does the
> export also result in two files? Are both signing subkey keys
> (original and additional) embedded in your private key when exported?

The two files are the public key (including all public subkeys) and the
private key (including all private subkeys).

Think of your keypair as a pair of matching tree structures:

PUBLIC  | (private)

PRIMARY | (primary)
--SUB-- | (--sub--)
--SUB-- | (--sub--)
--SUB-- | (--sub--)

Each "key" (singular) really consists of multiple keys (plural), a
primary and some number of subkeys that are signed by the primary. This
singular/plural inconsistency in terminology is probably the confusing
bit. ;-) You can create as many subkeys as you like, but they can all be
considered part of your "key" (singular).

GPG will by default create a subkey marked usable for encryption only
(as there are attacks against keys that are used for both encryption and
signing). The best practice method above creates a separate signing-only
subkey so that you don't need to use your primary key for signing messages.

Your "laptop key" is then just your private key-tree with the primary
private key safely deleted.

> (b) is this all really necessary? Aren't your private keys, when
> secured via a password, encrypted via AES256? If you have a super
> secure password / passphrase, is this all really necessary?

You just answered yourself below. ;-)

> (b2) can someone please explain what sort of situation would be
> necessary for a private key that's been secured via a password is
> actually compromised? Are we talking about keyloggers, etc. here?
> Brute force? etc.

Keeping your primary private key offline does not help against brute
forcing, but it does protect against keyloggers, rootkits, physical
loss/theft etc. The only protection against brute force is key
complexity/length, but brute forcing a properly generated key is
vanishingly rare - you are much more likely to lose it by less glamorous
methods.

> (c) if your "laptop keypair" (terminology from article above) is
> compromised, data encrypted against that subkey will be compromised as
> well, correct? The only benefit to creating subkeys is that you can
> then revoke the subkey using your original signing key and let the
> world know that you're still "in control" of your identity, correct?

Correct. As you worked out yourself, it is of limited use in the case of
encryption subkeys (as anything encrypted against that key is now
exposed) but it is VERY useful for signing and authentication subkeys,
so long as you notice the loss and revoke them in a timely fashion.

> (d) let's say you've used the laptop keypair to encrypt a wide swath
> of data (emails, actual files, etc.). If you revoke the laptop subkey
> because it's been compromised, can you still use that compromised
> keypair to _decrypt_ the data, or is it lost forever?

You can continue to decrypt with a revoked encryption key. Revocation
does not make the private key unusable, it just marks the public key as
"do not use". Best practice is to regularly revoke your encryption
subkeys and regenerate them so that only a finite amount of data is
encrypted with each subkey, limiting the impact of a disclosure. How
often you want to do this is up to you - if you rarely get encrypted
emails it might not be worth your while, but if you are a heavy user
then I'd strongly recommend it.

Andrew.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for securely creating master RSA key

[Daniel Kahn Gillmor]

On 05/12/2014 03:35 AM, Tomer Altman wrote:

 You recommend creating a revocation certificate against the private key, but 
 the GPG documentation seems to recommend creating the revocation certificate 
 against the public (sub-)key:
 
 https://www.gnupg.org/gph/en/manual.html#REVOCATION
 
 What are the pluses and minuses of the two approaches?

I think they're not different approaches.  you need the secret key to
make a revocation certificate, but it applies to the full OpenPGP
certificate anchored by the primary key.

there are different kinds of revocations that you can make: a revocation
that revokes a subkey or a user ID is narrower than a revocation that
revokes a primary key.

If you still have exclusive access to the primary key, then you can
always issue one of the narrower certifications yourself directly.

So the only thing you need a revocation certificate for is for the
primary key.  Does that make sense?

 Also, do you know if such a set of recommended steps is documented somewhere. 
 I *swear* that I saw it somewhere on the myriad GPG webpages, but now I can't 
 seem to find it. If it does not exist, do you think it would be worthwhile to 
 add it somewhere, perhaps as a FAQ entry?

There are indeed lots of documents in existence that touch on these
ideas, but that's understandable since there is no one single best way
to create an OpenPGP certificate for ever: too many circumstances that
have different goals and requirements.  I think it's entirely legitimate
to write up a high-quality reasonable suggestion for a common use case
though, which is what it sounds like you're aiming for.

And maybe some (or all) of it should go in the FAQ, but i'll let Robert
(who maintains the FAQ, iirc) weigh in on that.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for securely creating master RSA key

[Robert J. Hansen]

And maybe some (or all) of it should go in the FAQ, but i'll let Robert
(who maintains the FAQ, iirc) weigh in on that.


I feel as if I should apologize in advance here, because this is going  
to be a little bit ranty -- Daniel is making a good point, though, and  
any incoherent fist-shaking at the universe that I may do is  
definitely not directed at him.


The GnuPG community is prone to bikeshedding on a truly mind-blowing  
scale.  It often seems to me that although there's general consensus  
on 90% of a subject, nobody can quite agree on what that 90% is.  If I  
present a ten-step process as being a good practice, I can rely on the  
vast majority of opinions being this seems pretty good on these nine  
points, but this tenth one absolutely has to go because it's wrong  
wrong wrong -- and no agreement whatsoever on which nine points are  
good and which tenth one must go.


Further, there is an unfortunate subset of the community that believes  
it has a monopoly on truth and that any disagreement is Jeoparding The  
Security Of The Entire Internet -- I capitalize that phrase because  
their emails to me often have that sense to them, as if every word was  
being emphasized just to make sure that I got it.


For that reason I'm generally not all that fond of weighing in on  
certain subjects, because they are so phenomenally divisive and  
generate so much more heat than light.  (Case in point: PGP/MIME,  
which resulted in *so* much flamefesting in my inbox that rather than  
give a single answer on the subject I threw up my hands, said to hell  
with it, and the FAQ entry basically says whatever you think, half  
the community will say you're wrong.)


Anyway: yes, this probably does warrant a FAQ entry, and I'll do my  
best to make changes and send Werner a revised version.  Look for it  
by the end of the week.  It may take a bit longer, depending on how  
quickly Amazon is able to ship me a new pair of asbestos longjohns...



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for securely creating master RSA key

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 10-05-2014 4:23, Tomer Altman escribió:
 To whom it may concern,
 
 I recall reading somewhere some best practices for creating one's
 initial RSA key pair that they intend for building their Web of
 Trust. I think the recommended steps were:
 
 1. Find a computer that you think is relatively free of malware 2.
 Download a Live Linux distro CD/DVD/USB, and verify its signatures
 to make sure you are not installing a tainted version 3. Launch the
 verified Linux distro. 4. Use GnuPG to create private RSA key, and
 two subkeys (signing  encrypting) 5. Strip the master private key
 from the keychain, saving on an encrypted medium (e.g., encrypted
 USB stick) 6. Create necessary revocation certificates, also save
 on encrypted USB stick 7. Copy over GnuPG keychain without master
 private key to work computer, personal laptop, etc. 8. Store
 encrypted USB stick somewhere safe

  You need to create the revocation certificates before removing the
primary key, since it is needed to create them.

   Also, I'd use paperkey to print my secret keys, I'd have them
protected by an easy to remember passphrase, since by the time you
need the paper backup, you may have changed your passphrase several
times, so... also, malware can't steal the printed key, so the
passphrase doesn't necessarily need to be bruteforce-proof (now, if
you think somebody may want you secret key so bad to do burglary...
then it must be a strong passphrase).

   To remove the primary key, what you do is to export the secret
subkeys, then backup your keys (and store them somewhere safe), delete
the key, and import the subkeys.

   If you are working on a live CD, the only malware that may
interfere is a tainted bios, something most people doesn't have to
worry about (but again, some people DO need to worry about it, I've
heard a hint about a non profit CA got a donated computer, and when
they checked it before using it, they found something nasty in the bios).

  I've been thinking maybe I should designate a revocation key
(somebody I can trust), but so far, I don't know anyone I know to
1.- Be willing to be my designated revoker.
2.- Know how to keep his key safe until I need him to revoke my key.
3.- Be careful enough to don't revoke my key by mistake.


   Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTb/czAAoJEMV4f6PvczxA3xcH/AzVrmqLNb9DBOGcHFd6l39+
SqeycMRQvmBUp4AcWle4HM1+2uxwsaeY2gCr+cxaM1CTjYN4HuN+bAJ/0ot86/sT
w9eysPD3yRS8mVj2q0ORj0Ic3lTXk3NdxNgWf0J/cL8LD2yfreWzLjeURK2cKk5b
8Q6PAX4p8u9XNPwvmw8PrwWTTyMBL9eVmq0VbNK/+K3k1qyxyPj+eFqB0PWD8TZB
43wQ2aL3gUHRP9d4y28LNtOgSKKtXKWgeQ7K9Pn/Fj+kBm0WdZGgUZYQlscYx9jv
rhCQQavRP0Lue+EOc6oJlZNvmfVrInsTsdku+tOz+6DfjeHyDpa1Cj6N0D2rza0=
=JNHf
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best practices for securely creating master RSA key

[Ingo Klöcker]

On Saturday 10 May 2014 01:23:57 Tomer Altman wrote:
 To whom it may concern,
 
 I recall reading somewhere some best practices for creating one's
 initial RSA key pair that they intend for building their Web of
 Trust. I think the recommended steps were:
 
 1. Find a computer that you think is relatively free of malware
 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures
 to make sure you are not installing a tainted version
 3. Launch the verified Linux distro.
 4. Use GnuPG to create private RSA key, and two subkeys (signing 
 encrypting)
 5. Strip the master private key from the keychain, saving on an
 encrypted medium (e.g., encrypted USB stick)

And/or store it on a smart card.


 6. Create necessary revocation certificates, also save on encrypted
 USB stick

Storing the revocation certificate together with the master private key 
is suboptimal. If you lose the USB stick or it stops working then you 
won't be able to revoke your master key. I suggest printing the 
revocation certificate on a piece of paper and storing it at a safe 
place. You could even print multiple copies and store them in different 
safe locations to reduce the risk of losing it through 
fire/water/theft/whatever. The worst that can happen if somebody gets 
hold of one of the copies is that he can revoke your key. That'd be 
annoying, but your data would still be protected.


 7. Copy over GnuPG keychain without master private key to work
 computer, personal laptop, etc.

And/or copy the private subkeys to a smart card.


 8. Store encrypted USB stick somewhere safe


Regards,
Ingo


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: Best practices for securely creating master RSA key

[Daniel Kahn Gillmor]

Hi Tomer--

On 05/10/2014 05:23 AM, Tomer Altman wrote:
 1. Find a computer that you think is relatively free of malware
 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make 
 sure you are not installing a tainted version
 3. Launch the verified Linux distro. 
 4. Use GnuPG to create private RSA key, and two subkeys (signing  encrypting)
 5. Strip the master private key from the keychain, saving on an encrypted 
 medium (e.g., encrypted USB stick)
 6. Create necessary revocation certificates, also save on encrypted USB stick
 7. Copy over GnuPG keychain without master private key to work computer, 
 personal laptop, etc.
 8. Store encrypted USB stick somewhere safe
 
 Can people comment on what I recalled correctly, and what needs to be 
 added/modified?

Your steps above seem pretty sensible to me, especially if you don't
already have a trust-worthy, trusted machine that runs gpg.  I would
only adjust the creation and storage of the revocation certificate(s).

first: i think you only need one revocation certificate, not several; in
particular, you should make a generic this key has been compromised
certificate for your primary key.  This certificate is capable of
invalidating all your user IDs and subkeys.

second: I don't think it makes sense to store the revocation certificate
on the same medium (the encrypted USB stick) as the primary secret key.

If you need to revoke, and the encrypted USB stick is still available to
you, then you can just use the primary secret key to generate a new
revocation certificate (which can even be clearer about the specific
reason for revocation, if you want it to be.

If you need to revoke, and the encrypted USB stick is not available
(e.g. it is physically lost, destroyed, or you no longer have access to
the passphrase), then you won't be able to get to the revocation
certificate.

So that suggests that you probably want to store the revocation
certificate someplace else.  I'd argue that you probably want it to be
*more* available than your master secret key.  If your revocation
certificate is compromised, the worst that an attacker can do is
invalidate your key.  This is a bad thing, but not nearly as bad as what
a compromise of the master secret key could do.

You could print out the revocation certificate and store it in a safe
place, or entrust it to a technically-proficient and responsible friend.
 Or do both :)

When printing, you could use plain ascii text (the armored certificate)
or you could pass it through a tool like optar (or other
machine-readable encoding mechanisms) to make it more easily recoverable
from paper.  I'm not sure that the machine-readability is particularly
useful.   It's a lot of work to type in an ascii revocation certificate
by hand (esp. with large RSA keys), but if you ever have good cause to
use your revocation certificate, you will probably have much more work
to do (repairing your digital identity) and typing in a dozen lines of
base64 will seem simple by comparison :P

All the best,

--dkg





signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Ingo Klöcker]

On Tuesday 14 December 2010, Robert J. Hansen wrote:
 Off by about a factor of 100 there.  RSA-2048 is roughly equivalent
 to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an
 80-bit key. 32 bits of difference equals a factor of four billion. 
 It's way harder than you think.

Those equivalences have been mentioned a few times. Is there a good 
(freely available) reference for this? Thanks in advance!


Regards,
Ingo


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: Best Practices

[Robert J. Hansen]

On 12/14/2010 4:11 AM, Ingo Klöcker wrote:
 Those equivalences have been mentioned a few times. Is there a good 
 (freely available) reference for this? Thanks in advance!

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf

Page 63.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Robert J. Hansen]

On 12/14/10 10:08 AM, ved...@nym.hush.com wrote:
 Does anybody who is careful about using a 256 symmetric cipher 
 actually use a 15k rsa key??

There are a few of them on the keyservers, IIRC.  Whether this is the
result of a deliberate and carefully chosen policy, or rampant paranoid
schizophrenia, is an open question...

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Ben McGinnes]

On 15/12/10 4:11 AM, Robert J. Hansen wrote:
 
 There are a few of them on the keyservers, IIRC.  Whether this is the
 result of a deliberate and carefully chosen policy, or rampant paranoid
 schizophrenia, is an open question...

They could be a result of using the old Cyber Knights Templar versions
of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys.


Regards,
Ben



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Ben McGinnes]

On 15/12/10 5:12 AM, Robert J. Hansen wrote:
 
 What tool was used really doesn't interest me very much -- you can
 create them with GnuPG, too, if you're willing to tweak the source a
 little bit. 

True, that one just made it a lot easier for people who did not
realise how easy it is to tweak the source code and recompile.

 What I find morbidly fascinating is contemplating what kind of
 deranged individual would actually do this.  :)

There are many deranged individuals on the Internet and many kinds of
them too.


Regards,
Ben



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Robert J. Hansen]

On 12/14/10 1:23 PM, David Shaw wrote:
 You sort of need a crystal ball to make that argument though...

To underline and agree with what David said -- the entire field of
communications security requires crystal balls.  It sounds neat and
simple to say, the weakest part of the system must be stronger than the
adversary's ability to break it, but in reality it's messy and complicated.

The weakest part of the system, in your estimation, may not be the same
as the weakest part in the enemy's estimation.  If you don't know what
your enemy's capabilities are, well, figuring out what the enemy will
consider weakest requires a crystal ball.

For that matter, you may not know who your enemies are.  If you're
worried about the FBI eavesdropping on your email, you might be totally
blind to J. Random Sysadmin who gets his jollies from planting
keyloggers on systems.  Just knowing who your enemies are requires a
crystal ball.

You may... etc., etc.  It's an incredibly difficult and Byzantine problem.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[John Clizbe]

Ingo Klöcker wrote:
 On Tuesday 14 December 2010, Robert J. Hansen wrote:
 Off by about a factor of 100 there.  RSA-2048 is roughly equivalent
 to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an
 80-bit key. 32 bits of difference equals a factor of four billion. 
 It's way harder than you think.
 
 Those equivalences have been mentioned a few times. Is there a good 
 (freely available) reference for this? Thanks in advance!

In the multiple subkeys and key transition thread, I wrote on 12/9/2010 at
16:28 (US/Central):
+ How do elliptic curves compare to RSA today?
+
+ From the National Institutes of Science and Technology (one of the gold
+ standards for engineering know-how):
+
+  RSAECCSym
+  1024   160 80
+  2048   224112  +
+  3072   256128
+  7680   384192
+ 15360   512256
+
+ These recommendations can be found on page 63 of NIST Special
+ Publication 800-57, Recommendations for Key Management, Part I. 2nd Revision,
+ 8 Mar, 2007.
+
[http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf]
 

-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=help

Q:Just how do the residents of Haiku, Hawai'i hold conversations?
A:An odd melody / island voices on the winds / surplus of vowels



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 14-12-2010 15:12, Robert J. Hansen escribió:
 On 12/14/10 12:42 PM, Ben McGinnes wrote:
 They could be a result of using the old Cyber Knights Templar versions
 of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys.
 
 What tool was used really doesn't interest me very much -- you can
 create them with GnuPG, too, if you're willing to tweak the source a
 little bit.  What I find morbidly fascinating is contemplating what kind
 of deranged individual would actually do this.  :)

  Well, somebody could think if they made a 256 bits symmetric algo,
there should be a reason for that. And since if the asymmetric key is
broken, the message is decrypted, no matter how strong is the symmetric
algo, then it makes sense to use something equally strong.

  Now I think about it, AES-256 would be also an overkill, and the only
reason why we don't think it is a bad idea, is because we don't notice a
reduction in performance (with normal usage) compared with AES-128.

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNB/+jAAoJEMV4f6PvczxAg74H/RF9GLennMUSPZ79pEHcSuWz
zdIwDVbuXmZ3KXopADGlF6QMr9LX1jJjtWFoLSA7/BVXu/DfqX263uwixfMP+Xvz
FZL90hhzaU410Nt6xdgenRqORQnzRuyVKYmpj5psBNVeedsE+yY3tcRVIKNy9ePi
chdPrK/vwQ47Aq6+a8VBnCKhXlcFwo3rXQKgFgzy17fRuIhrbgu8Dany4TosWFwP
xNdo4Cdje6Na1RzKgkKiHORZzROzFV+OKQioy+yJPKEjYDmj566djNNWgU2Pu/ZZ
VbHEIR1kQX7P4idJv0BJmgfVUUMGlHJWgSj2k6IRy+w5pKRZuY7N8I5PUXr7JUI=
=FxHq
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Robert J. Hansen]

On 12/14/2010 6:37 PM, Faramir wrote:
   Well, somebody could think if they made a 256 bits symmetric algo,
 there should be a reason for that. And since if the asymmetric key is
 broken, the message is decrypted, no matter how strong is the symmetric
 algo, then it makes sense to use something equally strong.

Sure.  But someone could also think, since they make both high proof
whiskey and fast cars, and they're each perfectly safe, there's no harm
in mixing them.

Thinking, if they make a 256-bit symmetric algo, there should be a
reason for that, is quite correct as far as it goes.  Thinking its
existence means you need to use it, though, is not.  :)



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Robert J. Hansen]

On 12/14/2010 6:43 PM, Faramir wrote:
   I know I asked before, but I can't remember if I saw an answer. Is
 TwoFish implementation the 256 bit key version?

Yes.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 14-12-2010 15:23, David Shaw escribió:
...
 There is a weak safety factor argument, too.  If it turns out that (for 
 example) AES-256 isn't as strong as expected, it may well be that AES-256 is 
 actually a good match to RSA-2048, and you were wise to use it instead of 
 AES-128 (which given the same imaginary attack would be weaker than 
 RSA-2048).  You sort of need a crystal ball to make that argument though...

  I wish I had read that message before writing my last reply XD

  I know I asked before, but I can't remember if I saw an answer. Is
TwoFish implementation the 256 bit key version?

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNCAE6AAoJEMV4f6PvczxAtqIH/3a+8kwHqB9WuHDScknpwx+M
PCaquhrAoSKbZP06NG/+BH7wq4ChDBz2TLAy0MyUDdu9pb7uQWbu2btppubzxJBB
/zJ81qPBg/n1nBLlQ98UMYgIihxriuf+tC4x3JL7t0MhRrt/UaYEZwjdW/Xk1mRn
hJKZOiZdaGU23OcIVB4kcQIOo+yUYUatWIgsQDQSKJ2CGAxiWObW1hAaTMh/ZFa+
ppsfB859ULz4mXd85zsOqzrDMQaMRMCZmhJwLmODjspiQb1p5dl5K85PGDVnIt5F
shEqgctt3FxEWr4XvLwfrOm+kUwqijxbunWXT5XHqAIher6GwyKFR918A8+bkEE=
=ZJ7N
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices

[David Shaw]

On Dec 14, 2010, at 6:43 PM, Faramir faramir...@gmail.com wrote:

  I know I asked before, but I can't remember if I saw an answer. Is
 TwoFish implementation the 256 bit key version?

Yes it is.

David

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 13-12-2010 22:30, Robert J. Hansen escribió:
 On 12/13/2010 5:48 PM, Faramir wrote:
 But supposedly, even with all these botnets, RSA-1024 has not been
 broken yet. I don't know if there is some r...@home
 
 The Berkeley BOINC framework can be pretty easily adapted to do this.

   Ah, good hint, I found n...@home, a project to factor large integers...
   There is also eni...@home, but that is a bit old fashioned ;)

   I think I'll stay with fold...@home

 thing is breaking RSA-2048 would require about 10.000.000 times more
 power than breaking RSA-1024, which -so far as we know- has not been
 broken yet
 
 Off by about a factor of 100 there.  RSA-2048 is roughly equivalent to a
 112-bit symmetric key; RSA-1024 is roughly equivalent to an 80-bit key.
  32 bits of difference equals a factor of four billion.  It's way harder
 than you think.

  Ok, that's even better ;) I took the MIPS-years estimation to break
RSA-1024, the estimation for breaking RSA-2048, and divided.

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNCCLfAAoJEMV4f6PvczxAdm0H/1uvdoRRiiYoPUYVH4TbzGaV
LsK4b2URAzq7e51vjPqx3RfTsPSDLiKUP1aRyJXmAWiyLI5gftXhjT5wshc78BDQ
OEiP+BEVwe4Dh6mpVtODSUm8lpNcG5rViOAnRxE2nh/PYryZSyJcP/ipylGtxNVI
EDUAj3RYxQ5Vzpl+D3ouri33E+2FpG7XetHRoh/v/eCxyTccWHFHYa+T7U4HMFuJ
D7XTx337CFRsmkPgI7AMPgaENY9z3f+5IISeM4Ld0m/cyspl28IbG9ajk6GmHs8Z
6W/62xPwnWfWYqyxDxOXZ9ulftONkziWSyBpMuMdtBkigeelQbfnP6ztljTXZ8k=
=ln/S
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Ingo Klöcker]

On Monday 13 December 2010, Faramir wrote:
 El 10-12-2010 11:41, Robert J. Hansen escribió:
 ...
 
  Add a new UID and revoke the old.  You don't need to generate a new
  certificate.  RSA-4K is, IMO, phenomenal overkill for the vast
  majority of users.  Breaking RSA-2K is believed comparable in
  difficulty to breaking 3DES, and that prospect is ... let's just
  say implausible.
 
   Based on Schneier's estimations in Applied Cryptography, Second
 Edition, I calculated breaking RSA 2048 would be between 1E7 and 1E9
 times harder than breaking RSA 1024 (I divided the MIPS required to
 break RSA 2048 by the MIPS required to break RSA 1024).
 
   I know the book is old, and the estimations might be wrong, but
 still... there is a huge difference between breaking RSA 1024 (which
 so far has not happened), and breaking RSA 2048. It's not like
 saying it would require 2 times more computing power, it's several
 orders of magnitude harder.
 
   If RSA 1024 becomes breakable today, and after that factorizing
 keys become 1000 times easier that it is today, and computers become
 1000 times more powerful, they would still need at least 10 times
 more power to break RSA 2048. Yes, a lot of if's, but still useful
 to give an idea about how harder it would be.

Well, s...@home claims to have over 3 million users. Large botnets have 
tens of thousands slaves. GPUs are in some areas several magnitudes 
faster than CPUs. There go your several orders of magnitude.


Regards,
Ingo


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: Best Practices

[Werner Koch]

On Mon, 13 Dec 2010 01:27, ds...@jabberwocky.com said:

 The fix in OpenPGP is to hash the contents of the secret key, so any 
 tampering is evident.

FWIW: We verify a signature immediatley after its creation which also
thwarts this attack.

 I am also skeptical of this.  I strongly doubt that new fingerprints
 can be achieved without going to a V5 key format.  There are just too
 many interoperability gotchas with an upgraded V4.  We might be able

Switching to V5 will be a lot of work in GnuPG because under the hood we
need to replace a lot of data structures which use a 160 bit hash.  It
will eventually be done but before we do that we need SHA-3; lets talk
about this in 2 years.  Recall that the rush towards SHA-256 is due to
collisions on SHA-1 expected in the near future.  There are no signs at
all that we will have a pre-image attack on SHA-1 any time soon [1].


Shalom-Salam,

   Werner


[1] #include famous-last-words.h
-- 
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: Best Practices

[David Shaw]

On Dec 12, 2010, at 11:50 PM, Daniel Kahn Gillmor wrote:

 Can you help me understand why a change in the choice of fingerprint
 technique and a change in the must-implement-digest-algorithm would
 require a change in the certificates themselves?

It doesn't work that way.  If you want to make a proposal, I'm all ears, as are 
the folks on the IETF list, but it seems to me you are focusing on one specific 
part of the design (the secret key format), forcing it to remain unchanged, and 
(presumably) using changes elsewhere to accommodate this fixed point in the 
design (for example, doubled PKESK packets, one for each key ID).

As I see it, three major things need to happen to get OpenPGP using something 
other than SHA-1:

1) SHA-3 needs to exist: we will almost certainly use SHA-3, but even if we 
don't, we should wait until the SHA-3 reports are in.  SHA-3 is a major amount 
of effort focused on hashing.  It would be foolish to design something new 
involving hashing without using the latest research.
2) We need OpenPGP changes to incorporate the new hash in a way that works 
alongside the existing design.  It's not as easy as s/SHA-1/SHA-3/, 
especially given the deployed base of OpenPGP programs.
3) We need to roll out those changes in a way that won't break things.  We're 
going to be running with SHA-1 and SHA-3 together for (at least) years.

Even if we assume that there will be no other unrelated changes at the same 
time (an assumption I'm not willing to make - everyone has the half-dozen 
fiddle things (like hard expiration dates) that they think could be better, but 
aren't really worth fixing unless there is a key version jump), I'm still not 
willing to go into the design process in step 2 with the assumption that 
changing the secret key format is somehow off-limits.  (And mind you, we 
haven't even reached step 1 yet!)

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[David Shaw]

On Dec 13, 2010, at 12:23 PM, Daniel Kahn Gillmor wrote:

 Avoiding a systemic change to the certificate format seems like it would
 be a Good Thing in that people could participate in a global smooth
 transition, without requiring a hard cut-over or a global interruption
 of existing networks of identity verification.

Why is it that using the method you advocate, there is a graceful changeover 
between fingerprint formats, but a change in the certificate format requires a 
hard cut-over with global interruption of existing networks... ?  That's a 
straw man.  Who is advocating a hard cut over or any interruption whatsoever?  
Personally, I suspect a changeover would take somewhere between 5 and 10 years, 
just as the v3-v4 changeover did.

It is premature to try and force a particular format into the design before we 
even have a SHA-3 to talk about.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Daniel Kahn Gillmor]

On 12/13/2010 01:13 PM, David Shaw wrote:
 Why is it that using the method you advocate, there is a graceful
 changeover between fingerprint formats, but a change in the
 certificate format requires a hard cut-over with global
 interruption of existing networks... ?

I was assuming that new certificates come with new keys, and that new
keys could not certify or be certified by existing (old) certificates.

Are v3 keys able to certify or be certified by v4 certificates?

 I suspect a changeover would take somewhere between 5 and 10 years,
 just as the v3-v4 changeover did.

That sounds like what i would expect as well.

 It is premature to try and force a particular format into the
 design before we even have a SHA-3 to talk about.

i agree.  That's why i've been proposing that people transition to new
algorithms without trying to wait for a format change that is likely to
take years to even begin, plus many more years to complete.

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[David Shaw]

On Dec 13, 2010, at 4:40 PM, Daniel Kahn Gillmor wrote:

 On 12/13/2010 01:13 PM, David Shaw wrote:
 Why is it that using the method you advocate, there is a graceful
 changeover between fingerprint formats, but a change in the
 certificate format requires a hard cut-over with global
 interruption of existing networks... ?
 
 I was assuming that new certificates come with new keys, and that new
 keys could not certify or be certified by existing (old) certificates.
 
 Are v3 keys able to certify or be certified by v4 certificates?

Sure, in both directions.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 13-12-2010 7:10, Ingo Klöcker escribió:
 On Monday 13 December 2010, Faramir wrote:
...
   If RSA 1024 becomes breakable today, and after that factorizing
 keys become 1000 times easier that it is today, and computers become
 1000 times more powerful, they would still need at least 10 times
 more power to break RSA 2048. Yes, a lot of if's, but still useful
 to give an idea about how harder it would be.
 
 Well, s...@home claims to have over 3 million users. Large botnets have 
 tens of thousands slaves. GPUs are in some areas several magnitudes 
 faster than CPUs. There go your several orders of magnitude.

  But supposedly, even with all these botnets, RSA-1024 has not been
broken yet. I don't know if there is some r...@home, but anyway, the
thing is breaking RSA-2048 would require about 10.000.000 times more
power than breaking RSA-1024, which -so far as we know- has not been
broken yet, they would need a botnet a lot bigger...

  I searched in google, and found a paper doing estimations about how
many MIPS-year would a botnet have on year 2007. Based on that
assumption, they calculated how much time would it take to break 1
RSA-1024 key. I searched by MIPS year botnet (without the  marks),
and the first result is the paper, named Spam, Phishing, and the
Looming Challenge of Big Botnets, by René H. Hemmingsen. Department of
Computer Science. University of Copenhagen, Denmark.

  Pages 7 to 9.

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNBqLRAAoJEMV4f6PvczxAjtgH/iQifbgqqiWX7n9Q9cI4cNA3
II4dc4gLlOcDrcnyW87+x1NkYZQ04Fb+YYCu4rJCZH6EzGjK9AxTbZ7xEabIn19c
rhUC18S7JKBRHRs5Sq+uaGrhpxPyTD/5shblzxoQdXBLzlGrucDhaRhdps69SIqi
dOMWRQgIZj+qEyMSBiNBoxaf30UdOCs4hGEJKRkPrqUUIXlVcUqpSuxZ/i3odOHr
UHoOaFd2Rlai59i1Co0qw/+WfC/JK7Cn4ETjsmx1lPC1D9LPIfoWqhgVQPJAkqgo
K5oJNRexBDOZUCkBXiHl4yA04dNc/uiDeTiTOj0KT0MMNtBRK7Shm0HBR5nX+AY=
=3/dq
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/13/2010 12:23 PM, Daniel Kahn Gillmor wrote:
 Avoiding a systemic change to the certificate format seems like it would
 be a Good Thing in that people could participate in a global smooth
 transition, without requiring a hard cut-over or a global interruption
 of existing networks of identity verification.

*What* hard cut-over or interruption of existing networks?  The v3/v4
transition was seamless because there was neither a cut-over date nor an
interruption: people migrated at their own pace, when they were ready
to, and not before.  v3 keys are still used today, although they're
increasingly niche.

v4/v5 will coexist the same as v3/v4 coexist.  In fact, it's quite
likely v3 and v5 will coexist.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/13/2010 4:40 PM, Daniel Kahn Gillmor wrote:
 i agree.  That's why i've been proposing that people transition to new
 algorithms without trying to wait for a format change that is likely to
 take years to even begin, plus many more years to complete.

And no one is arguing against this.  All people are arguing against is,
I want to migrate to a new certificate in order to avoid SHA-1.  To
the extent it is possible to avoid SHA-1, it can be avoided today
without migrating to a new cert; and for the rest, it cannot be avoided
today even if one migrates to a new cert.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/13/2010 5:48 PM, Faramir wrote:
 But supposedly, even with all these botnets, RSA-1024 has not been
 broken yet. I don't know if there is some r...@home

The Berkeley BOINC framework can be pretty easily adapted to do this.

 thing is breaking RSA-2048 would require about 10.000.000 times more
 power than breaking RSA-1024, which -so far as we know- has not been
 broken yet

Off by about a factor of 100 there.  RSA-2048 is roughly equivalent to a
112-bit symmetric key; RSA-1024 is roughly equivalent to an 80-bit key.
 32 bits of difference equals a factor of four billion.  It's way harder
than you think.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Laurent Jumet]

Hello David !

David Tomaschik da...@systemoverlord.com wrote:

 In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings):
 personal-digest-preferences SHA512
 cert-digest-algo SHA512
 Are there any other settings (or changes to these) that would be considered
 more forward looking?

Hello !

To set the preferences, this can help:

   ??
   ? Cipher-Algos:? Digest-Algos:? Compress-Algos:  ?
   ??
   ?  ?  ? Z0  Uncompressed ?
   ? S1  IDEA ? H1  MD5  ? Z1  ZIP  ?
   ? S2  3DES ? H2  SHA1 ? Z2  ZLIB ?
   ? S3  CAST5? H3  RIPEMD160? Z3  BZIP2?
   ? S4  BLOWFISH ?  ?  ?
   ?  ?  ?  ?
   ?  ?  ?  ?
   ? S7  AES  ?  ?  ?
   ? S8  AES192   ? H8  SHA256   ?  ?
   ? S9  AES256   ? H9  SHA384   ?  ?
   ? S10 TWOFISH  ? H10 SHA512   ?  ?
   ? S11 CAMELLIA128  ? H11 SHA224   ?  ?
   ? S12 CAMELLIA192  ?  ?  ?
   ? S13 CAMELLIA256  ?  ?  ?
   ??

Those are my settings in GPG.CONF:

default-preference-list S7 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z3
Z2 Z0
personal-cipher-preferences S7 S1 S10 S3 S4 S2 S9 S8
personal-digest-preferences H3 H8 H9 H10 H11 H2 H1
personal-compress-preferences Z1 Z3 Z2 Z0

As you can see, you can replace the whole name by its tag.
When you change the settings, you must edit and save your public key and 
reload it on the servers; otherwise those changes will not work as they will 
stay internal in your system.

-- 
Laurent Jumet
  KeyID: 0xCFAF704C

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Daniel Kahn Gillmor]

On 12/11/2010 11:24 AM, Robert J. Hansen wrote:

 A certificate is just a block of key material plus some associated data.
  SHA-1 is used internally by the certificate to sign some parts of the
 data

Really?  i've got several certifications over my key's user IDs that i'm
pretty sure don't use SHA1 at all.

i note that gpg seems incapable of certifying subkeys using anything
other than SHA1, but that doesn't seem required by the standard.

What part of OpenPGP certificates require SHA-1?

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/12/2010 3:34 AM, Laurent Jumet wrote:
 As you can see, you can replace the whole name by its tag.

But why would you want to?

Humans should use tags convenient for humans.  Machines should use tags
convenient for machines.

 When you change the settings, you must edit and save your public key
 and reload it on the servers; otherwise those changes will not work
 as they will stay internal in your system.

Not if all he's changing are the personal-*-preferences.





smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Daniel Kahn Gillmor]

On 12/12/2010 11:21 AM, Robert J. Hansen wrote:
 On 12/12/2010 10:23 AM, Daniel Kahn Gillmor wrote:
 What part of OpenPGP certificates require SHA-1?
 
 ... At first blush, V4 certificate checksums,

what do you mean by V4 certificate checksums?

 symmetrically encrypted
 integrity protected data packets, the MDC system in general

These are not part of the OpenPGP certificate format.

 certificate fingerprints, etc.

yeah, this is serious, but it's not embedded in the certificate.  if we
were to come up with a new fingerprint format, it would not invalidate
any existing certificates -- it would just change how we refer to them.

 Probably the most annoying -- to me, at least -- is the fingerprint
 requirement.  If a preimage collision is discovered in SHA-1 then it's
 all over.  I can take your signature on my enemy's key, graft it onto my
 own impersonator of my enemy's key, and then get others to believe it.

agreed.  but this is not part of the certificate format.

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote:
 what do you mean by V4 certificate checksums?

Read the RFC.  It's in there, and does a better job than I can do of
explaining it.  Section 5.5.3.

 yeah, this is serious, but it's not embedded in the certificate.  if we
 were to come up with a new fingerprint format, it would not invalidate
 any existing certificates -- it would just change how we refer to them.

I am very skeptical of this claim you seem to be making, that we can
just upgrade-in-place.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Daniel Kahn Gillmor]

On 12/12/2010 03:51 PM, Robert J. Hansen wrote:
 On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote:
 what do you mean by V4 certificate checksums?
 
 Read the RFC.  It's in there, and does a better job than I can do of
 explaining it.  Section 5.5.3.

i thought that you might be referring to 5.5.3, but that is also not
part of the OpenPGP certificate format.

It's part of the secret key packet format, and it's not a part that is
cryptographically-signed either.  It looks to me like that checksum is a
way to verify that you've decrypted the key properly, and it's made over
material that you generated yourself.   If you've retained physical
control over your secret key material, this is certainly not a
cryptographic concern.

 yeah, this is serious, but it's not embedded in the certificate.  if we
 were to come up with a new fingerprint format, it would not invalidate
 any existing certificates -- it would just change how we refer to them.
 
 I am very skeptical of this claim you seem to be making, that we can
 just upgrade-in-place.

We can (and some of us do) use OpenPGP certificates and exchange
encrypted and signed material without relying on SHA-1 already.

The *fingerprint* format probably will need to change eventually (though
i haven't seen any indication of preimage attacks against SHA1 yet), and
the designated revoker subpacket is acknowledged to need an overhaul.
But you still haven't pointed to anything within the OpenPGP
*certificate* format itself that embeds SHA-1.

RFC 4880 mandates SHA-1 as a must-implement for compliant
implementations, but (aside from the rarely-used designated-revoker
subpacket) it doesn't require you to actually use it anywhere in the
certificates, as far as i can tell.  If i'm wrong about that, i
certainly hope to be made aware of it.

Again, the entire reason i'm engaging in this thread is to encourage
people to move to stronger cryptographic algorithms *today*.  I see no
good reason to wait for a new revision of the OpenPGP specification to
take advantage of stronger algorithms now.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/12/2010 6:37 PM, Daniel Kahn Gillmor wrote:
 We can (and some of us do) use OpenPGP certificates and exchange
 encrypted and signed material without relying on SHA-1 already.

Not so long as you're looking up key IDs by fragments of SHA-1 hashes,
you're not.

 Again, the entire reason i'm engaging in this thread is to encourage
 people to move to stronger cryptographic algorithms *today*.

That's not the point of this thread.  In fact, as near as I can tell
that's *never* been the point of this thread.  The original poster
wanted to create an entirely new certificate in order to migrate, and my
advice to him was that if he wanted to create an entirely new
certificate that he should wait until the next revision, otherwise he'd
likely be doing another new certificate in a year or two.

I have *never* claimed that we shouldn't move away from SHA-1.  Heck, I
was even the one who told the original poster to use enable-dsa2 in
order to get access to the stronger hash algorithms.

I maintain my original point: if you're thinking of creating an entirely
new certificate just in order to get access to better hash algorithms,
then you are best off waiting for the new revision: otherwise, use the
existing technologies.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Ben McGinnes]

On 13/12/10 10:52 AM, Robert J. Hansen wrote:
 
 I have *never* claimed that we shouldn't move away from SHA-1.  Heck, I
 was even the one who told the original poster to use enable-dsa2 in
 order to get access to the stronger hash algorithms.

Actually, I'm pretty sure that recommendation appeared in the key
transition thread I started on Thursday.  It's working very well for me
and I probably will hold off on the transition since the SHA-3 progress
appears to be sticking to their timetable after all.  ;)


Regards,
Ben



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[David Shaw]

On Dec 12, 2010, at 3:51 PM, Robert J. Hansen wrote:

 On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote:
 what do you mean by V4 certificate checksums?
 
 Read the RFC.  It's in there, and does a better job than I can do of
 explaining it.  Section 5.5.3.

Ah, I also wasn't sure what you were referring to.

The checksum in 5.5.3 is to foil the Klima-Rosa attack (see 
http://eprint.iacr.org/2002/076 for the whole paper).  Briefly, though, it 
means that if an attacker can get access to your secret key, they can modify it 
slightly and then wait for you to issue a signature.  Once they see a signature 
issued from the modified key, they can reconstruct the secret key.  The 
passphrase on your secret key does not protect against this.

It's a very interesting attack, though if someone had access to your computer 
where your secret key lived, there is a whole load of other stuff they could do 
besides tamper with your secret key and wait for you to issue a signature. :)

The fix in OpenPGP is to hash the contents of the secret key, so any tampering 
is evident.

 yeah, this is serious, but it's not embedded in the certificate.  if we
 were to come up with a new fingerprint format, it would not invalidate
 any existing certificates -- it would just change how we refer to them.
 
 I am very skeptical of this claim you seem to be making, that we can
 just upgrade-in-place.

I am also skeptical of this.  I strongly doubt that new fingerprints can be 
achieved without going to a V5 key format.  There are just too many 
interoperability gotchas with an upgraded V4.  We might be able to fight our 
way through them, but therein lies extra complexity and confusion for the 
implementer and user, which is not what is wanted for a secure system.

V5 has the advantage of cleanliness and simplicity: there is no 
interoperability.  Which doesn't mean that you couldn't have V4 alongside V5 
for a period of time, just as we had V3 alongside V4 for at least a decade.  
The WoT would survive this just as it survived the V3-V4 transition.  As V4 
ramped up, V3 died out.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

El 10-12-2010 11:41, Robert J. Hansen escribió:
...
 Add a new UID and revoke the old.  You don't need to generate a new
 certificate.  RSA-4K is, IMO, phenomenal overkill for the vast majority
 of users.  Breaking RSA-2K is believed comparable in difficulty to
 breaking 3DES, and that prospect is ... let's just say implausible.

  Based on Schneier's estimations in Applied Cryptography, Second
Edition, I calculated breaking RSA 2048 would be between 1E7 and 1E9
times harder than breaking RSA 1024 (I divided the MIPS required to
break RSA 2048 by the MIPS required to break RSA 1024).

  I know the book is old, and the estimations might be wrong, but
still... there is a huge difference between breaking RSA 1024 (which so
far has not happened), and breaking RSA 2048. It's not like saying it
would require 2 times more computing power, it's several orders of
magnitude harder.

  If RSA 1024 becomes breakable today, and after that factorizing keys
become 1000 times easier that it is today, and computers become 1000
times more powerful, they would still need at least 10 times more power
to break RSA 2048. Yes, a lot of if's, but still useful to give an idea
about how harder it would be.

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEbBAEBCAAGBQJNBWqvAAoJEMV4f6PvczxAasYH92kLwCf2y9A5LvwQlLd/G2d4
jiUQ8PK922yAJ9UnjqAhJOoKJ3AtZw3URYp9IXGNJpUSgI1OSUVX5KHkCCwxaZWq
NZ5m/8euHkqLd6PBqDWlHnK0lrkgEj0kUZyvSs0iceFwCt+WR7vp9QT1kAqC3kTN
FCXGYKJzIhs8IkzYbYdD4BY6Lm4natCpN6mvA9btaF/Yi4UEyknu2Nmc1NCRlojY
8WfjdzNmFNWZH/ulkVRlfUgUF+gaFBZvuxByyCbFq0U4JwDwEfn34C2WXtamEDBd
wXGdXu7J5NN6ZHsN2iiKdFMmwdXop1iaAKy1/aOilw0W/bpuO3J2i1K4yBdK7w==
=hm7Y
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[David Shaw]

On Dec 12, 2010, at 11:21 AM, Robert J. Hansen wrote:

 On 12/12/2010 10:23 AM, Daniel Kahn Gillmor wrote:
 What part of OpenPGP certificates require SHA-1?
 
 ... At first blush, V4 certificate checksums, symmetrically encrypted
 integrity protected data packets, the MDC system in general, certificate
 fingerprints, etc.  I just grepped through the RFC looking for any
 hardcoded SHA-1; David is probably a much better reference than I am on
 this.
 
 Probably the most annoying -- to me, at least -- is the fingerprint
 requirement.  If a preimage collision is discovered in SHA-1 then it's
 all over.  I can take your signature on my enemy's key, graft it onto my
 own impersonator of my enemy's key, and then get others to believe it.

Yes.  The other uses of SHA-1 are not nearly as significant as the fingerprint 
(and thus key ID).  For example, it's true that the MDC uses SHA-1, but no big 
deal - just make a new MDC that uses whatever you like, and repeat as needed.  
Virtually all deployed code will handle this correctly (for example, a feature 
flag indicating the existence of the mdc2 capability), and use it only when 
all participants can handle it.

The fingerprint issue is more than just making a new packet for a new MDC or 
revocation subpacket, though.  There is no concept in OpenPGP of a flag telling 
an implementation how to calculate the fingerprint - or rather there IS a flag: 
the version field, but its hardcoded :)

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Daniel Kahn Gillmor]

On 12/12/2010 11:03 PM, David Shaw wrote:
 The fingerprint issue is more than just making a new packet for a new MDC
 or revocation subpacket, though.  There is no concept in OpenPGP of a flag
 telling an implementation how to calculate the fingerprint - or rather
 there IS a flag: the version field, but its hardcoded :)

In the discussion last year on the IETF list, the general consensus
seemed to be that the fingerprints of primary keys were not endangered
by a weakening of SHA-1's collision resistance.  (This is in stark
contrast to digital signatures and certifications, where weakened
collision resistance in an algorithm represents a real threat [0]).
But as far as i know, no one has yet reported a significant practical
concern about SHA-1's resistance to a pre-image attack, which suggests
that reliance on SHA-1 for fingerprints is probably reasonable until
SHA-3 is selected.

Nonetheless, the purpose of the fingerprint is just to help humans
identify and communicate keys.  It is not embedded in the parts of the
spec for any part of the certificate format (aside from desig-revoker,
an acknowledged flaw in RFC 4880).  So i see no reason that when SHA-3
comes out, we couldn't define a new form of fingerprint (call it v5 if
you want) based on SHA-3, produce/consume that fingerprint alongside the
traditional v4 fingerprint for a reasonable time period, stop producing
v4 fingerprints, and then ultimately stop consuming v4 fingerprints.
Presumably when rolling out the new fingerprint format, we'd also
specify that SHA-3 is the new must-implement digest for compliant
implementations.  Clearly, anyone capable of providing an SHA-3-based
fingerprint has a tool capable of calculating SHA-3.

These strike me as updates to the specification, certainly (we now
calculate fingerprints in the following way; We now require SHA-3 as the
lowest-common-denominator digest).  But this is not a change of the
certificate format.

Can you help me understand why a change in the choice of fingerprint
technique and a change in the must-implement-digest-algorithm would
require a change in the certificates themselves?

--dkg

[0] http://www.win.tue.nl/hashclash/rogue-ca/



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/10/2010 9:16 PM, David Tomaschik wrote:
 Are there any disadvantages to distinct signature  encryption keys?

None that I've found.

 Is the weakness in the hash used to sign the key internally, or just when
 it is used to sign data?  I guess that's the part that eludes me.

Err -- yes.

A certificate is just a block of key material plus some associated data.
 SHA-1 is used internally by the certificate to sign some parts of the
data, as well as for computing a key fingerprint.  You can to some
extent mitigate how much SHA-1 gets used, but you can't remove it
completely.

You can also choose to use SHA-1 to sign messages and files.  Here, you
can remove it completely in favor of some other hash algorithm.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[David Tomaschik]

My thoughts at this point are to generate a new RSA4k certify-only key,
generate subkeys (probably RSA2k) for each encrypt and sign, move the
primary key offline (stored in 2 secure places) and then use the subkeys for
daily operations.  This seems to be the method most people who are fairly
concerned with security are using.  I may place my keys on a smart card at
some point, but I haven't decided on that yet.  (I'm aware that there are
some attacks I'm vulnerable to by not using one, but the offline
certify/primary key should help mitigate some of that.)

In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings):
personal-digest-preferences SHA512
cert-digest-algo SHA512

Are there any other settings (or changes to these) that would be considered
more forward looking?

I appreciate everyone's help on this -- trying to make sure I get it
right.

David


On Sat, Dec 11, 2010 at 11:24 AM, Robert J. Hansen r...@sixdemonbag.orgwrote:

 On 12/10/2010 9:16 PM, David Tomaschik wrote:
  Are there any disadvantages to distinct signature  encryption keys?

 None that I've found.

  Is the weakness in the hash used to sign the key internally, or just when
  it is used to sign data?  I guess that's the part that eludes me.

 Err -- yes.

 A certificate is just a block of key material plus some associated data.
  SHA-1 is used internally by the certificate to sign some parts of the
 data, as well as for computing a key fingerprint.  You can to some
 extent mitigate how much SHA-1 gets used, but you can't remove it
 completely.

 You can also choose to use SHA-1 to sign messages and files.  Here, you
 can remove it completely in favor of some other hash algorithm.



 ___
 Gnupg-users mailing list
 Gnupg-users@gnupg.org
 http://lists.gnupg.org/mailman/listinfo/gnupg-users




-- 
David Tomaschik, RHCE, LPIC-1
GNU/Linux System Architect
GPG: 0x
da...@systemoverlord.com
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/12/2010 2:10 AM, David Tomaschik wrote:
 In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings):
 personal-digest-preferences SHA512
 cert-digest-algo SHA512
 
 Are there any other settings (or changes to these) that would be
 considered more forward looking?

personal-digest-prefs is probably a bit off.  For instance, if for any
reason SHA512 is unavailable it will degrade to SHA-1, which you
probably don't want.  It's generally best to include all the algorithms
you'll accept, in whatever order you like.  E.g.:

personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1

This way you have a natural degradation in hash preferences: rather than
immediately degrading to SHA-1, it gives you more options to keep on
using strong hashes.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/9/2010 11:08 PM, David Tomaschik wrote:
 I feel bad for the litter this introduces to the keyservers.

Don't.  :)  The keyservers don't have a problem with this litter.  I
wish people showed more care with their certificates, but that's because
I get too many I forgot my passphrase, help! emails, not because I
think the keyserver network is getting clogged.

 I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys.  I
 believe, but am not certain, that it was generated with SHA1 hashes. 
 (Is there a way I can check?)  This keypair was generated in May of this
 year.

Well, you have one subkey, it's just that the subkey is capable of both
signing and encryption.  You don't have separate subkeys for separate
tasks, if I understand you correctly.  Some people think this is a bad
idea, since if you're compelled to produce an encryption key to the
authorities (so they can decrypt an email sent to you) you've also
provided them with your signature key (so they can now impersonate you).

 What is the best way to transition my email address?  Add a new UID and
 revoke the old?  Should a new keypair be generated?  What is the
 conventional wisdom on the strength of RSA-4096?

Add a new UID and revoke the old.  You don't need to generate a new
certificate.  RSA-4K is, IMO, phenomenal overkill for the vast majority
of users.  Breaking RSA-2K is believed comparable in difficulty to
breaking 3DES, and that prospect is ... let's just say implausible.

RSA-3K is roughly comparable to breaking AES-128.  RSA-4K is not very
much harder than that.  Given all this, I really don't see any point in
going past RSA-2K.  Adding another 2,000 bits to the key in order to get
about another 20 bits of symmetric-key equivalent just strikes me as bad
art.

 If a new keypair is generated, what length would be sufficient for a
 decent (10+ year, preferrably 20+) margin of safety?  I know that there
 may be unforeseen advances in computing that allow for keys to be broken
 rapidly (Quantum computing, new sieve algorithms, etc.), but there's
 surely some guidance based on the current generation of things.

There is not.  In twenty years we will see commonplace attacks that
today are just speculative science fiction.  It's incredibly hard to
make good long-term predictions about crypto.

It is possible that in twenty years national governments will have
large-scale quantum processors.  Once that happens, RSA, DSA and ElGamal
all die horrible screaming deaths.

As an example: almost twenty years ago Schneier wrote in _Applied
Cryptography_ of the Chinese Lottery Attack.  It involved putting a
small processor in every Chinese television set, which could be
programmed by broadcasts from Party headquarters.  Each processor would
crunch a small part of the keyspace, and as soon as a hit was achieved
the television would tell the viewer, You have won!  Call Party
headquarters with this authorization number: [insert key here].

Twenty years ago the Chinese Lottery Attack was an interesting thought
experiment, but nobody took it seriously.

Today we have RC5-64, distributed.net, s...@home, botnets, Amazon EC2
and all manner of other massively distributed computing frameworks.  The
question today isn't whether a Chinese Lottery Attack is possible: the
question is how much it will cost you to rent your server time.

The future is a scary place.  But fun, too, and I look forward to
getting there.  :)

 In a new keypair, is it safe to use SHA512 for hashes?

Sure, but you don't need to create a new cert to use new hash algorithms.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[John Clizbe]

Robert J. Hansen wrote:
 On 12/9/2010 11:08 PM, David Tomaschik wrote:
 If a new keypair is generated, what length would be sufficient for a
 decent (10+ year, preferrably 20+) margin of safety?  I know that there
 may be unforeseen advances in computing that allow for keys to be broken
 rapidly (Quantum computing, new sieve algorithms, etc.), but there's
 surely some guidance based on the current generation of things.
 
 There is not.  In twenty years we will see commonplace attacks that
 today are just speculative science fiction.  It's incredibly hard to
 make good long-term predictions about crypto.

Good case in point of this, some weeks ago a user on another list was asking
about increasing his RSA key size to 8192 bits, based on reading that Bruce
Schneier, in _Applied Cryptography_, has recommended a 8192 bit key if you want
it to have a useful lifetime beyond 2015.

It was pointed out, Bruce Schneier has done a lot of great work, but
relying on 14-year-old advice for RSA key sizes ignores current work and best
practice thought in cryptography. Over the summer, readers of the [Cryptography]
mailing list were reminded that in 1993 folks thought that 1024-bit RSA
'should be ok (safe from key-factoring attacks) for a few decades.'

These are just two examples long term predictions that missed. Back when these
predictions were made, no one foresaw the development of Elliptic Curve
Cryptography which is looking likely to be the upgrade path for RSA/DSA2 keys
larger than 2048-3072 bits.

A 3072 bit RSA key is as tough as an ECC key based on a 256 bit field, which is
as tough as a 128 bit symmetric key.

ECC cryptosystems on a 256 bit field are practical today. 3072 bit RSA systems
are not.

-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=help

Q:Just how do the residents of Haiku, Hawai'i hold conversations?
A:An odd melody / island voices on the winds / surplus of vowels



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Best Practices

[Robert J. Hansen]

On 12/10/2010 6:04 PM, Johan Wevers wrote:
 Why are 3072 bit RSA systems not practical today? Except for situations
 where very few data can be transmitted...

Answered your own question there.  :)

RSA-3K is practical for a lot of problem domains, but I wouldn't
consider it a good general recommendation.  For instance, there are a
lot of smartcards that don't play well with 3K keys.  As a general
recommendation, I think 3K is a bad idea.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users