Re: Where is ECC in gpg2 (specifically gnupg-2.0.21

[Werner Koch]

On Thu, 12 Sep 2013 07:35, d...@fifthhorseman.net said:

> GnuPG 2.1 (still currently in beta, afaict) is the first version to
> include ECC support for OpenPGP.  the 2.0.x branch does not include ECC

Right.  There are no plans to support it in older versions.  2.1 also
has a feature to work without the pinentry, which should mitigate most
concerns about switching to GnuPG-2.  However, if at some time ECC would
really take off, we might backport it to 1.4 if we could agree to change
1.4 to make use of Libgcrypt.

The ECC support is actually ready for use but in the light of
the recent news it might make sense to change the default curves.
Fortunately I insisted during the specification phase that the format
allows OIDs to specify the curve and not just the few Suite-B curves.
The easiest way to switch to different curves would be the use of the
somewhat slower Brainpool curves: We have already full support in
Libgcrypt for them, thus changing it in GnuPG would be easy (it is
mainly the key generation menu which maps desired key lengths to a
curve).

There are two other developments which should be considered:

 - Andrey is working on a more compact representation of keys and
   signatures which don't violate the compression patent (which anyway
   expires mid next year).

 - I am thinking to switch to Curve25519 based algorithms.  They have
   been developed by Dan Bernstein et al. and are considered a sound
   design.  I am currently working on the implementation of the signature
   scheme in Libgcrypt.


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: Why trust gpg4win?

[NdK]

Il 12/09/2013 23:10, Marko Randjelovic ha scritto:

> All the time I read suggestions on using USB sticks and I must say
> people are crazy about USB sticks. It is more convenient to use optical
> media then USB stick because they are read only. Boot from Live CD, not
> from USB stick and use USB stick only for data. In a desktop PC you can
> put two CD devices and boot Live CD from CD1 and write your data to
> CD2. You can use write-once media or rewritable media so you do not
> waste to much plastic.
It's just a matter of trust (and speed). After all, you need to take the
system image from "somewhere". That's probably the weakest link. Or, at
least, it's the easiest to compromise.

PS: I'll tell you a secret: there are USB keys with a "write protect"
switch :)

> If you write your data to CDROM, then it is much more safer to transfer
> data to another PC. It is much more complicated to make a virus that
> will insert itself into a CDROM then into a USB stick. Furthermore,
> such action would be odd and could be blocked by a security software
> like SELinux.
And maybe there's a buffer overflow in the ISO9660 driver that can be
exploited . Hey, we're talking of the most tested codepaths (unless
you use some exotic filesystem)!

Maybe technical solutions for a social problem aren't always the right
answer?
You can *never* be 100% sure. No way. You can be "reasonably sure". You
can be "certifiably sure" (given that you define which kind of attacks
you think you'll be exposed to and find a standard to certify against).

I can be "reasonably sure" nobody will hack my machine just to read my
mail. Obama can be "reasonably sure" that *many* attackers will try. So
my scenario and Obama's one are "a bit" different, and require *greatly*
different solutions. I can't afford the costs and inconveniences of a
solution based on Obama's needs (and I'd be indeed quite stupid to try
to adopt it), and he can't afford the risk of a solution tailored on mine.

PPS: at least here in Italy a *completely offline machine* becomes
illegal after 6 months. Law dictates that every computer where personal
data is handled (and even a name and surname *is* "personal data")
*must* be updated *at least* every 6 months. And attacking your update
medium is probably easier than attacking the USB key.

BYtE,
 Diego.

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

Re: Attacking an offline system

[Peter Lebbing]

On 12/09/13 22:03, NdK wrote:
> Nope. W/ Vinculum module you send it commands like "open mickey.txt" and
> then "read 1024". The filesystem driver is in the module and your interface
> only receives expected data.

I hadn't looked at the Vinculum module[1]; that would indeed be a way to remove
the filesystem from the equation, although you will end up writing something
similar to a filesystem driver for the PC which might itself be exploitable.

You can reduce the complexity of the software, but you can't eliminate some form
of driver. And I certainly wouldn't trust the module to give me only expected
data :). You've only moved the complexity of the USB stack to the module, it
needs to be regarded exploitable.

> You really should define your "security perimeter".

You mean threat model? I completely agree. All my contributions are just musings
about things I notice while reading other people's contributions. I'm not
contemplating actually doing any of this. If you seriously consider doing this,
you need to formulate a good threat model.

I use a USB stick to transfer stuff.

HTH,

Peter.

[1] I was just thinking in general terms of bridging USB mass storage to a
serial port through some driver.

-- 
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: Why trust gpg4win?

[Peter Lebbing]

On 13/09/13 09:19, NdK wrote:
> PS: I'll tell you a secret: there are USB keys with a "write protect"
> switch :)

Since people were concerned about hacking the USB key, you need to define the
scenario.

First of all, if we are talking about hacking through a rogue firmware update
for the USB key: is the write protect switch directly connected to the "Write
enable" line of the flash chip or is it done in the firmware? In the latter
case, it's useless. In the former case: the flash chip is reasonably
intelligent, and "closed source". There could be an exploit to write to it even
when the "Write enable" line is not asserted.

