Nabble - GnuPG - Dev

Re: gpgconf --list-dirs correct?

2009-12-09T09:04:45Z

> Why is "libdir" reporting /usr/lib/gnupg ? There is no such directory.

$ ls /usr/local/lib/gnupg
gpg-protect-tool pcsc-wrapper

However, this depends on your system.

> Who is the consumer or the "--list-dirs" output?

It is basically internal to GnuPG. It is an interface to internal
functions. Don't care about it.

Salam-Shalom,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: gpgconf --list-dirs correct?

2009-12-09T07:29:29Z

Werner Koch wrote:

> On Tue, 08 Dec 2009 14:12:10 -0500, Wyllys Ingersoll wrote:
>
>> The gpgconf --list-dirs command tacks on "gnupg" to the end of
>> the preconfigured libdir and datadir pathnames, is this correct?
>
> Yes. These are the gnupg specific directories.
>
>
> Salam-Shalom,
>
> Werner
>

Why is "libdir" reporting /usr/lib/gnupg ? There is no such directory.
I'm just confused because when I ran the "configure" script to build
the package, I specify "--libdir=/usr/lib".

Who is the consumer or the "--list-dirs" output?

Thanks,
-Wyllys

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: gpgconf --list-dirs correct?

2009-12-09T02:33:39Z

On Tue, 08 Dec 2009 14:12:10 -0500, Wyllys Ingersoll wrote:

> The gpgconf --list-dirs command tacks on "gnupg" to the end of
> the preconfigured libdir and datadir pathnames, is this correct?

Yes. These are the gnupg specific directories.

Salam-Shalom,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Read-only keyring and the keybox

2009-12-09T02:32:05Z

> F.e. http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups
> states under "Known problems" that "[...] GPG will look for the first
> key in the keyring to decrypt things." What a hassle to set up a
> smartcard subsequently.

That is simply not true. An OpenPGP message describes the key to be
used for decrytion by including the long key id in the message. This
keyid is then used to lookup the key. If it happens to be on a
smartcard, the smartcard is used.

The problems you may have is with messages also including keys with
wildcard keyids (--throw-keyids). In that case there is no well
defined order of keys to try. See this comment in g10/mainproc.c:

/* FIXME: Store this all in a list and process it later so that
we can prioritize what key to use. This gives a better user
experience if wildcard keyids are used. */

It has nothing to do with the smartcards.

> Oh, why I'm advocating to use the fingerprint instead of the short
> keyid above: I've come across a case where fetching a key via the
> usual gpg --recv-keys 0xdeadbeef method yielded 2 matching keys (if
> you must know, check for 0x76B8337A on subkeys.pgp.net).

Of course there are duplicated keyids out in th ewild; use the long
keyid in your conf file or - as you say - the fingerprint.

> Needless to say that the wrong key was used in operation (that could
> have been attributed just as well to my setup) but people expect to
> get a single key, not each key matching the shortid format. So, to
> make a rather verbose story short: Please adapt documentation
> accordingly.

I don't understand this. Key selection is matter of the mailer and
not of GPG.

Shalom-Salam,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Read-only keyring and the keybox

2009-12-08T14:24:06Z

* Werner Koch <wk@...> wrote:

> On Sun, 6 Dec 2009 22:00:40 +0100, markus reichelt wrote:
> > While you are at it, would it be possible to also address the
> > issue of using multiple smartcards?
>
> What do you mean by that? Support for several readers?

That would be nice too. But I think it's more important to be able to
use multiple smartcards per user - with the same reader.

F.e. http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups
states under "Known problems" that "[...] GPG will look for the first
key in the keyring to decrypt things." What a hassle to set up a
smartcard subsequently.

It would be nice to have some option like "--cardkey fingerprint" to
pass to gnupg in order to achieve that. I realize that a new format
like keybox is not really necessary to accomplish that, but while you
are brainstorming a major pillar of gnupg it's worth mentioning, in
my book.

Maybe it's even as simple as adapting gnupg's check for secret keys
present in the (primary) keyring to just look for a cardreader with
inserted card. Don't know, I haven't dived into the depths of the
source code.

