Re: Enigmail speed geeking

2015-03-16 Thread Werner Koch
On Sun, 15 Mar 2015 23:38, st...@mailbox.org said:

 Thanks, Werner. I read that, but I was particularly interested in how to get
 GnuPG work with haveged.

You should feed it into /dev/random or get into the kernel proper.  This
way all applications can benefit from it.

 So, I guess it would not be possible for an interested user to have GnuPG work
 with haveged by using configuration files or load instructions

This requires to add a new entropy gathering module or add it to
rndlinux.c.  However, I assume that proper output of haveged is pretty
system and compiler dependent.  Thus it belongs into the OS kernel.


Salam-Shalom,

   Werner

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


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


Re: Enigmail speed geeking

2015-03-15 Thread Robert J. Hansen
 Wouldn't the installation of haveged, at least for GNU/linux distros,
 extend the possibilities of traditional /dev/(u)random based RNG?

No idea -- I haven't looked at haveged.  Sorry.  :(

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


Re: Enigmail speed geeking

2015-03-15 Thread Stephan Beck
Am 15.03.2015 um 16:32 schrieb Stephan Beck:
 Am 15.03.2015 um 13:59 schrieb Robert J. Hansen:
 Wouldn't the installation of haveged, at least for GNU/linux distros,
 extend the possibilities of traditional /dev/(u)random based RNG?

 No idea -- I haven't looked at haveged.  Sorry.  :(

 
 Now, I'll look for information on how RNG in GnuPG exactly works.

Answerung myself :-) after having read some chapters in the libgcrypt manual, I
guess, in order to work with GnuPG, haveged would have to be configured in a
similar way as, for instance, the egd (1). Without doing so, it would probably
be ignored by GnuPG.

Cheers,

Stephan

(1) #when compiling, by adding

--enable-static-rnd=egd (to ./configure)

#when using a pre-compiled version that has a different configuration, by using
#a loadable extension module, adding

load-extension rndegd   

#to the ~/.gnupg/options file, or by typing

--load-extension=rndegd

#on the command line while GnuPG is running





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


Re: Enigmail speed geeking