If we're talking about hacking the USB key by getting your hands on it and
physically altering it, I don't even need to explain. Although if you keep the
stick next to your offline PC, the attacker will probably not bother with the
stick ;).

So it really depends on your threat model if that switch is useful.

> And attacking your update medium is probably easier than attacking the USB 
> key.

I think in my case, the only difference is the added possibility of attacking
the package manager. I put a debian mirror on an external hard disk, connect
that to my offline PC and then update the system.

I think it would be difficult to remove the package manager from the equation,
unless you switch distro's :).

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: Why trust gpg4win?

[Jan]

09/12/2013 22:03, NdK wrote:

You really should define your "security perimeter".


09/13/2013 09:19, NdK wrote:

I can be "reasonably sure" nobody will hack my machine just to read my
mail. Obama can be "reasonably sure" that *many* attackers will try.


My "security perimeter" should be "equal" to the maximum of the "security 
perimeters" of my usual communication partners. That is so because with 
their private key they protect my mail and with my private key I protect 
their mail. What is "usual" is not always easy to determine. Lets say I'm 
looking for the maximum of security an average user can achieve with common 
hardware. This user is willing to do some inconvenient things like reboot, 
burn CDs or wait.


Generally I distrust certain hardware like smartcards or HSMs because they 
are main targets for secret services, who have a lot of money. Recently I 
red about this intersting (English/German) article on FBI backdoors in 
openBSB and scmartcards:


http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html
http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html

It should be possible to create a rather secure system using "norml 
technoligies" (CDs, offline PCs etc.) which are harder to target by secret 
services. If you manage to have a rather secure file transfer between an 
online and an offline PC, the only security relevant technology you need to 
focus on is gnuPG itself. Some people read the source code to check its 
integrity but are there people who focus on its output? To me this is a very 
important point. I'm not sure how this could be done in practice, but I was 
thinking about someone who knows the theory of RSA etc. and who "manually" 
encrypted a text and would compare that with the output of gnuPG to see 
whether the two results match. Some other approach might be to compare the 
output of several versions of gnuPG, PGP etc.. This way you could check 
whether the information was secretly decrypted with a second "FBI key". This 
is even possible for someone how is no programer. Do you think checking the 
output in that way is useful?


Kind regards,
Jan 



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

Re: Why trust gpg4win?

[David Smith]

On 09/10/13 21:42, Jan wrote:
> 10/9/2013 14:19, Werner Koch wrote :
>> So what about using that free USB stack for AVR's to implement a flash
>> device?  You would be able to audit about everything; flylogic even has
>> these nice pictures of the ATmega88 masks...
> 
> 10/9/2013  16:33, David Smith wrote:
>> AVR is a semiconductor manufacturer who make microcontrollers (amongst
>> other things).
> 
> Thanks for the answers. Did you refer to the following?
[snip]

No.  I work for a (different) semiconductor manufacturer (you can
probably work out which one from my email address...).  Actually, I
wasn't quite correct - AVR is a brand of microcontrollers made by
semiconductor manufacturer Atmel.  They are used in the Arduino project
among other things.

> How could I implement a flash device? Do you mean I need to take some 
> existing USB device created by AVR and replace its firmware by LUFA or 
> something like that? Could I use that modified USB device on every PC or 
> operation system?

To answer your questions in order...

1. You've answered this question in the second question
2. Yes.
3. Yes.  If you get the microcontroller to tell the PC that it's a flash
drive, then the PC will believe it and treat it as such.  The USB spec
(and sub-specs) define how a flash drive should "look" to the host (the
PC), and provided the USB device behaves like this, the host will assume
that it really is a flash drive.

In reality, a lot of USB devices are built this way - the low-level USB
hardware interface is implemented by dedicated hardware, but the
higher-level parts (like defining what "sort" of device it is, and what
to do with the data that is transferred) is encoded in firmware.  In
fact, it wouldn't surprise me if some USB flash drives are implemented
this way.

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

Re: Where is ECC in gpg2 (specifically gnupg-2.0.21

[Johan Wevers]

On 9/13/2013 8:52, Werner Koch wrote:

> concerns about switching to GnuPG-2.  However, if at some time ECC would
> really take off, we might backport it to 1.4 if we could agree to change
> 1.4 to make use of Libgcrypt.

Such a major change would warrant a 1.6 IMO.

BTW, is there any discussion in the OpenPGP community about other public
key systems, like NTRUEncrypt (see
http://en.wikipedia.org/wiki/NTRUEncrypt )? Or are they too imature?

IMO ECC has at least some questions about it since the NSA is pushing
it. That could be because they know of weaknesses in it, or because they
know of weaknesses in ElGamal and RSA. Difficult to guess.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: Why trust gpg4win?

[NdK]

Il 13/09/2013 11:33, Jan ha scritto:

> My "security perimeter" should be "equal" to the maximum of the
> "security perimeters" of my usual communication partners. That is so
> because with their private key they protect my mail and with my private
> key I protect their mail. What is "usual" is not always easy to
> determine. Lets say I'm looking for the maximum of security an average
> user can achieve with common hardware. This user is willing to do some
> inconvenient things like reboot, burn CDs or wait.
Then you can't defend it. :) You can't even completely audit it, since
it involves a lot of "things" that aren't under your control.
What happens if one of your correspondents is willing to undergo the
whole procedure and he's an FBI agent? :)
You can be paranoid as much as you want, but you will never be paranoid
enough. If FBI (or, more realistically, your wife) wants access to your
data, there's nearly nothing you can do to avoid it...

> Generally I distrust certain hardware like smartcards or HSMs because
> they are main targets for secret services, who have a lot of money.
You could use a Chinese smart card: quite sure it's not been tampered by
FBI :)

> Recently I red about this intersting (English/German) article on FBI
> backdoors in openBSB and scmartcards:
> http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html
> http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html
Well, that's one reason I don't like "random blobs" in crypto (like OAEP
requires): it could be quite easy yo use such a blob as steganographic
covert channel.

But for OpenBSD I'd be more incline to thinking that FBI stopped funding
since they couldn't have their backdoors installed.

> It should be possible to create a rather secure system using "norml
> technoligies" (CDs, offline PCs etc.) which are harder to target by
> secret services.
Never heard of TEMPEST?
You boot from an accurately audited CD, decrypt your top-secret email
and as soon as you display it on the monitor it gets aired to that van
in front of your house :)