Oh, why I'm advocating to use the fingerprint instead of the short
keyid above: I've come across a case where fetching a key via the
usual gpg --recv-keys 0xdeadbeef method yielded 2 matching keys (if
you must know, check for 0x76B8337A on subkeys.pgp.net).

Needless to say that the wrong key was used in operation (that could
have been attributed just as well to my setup) but people expect to
get a single key, not each key matching the shortid format. So, to
make a rather verbose story short: Please adapt documentation
accordingly.

--
left blank, right bald

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (853 bytes) Download Attachment

gpgconf --list-dirs correct?

2009-12-08T11:12:10Z

The gpgconf --list-dirs command tacks on "gnupg" to the end of
the preconfigured libdir and datadir pathnames, is this correct?

For example:

$ gpgconf --list-dirs
sysconfdir:/usr/etc/gnupg
bindir:/usr/bin
libexecdir:/usr/libexec
libdir:/usr/lib/gnupg
^^^^^^
datadir:/usr/share/gnupg
^^^^^^
localedir:/usr/share/locale
dirmngr-socket:/var/run/dirmngr/socket
...

-Wyllys Ingersoll

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: new contributor?

2009-12-08T02:48:34Z

Hi Frédéric,

I thing this thread is better to have it in the gcrypt list. Can I ask
you for some help in the elliptic curve encryption? The implementation
of the future standart [1] is giving me some implementations
headaches.

Also the mathematical primitives over the finite fields can be
optimized because in elliptic curves we use a shorter field, but we
call them many more times.

About how to manage your contribution, I am not the good one to answer
you. As far as I know, you there are some types of agreements that can
help in how will be your contribution.

Finally, only say good luck and book some time to develop!

/Sergi.

[1] http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-03

2009/12/6 Frédéric Yhuel <yhuelf@...>:

> Hello,
>
> I recently graduate from Grenoble university (France), where I
> attended a M Sc in Mathematics and Cryptology. I would like to
> contribute to GNU PG project, and one of my former teacher told me you
> may need help for the ECDSA test. If it is the case, or if you need
> help somewhere else, please let me know. I will do my best to be
> useful and to not get (too much) in the way.
>
> BR,
> Frédéric Yhuel
>
> PS I've tried to subscribe to gcrypt-devel mailing list, but it seems
> that the sever doesn't accept gmail addresses.
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@...
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Read-only keyring and the keybox

2009-12-07T01:54:23Z

On Sun, 6 Dec 2009 22:00:40 +0100, markus reichelt wrote:
> While you are at it, would it be possible to also address the issue
> of using multiple smartcards?

What do you mean by that? Support for several readers?

Salam-Shalom,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

new contributor?

2009-12-06T14:16:04Z

Hello,

I recently graduate from Grenoble university (France), where I
attended a M Sc in Mathematics and Cryptology. I would like to
contribute to GNU PG project, and one of my former teacher told me you
may need help for the ECDSA test. If it is the case, or if you need
help somewhere else, please let me know. I will do my best to be
useful and to not get (too much) in the way.

BR,
Frédéric Yhuel

PS I've tried to subscribe to gcrypt-devel mailing list, but it seems
that the sever doesn't accept gmail addresses.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Read-only keyring and the keybox

2009-12-06T13:00:40Z

* Werner Koch <wk@...> wrote:

> Complaints about multiple keyrings are an old topic but one we
> eventually need to solve.

While you are at it, would it be possible to also address the issue
of using multiple smartcards?

--
left blank, right bald

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (205 bytes) Download Attachment

Re: Read-only keyring and the keybox

2009-12-05T08:53:54Z

On Fri, Dec 04, 2009 at 03:49:49PM +0100, Werner Koch wrote:

> Complaints about multiple keyrings are an old topic but one we
> eventually need to solve. Daniel Leidert recently opened a bug for it

FWIW, I had difficulties with multiple and/or read-only keyrings until
--primary-keyring was introduced, which has been a great improvement.

