Mailing List Archive

[SNIP]

> * Encryption is now much faster: About 2 times for 1k bit keys
> and 8 times for 4k keys.

Excellent! I can go ahead and do a speed comparison of PGP vs GnuPG....

> * New encryption keys are generated in way which allows a much
> faster decryption.

Is this detailed in the source Werner?


Regards,

Sam Simpson
Communications Analyst
-- http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.

On Tue, 22 Feb 2000, Simpson, Sam wrote:

> > * New encryption keys are generated in way which allows a much
> > faster decryption.
>
> Is this detailed in the source Werner?

cipher/elgamal.c

It is just that the secret exponent x is not anymore about the same
size as the prime but much smaller. See wiener_map() to see the
actual sizes used. It is believed that an extra large exponent
does not gain any extra security.

Werner

(Replying just to -users, since it seems more appropriate, but feel free
to copy to -devel if you see a need I overlooked.)

On Tue, Feb 22, 2000 at 10:40:56AM +0100, Werner Koch wrote:
>
> Noteworthy changes in the current test release
> ----------------------------------------------
>
> * The user is now asked for the reason of revocation as required
> by the new OpenPGP draft.

I have not yet looked at either the new source, nor the new draft, (shame
on me) but if I read the above correctly, this seems to contradict the
intent behind the following excerpt from The GNU Privacy Handbook.

http://www.gnupg.org/gph/en/manual/c14.html#REVOCATION

Generating a revocation certificate

After your keypair is created you should immediately generate a
revocation certificate for the primary public key using the option
[15]--gen-revoke. If you forget your passphrase or if your private

How is the user to know in advance what the "reason for revocation"
will be? The intent behind generating the certificate *immediately*
after generating the keypair is obvious (and, IMO, laudable.) Am I
misreading something here?

Does this new OpenPGP draft expect the user to foresee the future when
generating this immediately-after-keypair-creation revocation certificate?
Or did the draft writers not think of this? (If so, someone please
forward this to the appropriate parties.)

As an aside, if this is in response to the recent changes in laws in
the UK, wouldn't inclusion of a reason (presuming it is "Jack Straw
and his buddies have access to my passphrase") mandate a significant
period of incarceration? Nevertheless, my primary concern is still
regarding prescience of revocation rationale; a protocol matter, not
a talk.politics.crypto matter.

Please advise me if there is a more appropriate channel for discussion
than gnupg-users. Where do I look for a copy of the proposed changes
to the OpenPGP draft? Is this a change to RFC 2440?

--
Please encrypt all mail whenever possible. The following Public Keys
for Lazarus Long <lazarus@overdue.ompages.com> are available upon request:

Type Bits/KeyID Fingerprint (GnuPG (GPG) is preferred.)
GPG/ELG: 2048g/41783186 47A0 0929 CD9F B53E 49C0 F06C 560E F574 ED0D F80C
GPG/DSA KeyID: ^^^^ ^^^^

You, Lazarus Long, wrote:

> How is the user to know in advance what the "reason for revocation"
> will be?

You don't - state for reason "standard safety precaution". After all, this
_IS_ the reason you're creating it. That also solves your other problem:

> As an aside, if this is in response to the recent changes in laws in
> the UK, wouldn't inclusion of a reason (presuming it is "Jack Straw
> and his buddies have access to my passphrase") mandate a significant
> period of incarceration?

When you really need the certificate you probably don't care about the exact
wording of the reason string any more.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

On Tue, 22 Feb 2000, Lazarus Long wrote:

> I have not yet looked at either the new source, nor the new draft, (shame
> on me) but if I read the above correctly, this seems to contradict the

The change is only that the new draft makes the reason for revocation
a SHOULD.

> How is the user to know in advance what the "reason for revocation"
> will be? The intent behind generating the certificate *immediately*
> after generating the keypair is obvious (and, IMO, laudable.) Am I
> misreading something here?

This is indeed a problem. The reason why you should create a
revocation certificate in advance, is for the case you lost access to
your secret key. Therefore you may wont to use "key is no longer used"
and a verbal description why. If your key is compromised, you should
still have access to the secret key and you can do a revocation
certificate. But, what happens if you lost your laptop with the only
copy of the secret key - it is compromised and you are not able to
revoke the key.

There are 3 solutions:

* Create 2 revocation certificates, one for a compromised key and
one for the cae you lost access to the key.

* Create only a compromised key revocation in advance and use this
even if you only can't remember the passphrase.

* I add an option to not generate a revocation certificate. This
should still be allowed even if OpenPGP says SHOULD (it is not a
MUST)

> As an aside, if this is in response to the recent changes in laws in
> the UK, wouldn't inclusion of a reason (presuming it is "Jack Straw

No, It has been been in OpenPGP since we have the RFC.

> Please advise me if there is a more appropriate channel for discussion
> than gnupg-users. Where do I look for a copy of the proposed changes
> to the OpenPGP draft? Is this a change to RFC 2440?

It is just that the optional reason for revocations is now a SHOULD.
It is okay to discuss this here.


Werner

Werner Koch writes:
> Hi,
>
> I did a new test release of gnupg in order to prepare for 1.0.2.
> Please get it from the usual places (see below for mirrors):
>
> ftp://ftp.gnupg.org/pub/gcrypt/devel/gnupg-1.0.1c.tar.gz (1535k)
> ftp://ftp.gnupg.org/pub/gcrypt/devel/gnupg-1.0.1c.tar.gz.sig
> ftp://ftp.gnupg.org/pub/gcrypt/devel/gnupg-1.0.1a-1.0.1c.diff.gz (299k)

I need two little changes to get it compiled on m68k-cbm-netbsd1.4.1
and m68k-unknown-linux-gnu. It's the same machine in both cases.

diff -ur gnupg-1.0.1c.orig/acinclude.m4 gnupg-1.0.1c/acinclude.m4
--- gnupg-1.0.1c.orig/acinclude.m4 Mon Oct 11 17:43:40 1999
+++ gnupg-1.0.1c/acinclude.m4 Mon Feb 28 01:19:32 2000
@@ -230,6 +230,10 @@
CFLAGS_RDYNAMIC=""
;;

+ netbsd* )
+ CFLAGS_RDYNAMIC="-Wl,--export-dynamic"
+ ;;
+
* )
CFLAGS_RDYNAMIC="-Wl,-export-dynamic"
;;

Disclaimer: I have no idea whether this is correct for other versions
of NetBSD, and other ports.

diff -ur gnupg-1.0.1c.orig/mpi/config.links gnupg-1.0.1c/mpi/config.links
--- gnupg-1.0.1c.orig/mpi/config.links Fri Dec 10 13:04:00 1999
+++ gnupg-1.0.1c/mpi/config.links Mon Feb 28 01:18:38 2000
@@ -121,6 +121,7 @@
m680[234]0*-*-linux* | m68k*-*-linux*)
echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h
cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h
+ path="m68k/mc68020 m68k"
;;
m68060*-*-linux*)
echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h

I am suprised that this was missing. Linux on m68k requires at
least an 68020. Without this change, the generic mpi modules are
used instead of the machine specific ones.

On the good side, gpg is now very close to building without GNU make.
NetBSD's make works almost everywhere now, except for the asm modules.
I haven't yet figured out how to make this work.

On Mon, 28 Feb 2000, Lars Hecking wrote:

> + netbsd* )
> + CFLAGS_RDYNAMIC="-Wl,--export-dynamic"
^^ two

> * )
> CFLAGS_RDYNAMIC="-Wl,-export-dynamic"
^ one

I guess one of them is wrong...

Walter

Walter Hofmann writes:
> On Mon, 28 Feb 2000, Lars Hecking wrote:
>
> > + netbsd* )
> > + CFLAGS_RDYNAMIC="-Wl,--export-dynamic"
> ^^ two
>
> > * )
> > CFLAGS_RDYNAMIC="-Wl,-export-dynamic"
> ^ one
>
> I guess one of them is wrong...

I guess not.

NetBSD
http://www.flame.org/cgi-bin/uncgi/hman?page=ld&sect=1&arch=i386

FreeBSD
http://www.FreeBSD.org/cgi/man.cgi?query=ld&apropos=0&sektion=1&manpath=FreeBSD+4.0-current&format=html

The latter describes GNU ld, which is also standard on Linux systems.

The Solaris case could probably be left empty, as -dy is the default
(but the Solaris man page says nothing about how this affects exporting
of symbols).