> If you manage to have a rather secure file transfer
> between an online and an offline PC, the only security relevant
> technology you need to focus on is gnuPG itself.
No. Side-channels are everywhere. You can't ignore 'em. If you want to
certify that your security perimeter is secure, you first have to
accurately define where it is and the threat model. And even then you
can only certify it's secure against the attacks you could think of.

> Some people read the
> source code to check its integrity but are there people who focus on its
> output? To me this is a very important point. I'm not sure how this
> could be done in practice, but I was thinking about someone who knows
> the theory of RSA etc. and who "manually" encrypted a text and would
> compare that with the output of gnuPG to see whether the two results
> match.
Take OAEP signature as an example. *IF* the random bytes are really
random the signature is secure. But since they should be  random, you
can't say if they are truly random or just the output of a cypher that,
given the right password, is transferring your secret key
chunk-by-chunk. And against that, even manually encoding is useless: the
RSA encryption is done correctly, the key is the right one, the protocol
is followed, but soon someone else will have your key and will be able
to decrypt all your messages.
IVs are another potential channel, but they're needed to make many
encryption schemes secure.

> Some other approach might be to compare the output of several
> versions of gnuPG, PGP etc.. This way you could check whether the
> information was secretly decrypted with a second "FBI key". This is even
> possible for someone how is no programer. Do you think checking the
> output in that way is useful?
No. You can only check if the protocol is followed accurately.
How can you check there isn't a weakness in RNG, for example? In other
terms, how can you tell apart a TRNG from a good cypher?

BYtE,
 Diego.

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

Re: Transfer subkey to other keyring

[Jack Bates]

On 07/09/13 07:10 AM, Peter Lebbing wrote:

On 27/06/13 18:55, Jack Bates wrote:

except that I am using the key id of a subkey, with an exclamation
mark, to export just one subkey instead of all the subkeys belonging to the
primary key. The subkey with that key id definitely doesn't already exist in the
destination keyring, although the destination keyring does already contain a
different subkey.


I believe once GnuPG has a secret key, it won't update it anymore with any
subsequent imports. So to get the additional subkey, re-export the whole thing,
delete the existing one on the other system and import your re-exported whole 
thing.

I'm also wondering why you're being so explicit about it in the first place,
with transferring little chunks at a time using the exclamation mark instead of
the whole thing. Is there something specific you're trying to achieve?


gpg:  secret keys unchanged: 1


This message to me implies it is actually possible to change something about a
secret key. I haven't figured out what yet.


Thank you for following up Peter, I looked again and I think it's a 
difference between public vs. secret subkeys. It will merge a new public 
subkey with existing subkeys, but it won't merge a new secret subkey 
with existing ones. Here is a first crack at a patch to merge new secret 
subkeys similar to how it already handles public ones:


   http://nottheoilrig.com/gnupg/201309120/merge.patch

I'd love to contribute a change like this to GnuPG, would a change like 
this be welcome? (considered for inclusion?) If so, can anyone help me 
review it and get it into shape? What is the right way to submit a patch 
to GnuPG?


Here's what GnuPG does before and after the patch:

   # Generate primary key
   $ gpg2 --gen-key

   pub   4096R/B575FAD1 2013-09-12
 Key fingerprint = 19C1 3488 6B2A A80C E30A  6A96 4CB2 EAFB 
B575 FAD1

   uid  John Doe 

   # Add subkey
   $ gpg2 --edit-key B575FAD1 addkey

   pub  4096R/B575FAD1  created: 2013-09-12  expires: never 
usage: SC

trust: ultimate  validity: ultimate
   sub  4096R/3BEA5E48  created: 2013-09-12  expires: 2013-09-13 
usage: S


   # Export secret subkey
   $ gpg2 --export-secret-subkeys 3BEA5E48! > 3BEA5E48

   # Add another subkey
   gpg2 --edit-key B575FAD1 addkey

   pub  4096R/B575FAD1  created: 2013-09-12  expires: never 
usage: SC

trust: ultimate  validity: ultimate
   sub  4096R/3BEA5E48  created: 2013-09-12  expires: 2013-09-13 