2015-03-15 Thread Werner Koch
On Sun, 15 Mar 2015 16:32, st...@mailbox.org said:

 Now, I'll look for information on how RNG in GnuPG exactly works. It *seems*
 that haveged should impact on the gathering of entropy (available) at the 
 moment
 of keypair generation on any GNU/Linux PC/laptop equipped with it (specific

You can find this in the Libgcrypt manual:

  Libgcrypt provides 3 levels or random quality: The level
  'GCRY_VERY_STRONG_RANDOM' usually used for key generation, the level
  'GCRY_STRONG_RANDOM' for all other strong random requirements and the
  function 'gcry_create_nonce' which is used for weaker usages like
  nonces.  There is also a level 'GCRY_WEAK_RANDOM' which in general maps
  to 'GCRY_STRONG_RANDOM' except when used with the function
  'gcry_mpi_randomize', where it randomizes an multi-precision-integer
  using the 'gcry_create_nonce' function.
  
  There are two distinct random generators available:
  
 * The Continuously Seeded Pseudo Random Number Generator (CSPRNG),
   which is based on the classic GnuPG derived big pool
   implementation.  Implemented in 'random/random-csprng.c' and used
   by default.
 * A FIPS approved ANSI X9.31 PRNG using AES with a 128 bit key.
   Implemented in 'random/random-fips.c' and used if Libgcrypt is in
   FIPS mode.
  
  Both generators make use of so-called entropy gathering modules:
  
  rndlinux
   Uses the operating system provided '/dev/random' and '/dev/urandom'
   devices.
  
  rndunix
   Runs several operating system commands to collect entropy from
   sources like virtual machine and process statistics.  It is a kind
   of poor-man's '/dev/random' implementation.  It is not available in
   FIPS mode.
  
  rndegd
   Uses the operating system provided Entropy Gathering Daemon (EGD).
   The EGD basically uses the same algorithms as rndunix does.
   However as a system daemon it keeps on running and thus can serve
   several processes requiring entropy input and does not waste
   collected entropy if the application does not need all the
   collected entropy.  It is not available in FIPS mode.
  
  rndw32
   Targeted for the Microsoft Windows OS. It uses certain properties
   of that system and is the only gathering module available for that
   OS.
  
  rndhw
   Extra module to collect additional entropy by utilizing a hardware
   random number generator.  As of now the only supported hardware RNG
   is the Padlock engine of VIA (Centaur) CPUs.  It is not available
   in FIPS mode.
  

  16.6.1 Description of the CSPRNG
  
  
  This random number generator is loosely modelled after the one described
  in Peter Gutmann's paper: Software Generation of Practically Strong
  Random Numbers.(1)
  
 A pool of 600 bytes is used and mixed using the core RIPE-MD160 hash
  transform function.  Several extra features are used to make the robust
  against a wide variety of attacks and to protect against failures of
  subsystems.  The state of the generator may be saved to a file and
  initially seed form a file.
  
 Depending on how Libgcrypt was build the generator is able to select
  the best working entropy gathering module.  It makes use of the slow and
  fast collection methods and requires the pool to initially seeded form
  the slow gatherer or a seed file.  An entropy estimation is used to mix
  in enough data from the gather modules before returning the actual
  random output.  Process fork detection and protection is implemented.
  
 The implementation of the nonce generator (for 'gcry_create_nonce')
  is a straightforward repeated hash design: A 28 byte buffer is initially
  seeded with the PID and the time in seconds in the first 20 bytes and
  with 8 bytes of random taken from the 'GCRY_STRONG_RANDOM' generator.
  Random numbers are then created by hashing all the 28 bytes with SHA-1
  and saving that again in the first 20 bytes.  The hash is also returned
  as result.
  
 -- Footnotes --
  
 (1) Also described in chapter 6 of his book Cryptographic Security
  Architecture, New York, 2004, ISBN 0-387-95387-6.
  


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: Enigmail speed geeking

2015-03-15 Thread Stephan Beck
Am 15.03.2015 um 20:50 schrieb Werner Koch:
 On Sun, 15 Mar 2015 16:32, st...@mailbox.org said:
 
 Now, I'll look for information on how RNG in GnuPG exactly works. It *seems*
 that haveged should impact on the gathering of entropy (available) at the 
 moment
 of keypair generation on any GNU/Linux PC/laptop equipped with it (specific
 
 You can find this in the Libgcrypt manual:
 

Thanks, Werner. I read that, but I was particularly interested in how to get
GnuPG work with haveged.
So, I guess it would not be possible for an interested user to have GnuPG work
with haveged by using configuration files or load instructions (similar to egd)
and a strong dedication.
It does require to be implemented first in GnuPG/libgcrypt by modifying
source code, doesn't it? The latter would be certainly out of my reach, far off
the shore in (the Atlantic) C :)
If it were at all feasible/possible to do it by using the approach mentioned
first I would have given it a try, and published a howto in the wiki.

Stephan





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


Re: Enigmail speed geeking

2015-03-14 Thread Peter Lebbing
On 13/03/15 22:33, Robert J. Hansen wrote:
 And if you don't trust /dev/urandom, I'd suggest using a different 
 operating system, because that's a game-over compromise.

I trust both /dev/random and the sanity of the default settings of
GnuPG. And when I'm generating a key in GnuPG, I put my trust in both. I
don't know what is all going on in GnuPG for generating the highest
quality of randomness, but it's more than cat /dev/random. It was
simply incomplete to just say Linux's RNG, and it didn't acknowledge
the effort the GnuPG developers put into the code that generates the
randomness.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://digitalbrains.com/2012/openpgp-key-peter

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


Re: Enigmail speed geeking

2015-03-13 Thread Doug Barton

On 3/13/15 11:23 AM, Robert J. Hansen wrote:

Seriously? Wasn't it obvious from the context of what Robert and
I wrote that we were talking about keys that existed only on a
card?


Let's calm things down, folks.  :)


FWIW, I'm perfectly calm, as in the sense of not angry. But it is a
major source of frustration when folks take comments out of context to
use the tiniest bit of leverage with which to forward an agenda. It's
not only intellectually dishonest, but it's a massive waste of
everyone's time when the conversation devolves into the degree that
some argument is correct in some context, no matter how far removed it
is from the actual point under discussion.

Calling BS on that rhetorical technique may get me a shiny new
Curmudgeon badge to add to my collection, but I still think it's a
worthwhile exercise.

Doug


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


Re: Enigmail speed geeking

2015-03-13 Thread Robert J. Hansen
 Seriously? Wasn't it obvious from the context of what Robert and I
 wrote that we were talking about keys that existed only on a card?

Let's calm things down, folks.  :)

We're communicating in a text medium.  Sometimes, things we think are
obvious aren't obvious to others.  Let's take a deep breath and remember
that everyone's discussing things in good faith, okay?  :)

Nothing but peace here, guys.



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


Re: Enigmail speed geeking

2015-03-13 Thread Doug Barton

On 3/13/15 7:22 AM, Peter Lebbing wrote:

I interpreted Dougs message as saying that a disadvantage of smartcards,
as opposed to on-disk keys, is that you lose the key when the smartcard
stops functioning. I was replying to this statement by Doug:


Further, the inconvenience of having to deal with generating and
socializing a new key if your smart card gets lost, becomes
inoperable, etc. is way too high a cost for near-zero benefit.


So I say: you should use backups, duh.

The fact that you /can/ use a smartcard without a backup, which as you
say can be advantageous, by no means implies that you /cannot/ keep a
backup. This is what I was saying.


Seriously? Wasn't it obvious from the context of what Robert and I wrote 
that we were talking about keys that existed only on a card? And even if 
that bit of subtlety escaped you, isn't it even more obvious that if you 
have a backup copy of the key already then the point I was making 
doesn't apply?


If neither of those things were obvious to you from the thread then 
maybe you should reconsider whether you should be posting on the topic 
at all.


Doug


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


Re: Enigmail speed geeking

2015-03-13 Thread Peter Lebbing

On 2015-03-13 19:54, Doug Barton wrote:

But it is a
major source of frustration when folks take comments out of context 
to

use the tiniest bit of leverage with which to forward an agenda.


WHAT?!?!

It is true, text is a truly god awful medium to communicate in.

We are apparently completely unaware of each other's intentions. I 
honestly thought you thought a disadvantage of using a smartcard is that 
you lose the key once it breaks. It quite surprised me, but I've seen 
smart people have odd misconceptions of things[1], so I simply sought to 
rectify it.


Let's put this whole thing to rest. Nobody thinks you can't have a 
backup of a smartcard key, nobody thinks that a smartcard without a 
backup is a useless thing, and we should all go and read a nice book. 
Perhaps even for the third time, in my case. It's a nice book!


Peter.

[1] Sometimes in the mirror ;P

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


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


Re: Enigmail speed geeking

2015-03-13 Thread Robert J. Hansen
 Make that: I trust the RNG of GnuPG. There's more to it than what is 
 provided by the Linux kernel.

Be careful.  When was the last time you checked the GnuPG code?  And
when was the last time you checked the options your distro maintainer
used to build your GnuPG?  :)