> These bug reports are sometimes mixing two different issues: The
> debian-keyring and r/o keyrings for other purposes.

> The other issue is that of multiple keyrings. Over the years we tried
> several approaches to get it right but none of them worked reliable.
> The problem is the usual one of keeping two databases in sync.
> Aggravated by the requirement to keep some of them read-only but still
> allowing to update them somehow. Approaches like preferring the
> writable one over the read-only one work in theory but will lead to
> administrative headaches. We will never be sure which keyblock is
> actually used. (I had a similar problem today with VPATH builds where

It is a pain to manually/administratively ensure no key is used from
or kept in multiple keyrings, but that is generally what I have done.
Given that any GPG process should only be using one trustdb.gpg at
a time, I think it is acceptable to merge (in memory) all key material
found in multiple keyrings, recalculate trust/trustdb.gpg "stuff,"
and proceed as though only one keyring held all the key material.
When it is necessary to update a key on disk, the --primary-keyring
or first available writable keyring wins. (Non-exportable data must
remain in the file(s) in which it was found. New non-exportable data
must only be written to --primary-keyring.)

Speeding up finding one or more copies of all desired keys in one
or more keyrings is a separate issue (addressed below).

> What I plan with GnuPG 2.1 is to rework the keyring situation by
> replacing keyrings it with a new format (keybox). This new format
> allows to keep meta data and also will boost key access times. This
> will make it possible to flag keys as read-only or allow updates only

I think metadata is excellent, but GPG will always run into files
holding key material that are themselves marked read-only, no-change,
append-only, etc. at the OS level. Marking all keys in a keybox
file internally as read-only will be accompanied in a belt-and-
suspenders approach by also marking the file unchangeable at the
OS level by users who are sufficiently paranoid.

> with a new options set. I am actually working on 2.1. However,
> before we implement such extravagant feature it will be wetter to
> collect real world use cases. We should do this on gnupg-devel@.
>
> One such use case might be to automatically import certain keys into
> the keybox for future use. This is basically the idea of reading the
> writable keyring first and only then the read-only ring
> (write-on-demand). The solution I have in mind is to import such
> read-only keys using the established --auth-key-locate feature.

Rather than introducing a new format (keybox) for actual key material
or requiring that separate indices be kept for each keyring
(.gpg and .gpgidx?), why not add the needed metadata to trustdb.gpg
or some other single, suitable (and always-writable) file/database?

When the metadata and actual file sizes and file mtimes match for
all specified keyrings, and the combinations of offset, size/length,
fingerprint, and overall hash match the key(s) found in each file
for all keys being actively used, no further scanning of the specified
key files or updating of the centralized metadata need be done.

(When a file holding key material has changed in any detectable
way (depending on one's threat model), rescan the entire file
and update the central metadata store for that file. (Add a
command-line flag to rescan one or all specified keyrings or
to delete and rebuild all metadata if the file size + file mtime
method is not enough for the sufficiently paranoid.))

--
Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
jharris@... _|_ web: http://keyserver.kjsl.com/~jharris/
Got photons? (TM), (C) 2004

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (322 bytes) Download Attachment

Read-only keyring and the keybox

2009-12-04T06:49:49Z

Hi!

Complaints about multiple keyrings are an old topic but one we
eventually need to solve. Daniel Leidert recently opened a bug for it
listing several threads in the Debian BTS [1]. Below is my comment.
I'd really like to move forward on this issue. It will be quite some
work. I need to see how fast I can accomplish it while not having a
project to financial backing the development.

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

The debian keyring is afaik used with gpgv and has the special
property that all keys in it are fully trusted. In short: It is a set
of keys only to be used by gpgv. Thus the issue is how to create this
keyring. Currently I suggest to use gpg --export LIST-OF-KEYIDS to
create it. In some distance future a little conversion tool might be
required to convert the OpenPGP transport format for keys into the
database format used by gpgv. The bottom line is that I don't see
that as an issue and the Debian readme seems to support this point of
view.

The other issue is that of multiple keyrings. Over the years we tried
several approaches to get it right but none of them worked reliable.
The problem is the usual one of keeping two databases in sync.
Aggravated by the requirement to keep some of them read-only but still
allowing to update them somehow. Approaches like preferring the
writable one over the read-only one work in theory but will lead to
administrative headaches. We will never be sure which keyblock is
actually used. (I had a similar problem today with VPATH builds where
two different header files, both are created from the same source,
provoked a bug in certain environments - not particular easy to
understand what was going on)

What I plan with GnuPG 2.1 is to rework the keyring situation by
replacing keyrings it with a new format (keybox). This new format
allows to keep meta data and also will boost key access times. This
will make it possible to flag keys as read-only or allow updates only
with a new options set. I am actually working on 2.1. However,
before we implement such extravagant feature it will be wetter to
collect real world use cases. We should do this on gnupg-devel@.

One such use case might be to automatically import certain keys into
the keybox for future use. This is basically the idea of reading the
writable keyring first and only then the read-only ring
(write-on-demand). The solution I have in mind is to import such
read-only keys using the established --auth-key-locate feature.

Shalom-Salam,

Werner

[1] https://bugs.g10code.com/gnupg/issue1129

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Change s2k count?

2009-12-04T03:00:42Z

On Thu, 03 Dec 2009 10:54:32 +0100, Werner Koch wrote:

> For passphrase protected secret keys, passphrase caching helps to
> avoid delays.

That is of course a wrong statement. Passphrase caching does not help
because the passphrase is cached and not the derived protection key.

In this light a 100ms delay is too long. I sometimes get messages
with wildcard keyids. Thus gpg needs to do a couple of trial
decryption and for say 5 available secret keys, this adds up to 500ms
- definitely too long for quickly browsing your mails.

With gpg-agent we could implement a different way of caching but first
we need to integrate gpg2 better with gpg-agent.

Salam-Shalom,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Change s2k count?

2009-12-03T13:26:01Z

Daniel Kahn Gillmor wrote:
> actually, i think getting as high a count as possible is a good goal,
> based on a few assumptions:

By the same reasoning, everyone should be using RSA-4096 for their keys.

> 0) we're talking about secret key material, which is to be
> symmetrically-encrypted with the user's passphrase.

Yep.

> 1) such secret key material is very rarely legitimately transferred
> between machines.