usage: S
   sub  4096R/1F01C58C  created: 2013-09-12  expires: 2013-09-13 
usage: S


   # Export other secret subkey
   $ gpg2 --export-secret-subkeys 1F01C58C! > 1F01C58C

   # Start over with an empty keyring
   $ rm -r ~/.gnupg

   # Import first subkey
   $ gpg2 --import 3BEA5E48

   gpg: key B575FAD1: secret key imported
   gpg: key B575FAD1: public key "John Doe " imported
   gpg: Total number processed: 1
   gpg:   imported: 1  (RSA: 1)
   gpg:   secret keys read: 1
   gpg:   secret keys imported: 1

Here's what it does before the patch:

   # Import second subkey
   $ gpg2 --import 1F01C58C

   gpg: key B575FAD1: already in secret keyring
   gpg: Total number processed: 1
   gpg:   secret keys read: 1
   gpg:  secret keys unchanged: 1

   $ gpg2 -K

   sec#  4096R/B575FAD1 2013-09-12
   uid  John Doe 
   ssb   4096R/3BEA5E48 2013-09-12

And here's what happens after the patch:

   # Import second subkey
   $ gpg2 --import 1F01C58C

   gpg: key B575FAD1: "John Doe " 1 new signature
   gpg: key B575FAD1: "John Doe " 1 new subkey
   gpg: key B575FAD1: "John Doe " 1 new signature
   gpg: key B575FAD1: "John Doe " 1 new subkey
   gpg: Total number processed: 1
   gpg:new subkeys: 2
   gpg: new signatures: 2
   gpg:   secret keys read: 1

   $ gpg2 -K

   sec#  4096R/B575FAD1 2013-09-12
   uid  John Doe 
   ssb   4096R/3BEA5E48 2013-09-12
   ssb   4096R/1F01C58C 2013-09-12

I looked at the code in gnupg/g10/import.c and when you import 
something, the import() procedure gets called once by 
import_keys_internal(), etc. The import_one() procedure gets called if 
import() finds a PKT_PUBLIC_KEY keyblock and import_secret_one() gets 
called if it finds a PKT_SECRET_KEY keyblock. After import_secret_one() 
imports a new secret key, it converts it to a public key with 
sec_to_pub_keyblock() and passes that to import_one().


import_one() and import_secret_one() both check if the key already 
exists in the keyring. If import_one() finds that it does, it reads the 
existing keyblock, calls merge_blocks(), and if anything changed it 
writes back the updated keyblock.


However if import_secret_one() finds that the key already exists, 
currently it just says:


1273 else if( !rc )
1274   { /* we can't merge secret keys */
1275 log_error( _("key %s: already in secret keyring\n"),
1276keystr_from_sk(sk));
1277 stats-

Re: lsign produces exportable signatures when used for self-sigs

[Nicholas Cole]

On Fri, Sep 13, 2013 at 12:22 AM, Daniel Kahn Gillmor
 wrote:
> GnuPG is currently not able to create a non-exportable self-sig.  If you
> try to do this, it gives an error:
>
>   WARNING: the signature will not be marked as non-exportable.
>
> But: some people might never want their keys to be published to the public
> keyservers, or have some User IDs that they keep locally that they do
> not want to be transmitted via the keyserver network.
>
> AIUI, keyservers should reject keys that do not have a self-signature.
> Keyservers should also honor the "non-exportable" marker by rejecting
> OpenPGP certification packets that have the "exportable" subpacket
> included and set to 0.
>
> So the sensible thing for a keyholder who wants their key to stay off
> the keyservers would be to issue a non-exportable self-signature.

I don't think this is sensible.  What is the point of a UID that
cannot be used by someone else?  If the UID is shared with anyone else
(even privately), it must have a self-signature, and so that signature
must be exportable.  If gpg starts --exporting keys with
non-self-signed UIDs, this will be a step backwards.

I see what you are trying to achieve, but I don't think this is the
right way to do it.  The correct way would be to have keyservers
honour the no-modify flag, or perhaps have some notation on the ID
that prevents uploading to a public keyserver.  I myself would favour
the latter approach.

N.

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

Re: lsign produces exportable signatures when used for self-sigs

[Peter Lebbing]

On 2013-09-13 14:24, Nicholas Cole wrote:

The correct way would be to have keyservers
honour the no-modify flag, or perhaps have some notation on the ID
that prevents uploading to a public keyserver.  I myself would favour 
the latter approach.


The latter has the same problem as the no-modify flag: it can be 
subverted by someone as long as the keyservers do not do crypto.


HTH,

Peter.

PS: I accidentally replied to Nicholas only. Using a different client 
than usually.


--
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: lsign produces exportable signatures when used for self-sigs

[David Shaw]

On Sep 13, 2013, at 1:22 AM, Daniel Kahn Gillmor  wrote:

> GnuPG is currently not able to create a non-exportable self-sig.  If you
> try to do this, it gives an error:
> 
> WARNING: the signature will not be marked as non-exportable.

This is by design (hence the warning message), as an unsigned user ID is not 
really meaningful as anyone could add it against the will of the keyholder, and 
a locally signed user ID is effectively unsigned.

David


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

newbie and smartcard, I'm lost.

[Didier]

Hi,
I'm a newbie ... and I would like to do file and mail encryption from
different PCs at different locations with gnupg.
In any case I would not like to copy my private key on other pcs!
As far as I understood, using a smartcard was the ideal solution as I
won't have to store my private keys on each pc. I would simply have to
use my smartcard f.ex. to encrypt a file with my private key on a
given PC when I need to.

Here is what I did so far, I generated keys on the card:
a) gpg2 --card-edit, and after admin command.
gpg/card> generate
Make off-card backup of encryption key? (Y/n) n