GnuPG doesn't have one RNG.  It has *many* RNGs.  Some of them are
really just thin wrappers over lower-level OS facilities.  And if you
don't trust /dev/urandom, I'd suggest using a different operating
system, because that's a game-over compromise.  It's like not trusting
CryptGenRand on Win32.



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


Re: Enigmail speed geeking

2015-03-13 Thread Doug Barton

On 3/13/15 2:17 PM, Peter Lebbing wrote:

On 2015-03-13 19:54, Doug Barton wrote:

But it is a
major source of frustration when folks take comments out of context to
use the tiniest bit of leverage with which to forward an agenda.


WHAT?!?!

It is true, text is a truly god awful medium to communicate in.

We are apparently completely unaware of each other's intentions. I
honestly thought you thought a disadvantage of using a smartcard is that
you lose the key once it breaks. It quite surprised me, but I've seen
smart people have odd misconceptions of things[1], so I simply sought to
rectify it.

Let's put this whole thing to rest. Nobody thinks you can't have a
backup of a smartcard key, nobody thinks that a smartcard without a
backup is a useless thing, and we should all go and read a nice book.
Perhaps even for the third time, in my case. It's a nice book!

Peter.

[1] Sometimes in the mirror ;P


Thank you for clarifying.

Doug


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


Re: Enigmail speed geeking

2015-03-13 Thread Peter Lebbing
On 12/03/15 20:17, Doug Barton wrote:
 Further, the inconvenience of having to deal with generating and
 socializing a new key if your smart card gets lost, becomes inoperable,
 etc. is way too high a cost for near-zero benefit.