Yep.

> 2) a delay of 0.1 seconds between passphrase entry and access to the
> secret key is an acceptable delay in the case of legitimate use of the key.

Substitute in "a delay of 0.1 seconds for each encryption/decryption"
and this applies.

> 3) if the encrypted key is somehow transferred off the machine, we want
> it to be as expensive as possible to brute force the symmetric encryption.

Substitute in "we want it to be as expensive as possible to brute force
the encrypted message" and this applies.

... Of course, not everyone should be using RSA-4096. 2k keys are
appropriate for the overwhelming majority of users. The point is not to
get the highest numbers possible. The point is to satisfy the
conditions of the local security policy.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Change s2k count?

2009-12-03T13:05:50Z

On 12/03/2009 03:48 PM, Robert J. Hansen wrote:
> The point is not to get asymptotically as high a count as possible. The
> point is to get enough of a count to slow down brute forcers.

actually, i think getting as high a count as possible is a good goal,
based on a few assumptions:

0) we're talking about secret key material, which is to be
symmetrically-encrypted with the user's passphrase.

1) such secret key material is very rarely legitimately transferred
between machines.

2) a delay of 0.1 seconds between passphrase entry and access to the
secret key is an acceptable delay in the case of legitimate use of the key.

3) if the encrypted key is somehow transferred off the machine, we want
it to be as expensive as possible to brute force the symmetric encryption.

So i think the machine profiling step (using times, *not* gettimeofday)
to get an acceptable upper-bound is a quite reasonable thing to have in
place by default for key passphrase S2K usage.

I'm not so sure it makes sense for symmetrically-encrypted messages
other than secret key material, though, since the above assumptions
don't necessarily hold.

--dkg

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (909 bytes) Download Attachment

Re: Change s2k count?

2009-12-03T12:48:25Z