gpg: NOTE: keys are already stored on the card!

Replace existing keys? (y/N) y
What keysize do you want for the Signature key? (2048)
What keysize do you want for the Encryption key? (2048)
What keysize do you want for the Authentication key? (2048)
Please specify how long the key should be valid.
 0 = key does not expire
    = key expires in n days
  w = key expires in n weeks
  m = key expires in n months
  y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N)
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Test
Name must be at least 5 characters long
Real name: Test Test
Email address: t...@test.com
Comment:
You selected this USER-ID:
    "Test Test "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
gpg: key 7289B2FC marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m,
0f, 1u
pub   2048R/7289B2FC 2013-09-13
  Key fingerprint = F699 1939 18B7 C5E1 B01D  2D43 17D9 B703
7289 B2FC
uid  Test Test 
sub   2048R/9899BBE7 2013-09-13
sub   2048R/9E5C75ED 2013-09-13

1) Why did gpg create a secret key file secring.gpg  in the
%appdata%gnugpg directory, shouldn't the secret key file only be
stored on the smarcard?
here is a dir of %appdata%gnupg (the files generated at 15:00 were
created with the card admin generate command???)
13-Sep-13  14:50      private-keys-v1.d
13-Sep-13  15:00 1.751 pubring.bak
13-Sep-13  15:02 1.751 pubring.gpg
13-Sep-13  14:50 0 pubring.gpg.lock
13-Sep-13  14:50 8 reader_0.status
13-Sep-13  14:50    22 S.gpg-agent
13-Sep-13  14:50    22 S.scdaemon
13-Sep-13  15:00 1.826 secring.gpg
13-Sep-13  14:50 0 secring.gpg.lock
13-Sep-13  15:02 1.280 trustdb.gpg
13-Sep-13  14:50 0 trustdb.gpg.lock

Now I'm simulating a move to another computer and I'm renaming the
%appdata%gnugp to %appdata%gnupg.old
Now I'm reissuing the "gpg2 --card-status" command:
gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/secring.gpg' created
gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/pubring.gpg' created
Application ID ...: D27600012401020513B1
Version ..: 2.0
Manufacturer .: ZeitControl
Serial number : 13B1
Name of cardholder: Test Test
Language prefs ...: fr
Sex ..: male
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : forced
Key attributes ..: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 5
Signature key : F699 1939 18B7 C5E1 B01D  2D43 17D9 B703 7289
B2FC
  created : 2013-09-13 12:59:23
Encryption key: E0A0 95F9 646A 95ED F3E5  49A2 428B F92C 9E5C
75ED
  created : 2013-09-13 12:59:23
Authentication key: B925 6ED8 BEF6 F17F 7A4D  4E4E F5DC BD13 9899
BBE7
  created : 2013-09-13 12:59:23
General key info..: [none]

2) Why is "General key info" empty now? 
If I do a gpg2 --list-keys, no keys are listed anymore. 
3) How can I encrypt a mail or file with my smartcard now on another
PC without copying any files?

Thank you very much for helping me
Didier


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

Re: lsign produces exportable signatures when used for self-sigs

[Nicholas Cole]

On Fri, Sep 13, 2013 at 3:29 PM, Daniel Kahn Gillmor
 wrote:
> On 09/13/2013 08:24 AM, Nicholas Cole wrote:
>
>> I don't think this is sensible.  What is the point of a UID that
>> cannot be used by someone else?  If the UID is shared with anyone else
>> (even privately), it must have a self-signature, and so that signature
>> must be exportable.
>
> It is possible to share non-exportable signatures between private users.
>  see --import-options import-local in gpg(1).  I know there are GnuPG
> users who prefer to avoid having their keys on the public keyservers
> entirely, and who are willing to accept the costs of doing manual key
> distribution using non-exportable certifications.
>
>> If gpg starts --exporting keys with
>> non-self-signed UIDs, this will be a step backwards.
>
> those keys will not be accepted by anyone as valid, and users will have
> had to jump through hoops to create them as such, so they know what
> they're getting themselves into.
>
>> I see what you are trying to achieve, but I don't think this is the
>> right way to do it.  The correct way would be to have keyservers
>> honour the no-modify flag,
>
> Nearly every key created by GnuPG in the last decade has had the
> no-modify flag set.  There was never consensus about exactly what it
> means, or how to interpret it: does it mean that keyservers need primary
> key approval before publishing a third-party certification on an OpenPGP
> cert?  if so, how does the primary keyholder express that approval?  And
> no keyservers ever implemented it, because there was no unambiguous
> mechanism *to* implement.
>
> interpreting it to mean "do not publish on the keyservers at all" would
> mean almost no keys would be on the keyservers.
>
>>  or perhaps have some notation on the ID
>> that prevents uploading to a public keyserver.
>
> We have that already.   It's having the "exportable" subpacket included
> in the certification, with the content set to 0, meaning
> "non-exportable".  That's what i'm trying to do.
>
>> I myself would favour the latter approach.