And what if your hard drive holding your on-disk key crashes? Do you
also socialize a new key?

Of course not (I hope). You keep a backup of your key in a safe place.
This goes for smartcard keys as well. The situation is the same whether
you use a smartcard or not.

For signing subkeys, a backup isn't very necessary, not for on-disk keys
or for smartcard keys. But for your primary key and especially
encryption subkeys, this is important.

Not having a backup of your encryption subkeys means a not very robust
single point of failure, and if that hard disk crashes, or the file
system is corrupted, or your smartcard dies, you suddenly lose access to
all your encrypted files.

I cannot fathom why you would not have at the very least one backup of
your encryption subkey. It sounds like a phenomenally bad idea.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://digitalbrains.com/2012/openpgp-key-peter

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


Re: Enigmail speed geeking

2015-03-13 Thread Peter Lebbing
I interpreted Dougs message as saying that a disadvantage of 
smartcards, as opposed to on-disk keys, is that you lose the key when 
the smartcard stops functioning. I was replying to this statement by 
Doug:


Further, the inconvenience of having to deal with generating and 
socializing a new key if your smart card gets lost, becomes inoperable, 
etc. is way too high a cost for near-zero benefit.


So I say: you should use backups, duh.

The fact that you /can/ use a smartcard without a backup, which as you 
say can be advantageous, by no means implies that you /cannot/ keep a 
backup. This is what I was saying.


HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


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


Re: Enigmail speed geeking

2015-03-13 Thread Brian Minton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If a key is generated externally, a backup can be taken before the key
is moved to the card.  For a key generated on the card, there is (by
design), no way to extract the secret key, including for the purpose of
backing it up
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlUC9JUACgkQa46zoGXPuqlGIwD+MqwlNB6gkMnOlNDITREhS0W6
0r8PkacHiQckvJTgZ8UA/33GtkpcUCSzSemcfCYx+AnZ3bDct9xaDtBORe6PyMPk
=NmcR
-END PGP SIGNATURE-

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


Re: Enigmail speed geeking

2015-03-13 Thread Peter Lebbing

On 2015-03-13 15:31, Brian Minton wrote:
If a key is generated externally, a backup can be taken before the 
key

is moved to the card.  For a key generated on the card, there is (by
design), no way to extract the secret key, including for the purpose 
of

backing it up


When you ask GnuPG to create an on-card key, it will ask you whether 
you want to keep a backup of the key or not.


If you choose to proceed without a backup, the key is generated 
on-card. I consider this the inferior of the two methods because I trust 
the RNG of Linux much more than I trust the RNG of a smartcard that 
costs a few euros to produce.


If you choose to have a backup, GnuPG will create the key just as it 
would for a normal on-disk key, and then upload that key to the 
smartcard and keep a backup file. This thus uses the RNG of your PC; on 
which I would be running Linux.


You could then discard the backup if you want to have the quality of 
the RNG of the PC but don't want the backup.


HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


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


Re: Enigmail speed geeking

2015-03-13 Thread Robert J. Hansen
 Of course not (I hope). You keep a backup of your key in a safe
 place. This goes for smartcard keys as well. The situation is the
 same whether you use a smartcard or not.

This is not true.  There are a lot of use cases where there are no
backups of this smart-card key are baked into the security model.
That's why we can create keys on the card directly: that way they never
need to exist outside of the card.

 Not having a backup of your encryption subkeys means a not very
 robust single point of failure, and if that hard disk crashes, or the
 file system is corrupted, or your smartcard dies, you suddenly lose
 access to all your encrypted files.

Yes, and in some security models that's preferable to having a backup
copy somewhere.



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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 As to your enigmail essay, point 1, would you go that far that
 keeping keys on hard disk is unsafe and using a smart card is a
 must?