Daniel Kahn Gillmor wrote:
> I like the elegance of this solution, but couldn't this calculation be
> confounded by other load on the processor? For example, if i'm
> generating a new key (or changing a passphrase) while also encoding
> video, it would be a shame if gpg were to pick a too-low value.

As you said, there's an easy fix. Why check times/gettimeofday when the
lower-bound method works just as well?

The point is not to get asymptotically as high a count as possible. The
point is to get enough of a count to slow down brute forcers.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Supressing Passphrase messages

2009-12-03T12:41:44Z

On AIX, I am using the following command for decrypting:
/usr/local/bin/gpg --passphrase-file ./.gnupg/passphrase.txt -o ${OUTFILE} -d ${INFILE}

The decryption works fine, but the end-user always sees the following verbage that messes up the screen:

Reading passphrase from file descriptor 3

You need a passphrase to unlock the secret key for
user: "`XXXX (comment) "
1024-bit ELG-E key, ID YYYYY, created 2009-10-19 (main key ID ZZZZZ)

HOW CAN I KEEP THIS FROM DISPLAYING?
I also added > /dev/null 2>&1 to send the text to the bitbucket, but it still displays!!!

Re: Change s2k count?

2009-12-03T09:06:03Z

On Dec 3, 2009, at 11:46 AM, Daniel Kahn Gillmor wrote:

> On 12/03/2009 10:58 AM, David Shaw wrote:
>> PGP calculates whatever count your computer can do in 1/10 of
>> a second and uses that. It seems like a reasonable solution to
>> me. If someone explicitly sets a --s2k-count, we'll use what
>> they set. If they don't, we can do the 1/10-second calculation.
>
> I like the elegance of this solution, but couldn't this calculation be
> confounded by other load on the processor? For example, if i'm
> generating a new key (or changing a passphrase) while also encoding
> video, it would be a shame if gpg were to pick a too-low value.
>
> I suppose i'm suggesting that it would be important to check times(2)
> instead of gettimeofday(2) (on POSIX systems, anyway, i dunno about
> win32), but also that it would be good to retain a lower-bound as a
> sanity check (perhaps the current value could be a lower-bound unless
> explicitly specified by the user).

There will of course be a lower bound (probably should be larger than 65536, actually).

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Change s2k count?

2009-12-03T08:46:03Z

On 12/03/2009 10:58 AM, David Shaw wrote:
> PGP calculates whatever count your computer can do in 1/10 of
> a second and uses that. It seems like a reasonable solution to
> me. If someone explicitly sets a --s2k-count, we'll use what
> they set. If they don't, we can do the 1/10-second calculation.

I like the elegance of this solution, but couldn't this calculation be
confounded by other load on the processor? For example, if i'm
generating a new key (or changing a passphrase) while also encoding
video, it would be a shame if gpg were to pick a too-low value.

I suppose i'm suggesting that it would be important to check times(2)
instead of gettimeofday(2) (on POSIX systems, anyway, i dunno about
win32), but also that it would be good to retain a lower-bound as a
sanity check (perhaps the current value could be a lower-bound unless
explicitly specified by the user).

--dkg

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (909 bytes) Download Attachment

Re: Change s2k count?

2009-12-03T07:58:02Z

On Dec 3, 2009, at 4:54 AM, Werner Koch wrote:

> I doubt that keeping highly confidential keys on a smartphone is a
> good idea at all. On most devices (notable exception is the Neo
> Freerunner) you don't entirely control the device due to malware and
> the phone system operator's ability to gain access to it.

Not wise, I agree. But people do keep all sorts of stuff on their phone. I seem to recall that the Blackberry has an OpenPGP client that keeps keys locally (if someone knows one way or the other for sure, please jump in).

>> dropping. If 65536 was the right value for 11 years ago, we
>> probably could do with a brief discussion on whether we should raise
>> it for today (and if so, how much).
>
> I agree. I heard that PGP measures the performance during key
> generation and selects the S2K count depending on that value. Most
> people are using their keys on just one machine and thus it would fit
> their needs. If they are switching to another hardware they can
> easily change the passphrase and thus use a new S2K count.