I'll admit your solution is ingenious. But all the same, I think you
are trying to overload one clearly defined feature of the openpgp spec
- a non-exportable signature - to try and force keyservers not to
store UIDs.  I really don't favour this approach at all.

Section 5.2.3.11. (Exportable Certification) of the openpgp spec very
clearly defines what "local" signatures are to be used for.  Your
solution works only because gpg provides a way to export even
non-exportable signatures, but that is not guaranteed by the spec.

If the no-modify flag is a dead-end, then (as I suggested) I think a
new notation that keyservers could honour is the the way forward on
this.

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

Re: lsign produces exportable signatures when used for self-sigs

[Daniel Kahn Gillmor]

On 09/13/2013 10:17 AM, David Shaw wrote:
> On Sep 13, 2013, at 1:22 AM, Daniel Kahn Gillmor  
> wrote:
> 
>> GnuPG is currently not able to create a non-exportable self-sig.  If you
>> try to do this, it gives an error:
>>
>> WARNING: the signature will not be marked as non-exportable.
> 
> This is by design (hence the warning message), as an unsigned user ID is not 
> really meaningful as anyone could add it against the will of the keyholder, 
> and a locally signed user ID is effectively unsigned.

I'm not advocating for keyservers to traffic in (or for gpg to export or
import by default) keys with unsigned user IDs.  That would be a Bad Thing.

What i'm asking for is to make it possible for people who do not want
their key on the keyservers, ever, to be able to explicitly state it in
their self-signatures.  I hope this will not be a large class of users,
but i know it is a non-empty set.

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: lsign produces exportable signatures when used for self-sigs

[Nicholas Cole]

On Fri, Sep 13, 2013 at 3:42 PM, Daniel Kahn Gillmor
 wrote:
> On 09/13/2013 09:49 AM, Peter Lebbing wrote:
>> On 2013-09-13 14:24, Nicholas Cole wrote:
>>> The correct way would be to have keyservers
>>> honour the no-modify flag, or perhaps have some notation on the ID
>>> that prevents uploading to a public keyserver.  I myself would favour
>>> the latter approach.
>>
>> The latter has the same problem as the no-modify flag: it can be
>> subverted by someone as long as the keyservers do not do crypto.
>
> yes, pretty much anything can be published as long as the keyservers do
> not do crypto.  That's something that the keyservers need to fix, as it
> would prevent other problems as well.
>
> In the meantime, we can produce certifications that won't be
> misinterpreted by the keyservers as they currently exist, and can be
> validated by any future keyservers that do proper cryptographic checks.

Well. Why not trust your circle of contacts (because anyone using this
scheme must be in a small circle) not to upload the keys to
keyservers?

Perhaps if there is enough demand gpg could even have a "Never send
these keys to keyservers" option in the config file, taking a list of
fingerprints.

Just a thought.  I'm against doing something that goes against the
standard when there are other ways to achieve it.

N.

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

Re: lsign produces exportable signatures when used for self-sigs

[Daniel Kahn Gillmor]

On 09/13/2013 09:49 AM, Peter Lebbing wrote:
> On 2013-09-13 14:24, Nicholas Cole wrote:
>> The correct way would be to have keyservers
>> honour the no-modify flag, or perhaps have some notation on the ID
>> that prevents uploading to a public keyserver.  I myself would favour
>> the latter approach.
> 
> The latter has the same problem as the no-modify flag: it can be
> subverted by someone as long as the keyservers do not do crypto.

yes, pretty much anything can be published as long as the keyservers do
not do crypto.  That's something that the keyservers need to fix, as it
would prevent other problems as well.

In the meantime, we can produce certifications that won't be
misinterpreted by the keyservers as they currently exist, and can be
validated by any future keyservers that do proper cryptographic checks.

--dkg



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

Re: lsign produces exportable signatures when used for self-sigs

[Daniel Kahn Gillmor]

On 09/13/2013 08:24 AM, Nicholas Cole wrote:

> I don't think this is sensible.  What is the point of a UID that
> cannot be used by someone else?  If the UID is shared with anyone else
> (even privately), it must have a self-signature, and so that signature
> must be exportable.  

It is possible to share non-exportable signatures between private users.
 see --import-options import-local in gpg(1).  I know there are GnuPG
users who prefer to avoid having their keys on the public keyservers
entirely, and who are willing to accept the costs of doing manual key
distribution using non-exportable certifications.

> If gpg starts --exporting keys with
> non-self-signed UIDs, this will be a step backwards.

those keys will not be accepted by anyone as valid, and users will have
had to jump through hoops to create them as such, so they know what
they're getting themselves into.

> I see what you are trying to achieve, but I don't think this is the
> right way to do it.  The correct way would be to have keyservers
> honour the no-modify flag,

Nearly every key created by GnuPG in the last decade has had the
no-modify flag set.  There was never consensus about exactly what it
means, or how to interpret it: does it mean that keyservers need primary
key approval before publishing a third-party certification on an OpenPGP
cert?  if so, how does the primary keyholder express that approval?  And
no keyservers ever implemented it, because there was no unambiguous
mechanism *to* implement.