For many users, smart cards are a good idea.  (I've got one myself.)
But for just as many users, smart cards are inconvenient and overkill.
Frankly, they have awful usability, just terrible.  When I receive an
email message encrypted to my smart card key, finding the smart card is
easy -- it's in my wallet -- but finding the smart card *reader* is the
sort of thing that leads me to crazed conspiracy theories.  Is the
reader attached to my laptop?  Did I leave it at the office?  Did I kick
it under the sofa?  Did the space aliens from Zarbnulax take it?

The upshot of it is that whenever I want to decrypt messages sent to my
smart card, in the best case scenario (I remember where the reader is
and it's within a few meters of my desk) it takes me 30-45 seconds to
read the message.  In the worst-case scenario, I'm in Valencia, Spain,
and my reader is in Washington, D.C., and there's no way I'm reading
this traffic until I get home.  (And in case you're wondering, yes, that
really happened to me.)

If email crypto makes it hard to read email, few people will adopt the
technology.  We want technologies that make our lives easier, not
harder.  Smart cards, although a really good idea in certain
environments, make crypto harder in a lot of environments.  I'm not sure
the (marginal) additional security from using a smart card is worth the
(very real) usability expense.

Is it unsafe to keep your keys on your hard disk?  Dunno.  Depends a lot
on your situation.

Is using a smart card a must?  Dunno.  Depends a lot on your situation.

Hope this helps.  :)



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


Re: Enigmail speed geeking

2015-03-12 Thread Andreas Schwier
On 03/12/2015 04:51 PM, Robert J. Hansen wrote:
 For many users, smart cards are a good idea.  (I've got one myself.)
 But for just as many users, smart cards are inconvenient and overkill.
 Frankly, they have awful usability, just terrible.  When I receive an
 email message encrypted to my smart card key, finding the smart card is
 easy -- it's in my wallet -- but finding the smart card *reader* is the
 sort of thing that leads me to crazed conspiracy theories.  Is the
 reader attached to my laptop?  Did I leave it at the office?  Did I kick
 it under the sofa?  Did the space aliens from Zarbnulax take it?
There are USB-Sticks with an embedded smart card controller that take
away the burden to find a working card reader (which _is_ a real pain).
The one we use has a standard CCID interface that works without driver
installation on the majority of operating systems.

-- 

-CardContact Software  System Consulting
   |.## ##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'## ##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 There are USB-Sticks with an embedded smart card controller that
 take away the burden to find a working card reader (which _is_ a real
 pain). The one we use has a standard CCID interface that works
 without driver installation on the majority of operating systems.

Yeah -- back in 2000 I used a Rainbow iKey, which was one of the first
USB tokens.  Then I discovered the downside of USB tokens: they don't
take well to going through the wash.  (You know how when you pull
clothes out of the dryer they've got all kinds of static electricity on
them?  USB tokens don't take kindly to that.)

I dunno, maybe today we've got USB tokens that can survive the wash.
Wouldn't surprise me.  Unfortunately, I don't have the money to make a
good empirical test.




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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 I would go so far as to say for the vast majority of users they are 
 totally unnecessary. It's cool to play with smart cards, and I'm all
 in favor of that sort of thing ... but for the overwhelming number of
 PGP users the threat model just isn't there.

I dunno.  I think there are some good arguments for regular users
employing them; I just don't think those arguments are all that compelling.

For instance, I have my smartcard cross-signed with my usual certificate
(0xD6B98E10).  If you trust 0xD6B98E10, you'll probably also trust my
smartcard certificate -- and vice-versa.  Now let's say that in a couple
of years 0xD6B98E10 gets compromised.  I revoke the certificate,
propagate the revocation, and generate a new cert (0xBADD00D5).  I sign
0xBADD00D5 with the smartcard cert and put it up on the servers.  Etc.
People can see 0xBADD00D5 is signed by my smartcard and can have
confidence this is my new certificate.

This is basically the idea of the offline master signing key that a
lot of people talk about, but a lot more convenient due to the smartcard
form-factor.  I don't have to worry about air-gapping the signing
system, I just have to worry about finding the card reader when it comes
time to generate a new cert.

 Further, the inconvenience of having to deal with generating and 
 socializing a new key if your smart card gets lost, becomes
 inoperable, etc. is way too high a cost for near-zero benefit.

Yep.  Don't lose 'em.




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


Re: Enigmail speed geeking

2015-03-12 Thread Ville Määttä
On 12.03.15 20:52, Robert J. Hansen wrote:
 My point was that you wrote multiple paragraphs worth of stories on 
  two emails from which I really got the impression that people should
  just not bother.
 In response to someone who was thinking that storing keys on your hard
 drive was categorically unsafe, and that smart cards were categorically
 necessary, yes.

Absolutely. I agree. I think the difference of opinion here stems from
how I read the reply you sent. After the first couple sentences it's not
much about answering the question anymore :).

The questions was: Are smart cards a must? No they are not.

 The answer is, it depends.

 Isn't it depends exactly what I said ?
 
 No.  You said they add security, period, and that they either
 inconvenience minutely or add convenience.

All things being equal, they do practically add security, period :).
Well, you're quite right that it's impossible to say that they would add
security in all situations. Maybe they could also weaken it in some. But
you can use the same passphrase with or without the card. You can have
your subkeys on the card or on the computer. Maybe you can fill in the
rest. I.e. all things being equal:

The card can and on defaults probably will limit the amount of
passphrase attempts. And then it locks. Is it absolutely secure against
hacking? No. But it should be quite difficult to hack. And an important
point if to only have subkeys in there that you can revoke.

 That's not an it depends
 answer.  That's a this is true in all times and situations answer, and
 that's exactly wrong.

I said depending on the user and use case. It is an it depends answer.

 They do *not* add security in all times and
 situations

I'm not making such a claim. The world is not black and white. Yes or no
only. I'm not talking about some theoretical, mathematically proven
statement that smart cards are more secure in every possible way. They
are not.

, and they do *not* only ever cause minute inconvenience.

I don't know how you count the 30-45 second number from before but for
me it adds 1-10 seconds, maybe. Hard to estimate but it doesn't really
add any inconvenience to my use. And obviously, that's quite subjective.

I'm not even trying to make a point that they would be more secure all
the time. But, practically, they can be a cheap and convenient way to
add security. Everyone has to evaluate their use case though.

Here's an example. Is it better to store secret keys on each computer or
a smart card? I use multiple different computers and think that it's
more secure to have the keys on my smart card. So, more security by not
having to distribute the secret keys to all those computers. I'd say
that's convenient security as the secret keys come with me to whichever
computer I happen to be using.

-- 
Ville



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


Re: Enigmail speed geeking

2015-03-12 Thread Ville Määttä
On 12.03.15 19:21, Robert J. Hansen wrote:
 If you think I'm portraying them as completely unusable, then I think
 you didn't bother to read my message very closely.

I read both of your messages quite closely. Had you merely pointed out
the downsides of having to carry a card, a reader etc. I would probably
have just agreed with you and likely just read and said nothing. My
point was that you wrote multiple paragraphs worth of stories on two
emails from which I really got the impression that people should just
not bother.

On 12.03.15 19:55, Stephan Beck wrote:
 Yes, thanks a lot. From your answer I deduce that a single-user,
 non-professional environment may not require use of a smart card,
 or may not require it with the necessity it may have in high-security
 environments.

It would appear so did Stephan.

 I think they add security and depending on the user and use case
 they either add inconvenience minutely or the complete opposite, they
 add usability.
 
 The number of environments, number of users, and number of use cases, is
 way too vast to be able to make a glib statement like this.  You're just
 wrong.  
 
 The answer is, it depends.
 

Isn't it depends exactly what I said :)? I think you went a bit
overboard with the stories and wanted to point that out, that's all.
Smart cards are not some scary thing only necessary in high-security
environments. Whatever that might mean.

-- 
Ville



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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 My point was that you wrote multiple paragraphs worth of stories on 
 two emails from which I really got the impression that people should
 just not bother.

In response to someone who was thinking that storing keys on your hard
drive was categorically unsafe, and that smart cards were categorically
necessary, yes.  If you want to illustrate that smart cards are not
categorically necessary, you don't highlight instances where they're
useful and/or necessary: you highlight instances where they're not.  Had
the original poster said, Is it correct to say there's no real use case
for smart cards?, I would have talked about situations where they're a
real benefit.

 I think they add security and depending on the user and use case 
 they either add inconvenience minutely or the complete opposite,
 they add usability.
 
 The number of environments, number of users, and number of use 
 cases, is way too vast to be able to make a glib statement like 
 this.  You're just wrong.
 
 The answer is, it depends.
 
 Isn't it depends exactly what I said :)?

No.  You said they add security, period, and that they either
inconvenience minutely or add convenience.  That's not an it depends
answer.  That's a this is true in all times and situations answer, and
that's exactly wrong.  They do *not* add security in all times and
situations, and they do *not* only ever cause minute inconvenience.




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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 That's quite a personal issue to count as a failing of smart cards.

Sure!  And I even said that.  For many users, smart cards are a good
idea.  (I've got one myself.)  But for just as many users, smart cards
are inconvenient and overkill.  Your use case isn't my use case.

That said, I've heard from enough people over the years sharing the I
can never find a reader when I need one problem for me to think I'm not
alone.

 I'm not sure the (marginal) additional security from using a smart 
 card is worth the (very real) usability expense.
 
 Oh, you mean like being able to use a more humane PIN / passphrase?

Depends on the user.  I personally have three different 128-bit
passphrases memorized (sixteen random bytes base-64 encoded).  Other
people have trouble remembering their four-digit ATM PIN code.

Will I get additional security from using a smart card?  Depends on my
specific usage and my goals, but in most of my cases, no.  Enough to
justify the usability expense?  Again: it depends on my specific usage
and my goals, but in most of my cases, no.

But that doesn't mean I don't use my smart card.  I do.  I just use it
in use cases where it makes sense to do it.

 Then I discovered the downside of USB tokens: they don't take well 
 to going through the wash.
 
 Are you serious? I wouldn't know but I'm guessing the computer you 
 use to decrypt those messages won't take too well to water either.

Probably not, but in my defense, Apple didn't put a hole in my laptop
and give me a glossy brochure showing a MacBook Pro hanging off my
keychain, either.  Rainbow Technologies did, and what happened to the
token after that was predictable.  It went where my car keys did.
Namely, the wash.

 Sure you need a reader and sure, you shouldn't throw the reader into
 water but come on. You go out of your way to make them sound like 
 something completely unusable.

Not completely unusable.  In the best case, a smart card adds 30-45
seconds to my operation time.  That's a price I'm willing to pay for
certain operations.  For others, it's not.

If you think I'm portraying them as completely unusable, then I think
you didn't bother to read my message very closely.  Their usability and
appropriateness is *intensely* dependent on the user and the operating
environment.  For some users they make a lot of sense.  For others, they
don't.

 I think they add security and depending on the user and use case
 they either add inconvenience minutely or the complete opposite, they
 add usability.

The number of environments, number of users, and number of use cases, is
way too vast to be able to make a glib statement like this.  You're just
wrong.  :)

The answer is, it depends.



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


Re: Enigmail speed geeking

2015-03-12 Thread Doug Barton

On 3/12/15 8:51 AM, Robert J. Hansen wrote:

For many users, smart cards are a good idea.  (I've got one myself.)
But for just as many users, smart cards are inconvenient and overkill.


I would go so far as to say for the vast majority of users they are 
totally unnecessary. It's cool to play with smart cards, and I'm all in 
favor of that sort of thing ... but for the overwhelming number of PGP 
users the threat model just isn't there.


Further, the inconvenience of having to deal with generating and 
socializing a new key if your smart card gets lost, becomes inoperable, 
etc. is way too high a cost for near-zero benefit.


FWIW,

Doug


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


Re: Enigmail speed geeking

2015-03-12 Thread Robert J. Hansen
 Yes, thanks a lot. From your answer I deduce that a single-user, 
 non-professional environment may not require use of a smart card, or 
 may not require it with the necessity it may have in high-security 
 environments.

Yep!  And just as importantly: it may require it.  It depends on your
threat model and what you need to defend against.  Ultimately, it's a
judgment call.

 But on an individual level, I guess it also depends on how much you 
 love (playing with) software and related devices and are already
 used to it.

This, too!  If you want to play around with them and have fun, don't let
me stop you.  :)



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


Re: Enigmail speed geeking

2015-03-11 Thread Stephan Beck
Hi Robert,

Am 11.03.2015 um 18:10 schrieb Robert J. Hansen:

 Things you're doing wrong with Enigmail is a short (500-word) essay on
 four mistakes I repeatedly see Enigmail users making.  However, it's not
 limited to Enigmail: most of the content is broadly applicable to any
 cryptosystem.
 
 http://robert-hansen.com/?p=83


I enjoyed reading your blog. In particular, the about page is really worth 
reading.
As to your enigmail essay, point 1, would you go that far that keeping keys on
hard disk is unsafe and using a smart card is a must? I joined the list some
weeks ago and half of the messages (I'm exaggerating) were/are about smart
cards, so I take up this point here, although you might not have implied it.

TIA

Stephan





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