PGP calculates whatever count your computer can do in 1/10 of a second and uses that. It seems like a reasonable solution to me. If someone explicitly sets a --s2k-count, we'll use what they set. If they don't, we can do the 1/10-second calculation.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Change s2k count?

2009-12-03T01:54:32Z

On Mon, 30 Nov 2009 10:29:08 -0500, David Shaw wrote:

> There are a number of factors: obviously we must take care with the
> setting here - too high and it can make decrypting with a passphrase
> (either a secret key decryption or a passphrase protected message)

I don't consider the latter a real problem. If you use symmetric only
encryption it is very likely that you are working in a custom
environment which is for example needed to take care about key
management. In that case you can setup a non-default s2k count.

In the rare case that you receive symmetric only message, you got the
key by, say, phone and conveying the key takes some time anyway. Thus
an extra delay on a small device should not be too troublesome.

For passphrase protected secret keys, passphrase caching helps to
avoid delays.

> It could be argued that cell phone usage actually needs the iterated
> hash even more as typing a long high-entropy passphrase is extremely
> difficult on a cell phone.

I doubt that keeping highly confidential keys on a smartphone is a
good idea at all. On most devices (notable exception is the Neo
Freerunner) you don't entirely control the device due to malware and
the phone system operator's ability to gain access to it.

> dropping. If 65536 was the right value for 11 years ago, we
> probably could do with a brief discussion on whether we should raise
> it for today (and if so, how much).

I agree. I heard that PGP measures the performance during key
generation and selects the S2K count depending on that value. Most
people are using their keys on just one machine and thus it would fit
their needs. If they are switching to another hardware they can
easily change the passphrase and thus use a new S2K count.

Shalom-Salam,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] - gpgme mkstatus

2009-12-02T09:07:59Z

Werner Koch wrote:

>> gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris),
>> awk and gawk are not the same and only 'gawk' will work correctly.
>
> Can you point out the gawk specific suff we use? The script is
> intended to work with a POSIX or other commonly used awk.
>
>
> Shalom-Salam,
>
> Werner
>

I get the following error when building with the standard 'awk' (/usr/bin/awk) in
Solaris:

./mkstatus < ./gpgme.h > status-table.h
awk: syntax error near line 3
awk: bailing out near line 3

The "awk" statement in mkstatus looks like this:
awk '
/GPGME_STATUS_ENTER/ { okay = 1 }
!okay { next }
/}/ { exit 0 }
/GPGME_STATUS_[A-Za-z_]*/ { sub (/,/, "", $1); printf " { \"%s\", %s },\n", substr($1,14), $1 }
' | sort

The standard Solaris awk doesn't like the "!okay" expression.
That is easy enough to fix, change it to "okay == 0" and it doesn't complain.

However, that exposes a larger issue with Solaris /usr/bin/awk - it doesn't support the "sub"
statement.

Switching to 'gawk' is the easiest fix.

-Wyllys

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] - gpgme gpgconf.c

2009-12-02T05:59:51Z

Wyllys Ingersoll wrote:
> There is a minor bug in gpgme/src/gpgconf.c which causes it to fail to compile with
> some compilers. gpgme_conf_arg_release is declared a "void" function but it is
> currently coded to return the results of _gpgme_conf_arg_release

Werner put it in, thanks for reporting it.

Marcus

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] - pinentry secmem/util.c

2009-12-02T00:14:46Z

Hi!

I removed it:

* secmem/util.c: Re-indent function names.
(TEMP_FAILURE_RETRY): Remove because it is non-portable.
(xwrite): Open code the EINTR retry.

Thanks,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] - pinentry pinentry-curses.c

2009-12-02T00:06:01Z

Hi!

On Tue, 01 Dec 2009 16:00:40 -0500, Wyllys Ingersoll <Wyllys.Ingersoll@...> wrote:
> pinentry-curses.c has a switch statement that looks for
> characters like "\t" and "\e", it should use numerical values
> for these constants, different compilers intepret the characters
> differently which results in unexpected behavior.