interpreting it to mean "do not publish on the keyservers at all" would
mean almost no keys would be on the keyservers.

>  or perhaps have some notation on the ID
> that prevents uploading to a public keyserver.

We have that already.   It's having the "exportable" subpacket included
in the certification, with the content set to 0, meaning
"non-exportable".  That's what i'm trying to do.

> I myself would favour the latter approach.

great!

--dkg



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

Re: newbie and smartcard, I'm lost.

[Pete Stephenson]

On Fri, Sep 13, 2013 at 3:33 PM, Didier
 wrote:
>
>
> Hi,
> I'm a newbie ... and I would like to do file and mail encryption from
> different PCs at different locations with gnupg.
> In any case I would not like to copy my private key on other pcs!
> As far as I understood, using a smartcard was the ideal solution as I won't
> have to store my private keys on each pc. I would simply have to use my
> smartcard f.ex. to encrypt a file with my private key on a given PC when I
> need to.

Indeed. Sounds like a good plan.

> 1) Why did gpg create a secret key file secring.gpg  in the %appdata%\gnugpg
> directory, shouldn't the secret key file only be stored on the smarcard?

GPG creates a pseudo-secret key that includes "stubs" that tell GPG
that your private key is located on a card number with serial number
13B1. This pseudo-secret key (there's not actually anything secret
about it, as it's just the stubs) is stored in the secring.gpg.

The private key was generated entirely on the card and cannot be exported.

> Now I'm simulating a move to another computer and I'm renaming the
> %appdata%\gnugp to %appdata%\gnupg.old
> Now I'm reissuing the "gpg2 --card-status" command:
> gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/secring.gpg' created
> gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/pubring.gpg' created
> Application ID ..: D27600012401020513B1
> Version ..: 2.0
> Manufacturer .: ZeitControl
> Serial number : 13B1
> Name of cardholder: Test Test
> Language prefs ...: fr
> Sex .: male
> URL of public key : [not set]
> Login data ...: [not set]
> Signature PIN : forced
> Key attributes ...: 2048R 2048R 2048R
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : 5
> Signature key : F699 1939 18B7 C5E1 B01D  2D43 17D9 B703 7289 B2FC
>   created : 2013-09-13 12:59:23
> Encryption key: E0A0 95F9 646A 95ED F3E5  49A2 428B F92C 9E5C 75ED
>   created : 2013-09-13 12:59:23
> Authentication key: B925 6ED8 BEF6 F17F 7A4D  4E4E F5DC BD13 9899 BBE7
>   created : 2013-09-13 12:59:23
> General key info..: [none]
>
> 2) Why is "General key info" empty now?
> If I do a gpg2 --list-keys, no keys are listed anymore.
> 3) How can I encrypt a mail or file with my smartcard now on another PC
> without copying any files?

If I remember correctly, you need to import the public key (whether
from the keyserver, a flash drive, or some other storage medium) to
that computer, insert the card, run "gpg --card-status", the General
Key Info will be correctly populated, and new pseudo-secret stubs will
be created, and you'll be able to use the smartcard on that system.

If you put your public key online somewhere (say on your website, by
itself, in a text file) you can program that URL into your smartcard
in the "URL of public key" section (gpg --card-edit, admin, url). When
you get to a new computer, you can insert the card, run "gpg
--card-edit", then run "fetch" and GPG will fetch the public key from
that URL. If there's no URL entered then I think it will attempt to
retrieve the public key from the keyserver but you might want to
check.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: lsign produces exportable signatures when used for self-sigs

[Daniel Kahn Gillmor]

On 09/13/2013 11:35 AM, Nicholas Cole wrote:
> Well. Why not trust your circle of contacts (because anyone using this
> scheme must be in a small circle) not to upload the keys to
> keyservers?
> 
> Perhaps if there is enough demand gpg could even have a "Never send
> these keys to keyservers" option in the config file, taking a list of
> fingerprints.

Because I want to be able to make it clear *to the keyservers*, not to
"the circle of contacts" that are using the key.  People make mistakes;
people change allegiances; people can be coerced.

I am talking about a statement made by the keyholder, about how they
want their key to propagate or not propagate.  We have a standard that
makes clear how to express this intent.  It makes sense to embed the
desired instructions in the key itself.

> Just a thought.  I'm against doing something that goes against the
> standard when there are other ways to achieve it.

I don't think anything that I have proposed here is in any way against
the standard.

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: Why trust gpg4win?

[Jan]

In 09/13/2013 14:05, NdK wrote:

> Some other approach might be to compare the output of several
> versions of gnuPG, PGP etc.. This way you could check whether the
> information was secretly decrypted with a second "FBI key". This is 
> even

> possible for someone how is no programer. Do you think checking the
> output in that way is useful?

No. You can only check if the protocol is followed accurately.
How can you check there isn't a weakness in RNG, for exampel [...]


There are statistical test with which you can test whether a random number 
generator produces for instance uniformly distributed numbers. This in 
connection with the above procedure might make a good output oriented check 
of gnuPG.


Kind regards,
Jan 



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

Re: Why trust gpg4win?

[Jan]

On 09/13/2013 14:05, NdK wrote:

What happens if one of your correspondents is willing to undergo the
whole procedure and he's an FBI agent?

I'd tell him confidential information, - but I did not intent to protect
me against such a thread by means of gnuPG.


If you want to
certify that your security perimeter is secure, you first have to
accurately define where it is and the threat model. And even then you
can only certify it's secure against the attacks you could think of.


That is a good point. On this list I learned about the existence of some 
vectors I did not even think of. Thank you for that information. Is there a 
book on thread models which list widely known attack vectors?


OK, so I'll try to define two thread models.

The setup:
Assume there is a windows PC connected to the internet (online PC) and an 
USB device with debian on it where the network drives are uninstalled 
(offline PC). The USB device is only plugged into the machine, if windows is 
not running. The windows PC has a FAT partition. Encrypted emails/files 
downloaded with windows are stored there. After reboot the FAT partition is 
mounted with debian and the emails/files are decrypted. The reverse 
procedure (answer to the email) runs analogously. Only simple file formats 
are accepted.


Thread models:
1. There might be a Trojan on the windows machine.

2. There might be a Trojan on the windows machine and someone might steel 
the USB device from my apartment.


I don't care about hardware key loggers, TEMPEST, cold boot attacks or 
cameras installed in my apartment. In the second thread model the USB device 
would have an encrypted root partition. Another scenario is that instead of 
the USB device there is a real offline PC and file transfer between the two 
machines happens only via CD-RW or multisession CD-R.


Kind regards,
Jan 



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

Re: Why trust gpg4win?

[NdK]

Il 13/09/2013 21:12, Jan ha scritto:

>> How can you check there isn't a weakness in RNG, for exampel [...]
> There are statistical test with which you can test whether a random
> number generator produces for instance uniformly distributed numbers.
> This in connection with the above procedure might make a good output
> oriented check of gnuPG.
A good encryption algorithm should generate an output that you can't
tell is not purely random. That's why you have to compress the data
BEFORE encrypting it.
Then the output is usually "decorated" with data structures to make it
recognizeable and not attempt decrypting it the wrong way.

BYtE,
 Diego.

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

Re: Where is ECC in gpg2 (specifically gnupg-2.0.21

[Werner Koch]

On Fri, 13 Sep 2013 13:25, joh...@vulcan.xs4all.nl said:

> Such a major change would warrant a 1.6 IMO.

Sure.

> BTW, is there any discussion in the OpenPGP community about other public
> key systems, like NTRUEncrypt (see

No, I am not aware of any discussions.  QC resistant algorithms are not
yet something we need to rush for.  We can't predict the future, but
anyway it is good to know that even with today's technologies there are
ways to mitigate an eventual QC based public key break.  In this light
the discussions about the need for 8k RSA now is as reliable as coffee
grounds reading

> IMO ECC has at least some questions about it since the NSA is pushing
> it. That could be because they know of weaknesses in it, or because they

There are of course sound reasons why they suggest the use of ECC.  With
about 30 years of research, ECC has a pretty solid theoretical
foundation.  The reasons why the seeds for the NIST curve parameters
have not been recorded should of course raise more doubts now - I don't
think that the DES history has a sequel here.


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: Should the use of multiple UID per key be discouraged?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Tuesday 10 September 2013 at 8:01:30 PM, in
, Philipp Klaus Krause wrote:




> GPG supports the feature of having multiple UIDs per
> key. However this requires special care of anyone
> signing such a key. AFAIK, there is no really
> user-friendly, and definitely no newbie-friendly way to
> do so.


I have often seen mention of (but not personally used) CA - Fire and
Forget (CAFF)


   "CA Fire and Forget is a script that helps you in keysigning.  It takes
   a list of keyids on the command line, fetches them from a keyserver and
   calls GnuPG so that you can sign it.  It then mails each key to all its
   email addresses - only including the one UID that we send to in each
   mail, pruned from all but self sigs and sigs done by you.  The mailed
   key is encrypted with itself as a means to verify that key belongs to
   the recipient."

- --
Best regards

MFPAmailto:expires2...@ymail.com

Never lean forward to push an invisible object.
-BEGIN PGP SIGNATURE-

iQCVAwUBUjOhB6ipC46tDG5pAQoShAP/ZFKmvB+GdDapfBdKUDDYXUH62YDI8i9K
4eAquDk0ei/zLzQ3pZXkDAKsrvAkCcvzwSZe3m6qY8DtNlxiJ1WqEg1atL5wVCwq
E3QaiagGkHedaQWdMYGhjXNcwXl+N2mH5iXD/WBgEOrq+3yU7MMyhbnfi08wBfnf
MbMmpttqnyc=
=Xs9k
-END PGP SIGNATURE-


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

Re: Where is ECC in gpg2 (specifically gnupg-2.0.21

[Robert J. Hansen]

On 9/13/2013 6:20 PM, Werner Koch wrote:
> No, I am not aware of any discussions.  QC resistant algorithms are not
> yet something we need to rush for.

Although it hasn't hit the IETF WG mailing list, I know that some list
participants have had intermittent off-list conversations about lattice
cryptography and other QC-resistant crypto.  I wouldn't say that it's a
subject of active discussion within the WG, but some individual WG
members are definitely keeping an eye on it.

And let me give a big "d'accord!" to Werner's "we don't need to rush."



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