I agree that \e is a non-standard extension and should be replace.
However \t is a TAB and that is the same on all ASCII based systems.
Right, we don't care about EBCDIC.

Salam-Shalom,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] - gpgme mkstatus

2009-12-02T00:02:59Z

> gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris),
> awk and gawk are not the same and only 'gawk' will work correctly.

Can you point out the gawk specific suff we use? The script is
intended to work with a POSIX or other commonly used awk.

Shalom-Salam,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[PATCH] - pinentry secmem/util.c

2009-12-01T13:03:15Z

Attached is a patch for the pinentry secmem/util.c file.

The TEMP_FAILURE_RETRY macro uses "__extension__" which is unsupported
on some compilers and will cause the build to fail. I'm not sure it is
necessary or helpful in the first place.

-Wyllys Ingersoll

--- secmem/util.c.save Wed Oct 28 09:42:42 2009
+++ secmem/util.c Wed Oct 28 09:43:01 2009
@@ -34,11 +34,10 @@

#ifndef TEMP_FAILURE_RETRY
#define TEMP_FAILURE_RETRY(expression) \
- (__extension__ \
({ long int __result; \
do __result = (long int) (expression); \
while (__result == -1L && errno == EINTR); \
- __result; }))
+ __result; })
#endif

#ifndef HAVE_DOSISH_SYSTEM

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[PATCH] - pinentry pinentry-curses.c

2009-12-01T13:00:40Z

pinentry-curses.c has a switch statement that looks for
characters like "\t" and "\e", it should use numerical values
for these constants, different compilers intepret the characters
differently which results in unexpected behavior.

Attached is a patch against the source from the pinentry-0.7.6 tarball.

-Wyllys Ingersoll

--- pinentry/pinentry-curses.c.old Thu Apr 16 08:06:53 2009
+++ pinentry/pinentry-curses.c Mon Nov 9 08:23:40 2009
@@ -665,7 +665,7 @@
if (has_colors ())
{
start_color ();
- use_default_colors ();
+ /* use_default_colors (); */

if (pinentry->color_so == PINENTRY_COLOR_DEFAULT)
{
@@ -741,7 +741,7 @@
}
break;

- case '\t':
+ case '\011': /* HARD TAB */
switch (diag.pos)
{
case DIALOG_POS_PIN:
@@ -767,11 +767,11 @@
}
break;

- case '\e':
+ case '\005': /* ENQ */
done = -2;
break;

- case '\r':
+ case '\015': /* CR */
switch (diag.pos)
{
case DIALOG_POS_PIN:

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[PATCH] - gpgme mkstatus

2009-12-01T12:57:47Z

gpgme mkstatus should use "gawk" instead of "awk". On some platforms (Solaris),
awk and gawk are not the same and only 'gawk' will work correctly.

Attached is a patch.

-Wyllys Ingersoll

--- src/mkstatus.orig Fri Sep 25 08:22:00 2009
+++ src/mkstatus Fri Sep 25 08:21:41 2009
@@ -38,7 +38,7 @@
{
EOF

-awk '
+gawk '
/GPGME_STATUS_ENTER/ { okay = 1 }
!okay { next }
/}/ { exit 0 }

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[PATCH] - gpgme gpgconf.c

2009-12-01T12:56:03Z

There is a minor bug in gpgme/src/gpgconf.c which causes it to fail to compile with
some compilers. gpgme_conf_arg_release is declared a "void" function but it is
currently coded to return the results of _gpgme_conf_arg_release

The patch attached is against the tarball from 1.1.8:

-Wyllys Ingersoll
Sun Microsystems, Inc.

--- src/gpgconf.c.orig Wed Sep 23 09:38:36 2009
+++ src/gpgconf.c Wed Sep 23 09:38:42 2009
@@ -59,7 +59,7 @@
gpgme_conf_arg_release (gpgme_conf_arg_t arg, gpgme_conf_type_t type)
{
#ifdef ENABLE_GPGCONF
- return _gpgme_conf_arg_release (arg, type);
+ _gpgme_conf_arg_release (arg, type);
#endif
}

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Change s2k count?

2009-11-30T07:29:08Z

Hi everyone,

The discussion around s2k-count on gnupg-users made me think a bit about our current default there. The default s2k count has been 65536 iterations for (as best I can tell) pretty near the entire lifespan of GnuPG. Certainly it is at least 11 years as I see it in a code checkin from 1998.

There are a number of factors: obviously we must take care with the setting here - too high and it can make decrypting with a passphrase (either a secret key decryption or a passphrase protected message) unacceptably slow. In addition, there are other factors to consider, like uses today that didn't exist as much 11 years ago - slow CPUs in cell phones and the like, which would have a hard time with a large iteration count. Even so, most smartphone processors today are on par with or even faster than the average processor from 1998 (my own phone is roughly 2x faster than my 1998-era computer). It could be argued that cell phone usage actually needs the iterated hash even more as typing a long high-entropy passphrase is extremely difficult on a cell phone.

The bottom line is that the speed of the average processor today is vastly faster than what it was then, and so the cushion against passphrase guessers that the iterated hash was giving us is steadily dropping. If 65536 was the right value for 11 years ago, we probably could do with a brief discussion on whether we should raise it for today (and if so, how much).

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: SCM dicussion (Re: Where is >libassuan-1.1.0)

2009-11-26T10:51:09Z

On Thu, Nov 26, 2009 at 12:05:47PM +0100, Bernhard Reiter wrote:

> Am Montag, 23. November 2009 22:51:44 schrieb Ingo Krabbe:
> > > What is wrong with http://cvs.gnupg.org as stated on
> > > http://www.gnupg.org (download->cvs access).
> >
> > Some links are missing there: libassuan and libgpg-error as far as I can
> > see now.
>
> The links on cvs.gnupg.org are just shortcusts and not complete, check the
> selection box on top right of http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/
> (An improvement could be to mention that the list of shortcuts is not complete
> and to point the reader towards the selection box of the fulll version.)

Yes, thats the one I searched for. Thanks.

>
> --
> Managing Director - Owner: www.intevation.net (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@...
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

--
i don't do signatures

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

SCM dicussion (Re: Where is >libassuan-1.1.0)

2009-11-26T03:05:47Z

Am Montag, 23. November 2009 22:51:44 schrieb Ingo Krabbe:
> > What is wrong with http://cvs.gnupg.org as stated on
> > http://www.gnupg.org (download->cvs access).
>
> Some links are missing there: libassuan and libgpg-error as far as I can
> see now.

The links on cvs.gnupg.org are just shortcusts and not complete, check the
selection box on top right of http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/
(An improvement could be to mention that the list of shortcuts is not complete
and to point the reader towards the selection box of the fulll version.)

--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

smime.p7s (3K) Download Attachment

Re: Where is >libassuan-1.1.0

2009-11-23T13:51:44Z

On Mon, Nov 23, 2009 at 08:59:00PM +0100, Werner Koch wrote:
> On Mon, 23 Nov 2009 17:12, ikrabbe.ask@... said:
>
> > svn paths on a central place on gnupg.org, as I failed to find the libassuan one
> > for example and I don't think there is a way to access them, without knowing
>
> What is wrong with http://cvs.gnupg.org as stated on
> http://www.gnupg.org (download->cvs access).

Some links are missing there: libassuan and libgpg-error as far as I can see
now.

bye ingo

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: Where is >libassuan-1.1.0

2009-11-23T11:59:00Z

On Mon, 23 Nov 2009 17:12, ikrabbe.ask@... said:

> Actually there are strong reasons to use git, not just that it might be
> "en-vouge" and its possible to read in all the previously known tags and
> branches in svn or cvs into a new git repository, but finally its your

.. as well as changing the history without any traces left. Anyway, I
won't start a holy war on VCS stuff.

> svn paths on a central place on gnupg.org, as I failed to find the libassuan one
> for example and I don't think there is a way to access them, without knowing

What is wrong with http://cvs.gnupg.org as stated on
http://www.gnupg.org (download->cvs access).

Shalom-Salam,

Werner

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

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel