Keypair created with gpg 1.0.7

Leigh S. Jones kr6x@kr6x.com
Tue May 28 22:32:02 2002


Well, because I've overcome some of the obstacles and managed to
exchange keys between gpg and PGP (both ways), you can bet that
I've got some ideas.

First, here is an options file that I use with gpg 1.0.7 that
allows the exchange:

armor
s2k-cipher-algo 3des
s2k-digest-algo sha1
compress-algo 1
openpgp
pgp6
simple-sk-checksum
escape-from-lines
allow-freeform-uid
lock-once
load-extension idea
keyserver http://wwwkeys.us.pgp.net
default-recipient-self

Frankly, the openpgp and pgp6 options override each
other plus the options that appear in front of them, and
the simple-sk-checksum is only there for the key
exchange.  I wouldn't use it if I thought that my
computer might be "visited".  There are probably other
overrides occurring.  In the US "load-extension idea"
option wouldn't be used at work.  And, it is necessary
to --edit-key [keyID] then "change" passwords and
save in order for the deprecated checksum to be used.
I also was successful with "s2k-cipher-algo aes" --
the "s2k-cipher-algo 3des" option was chosen in a
search for compatibility with Peter Guttman's CryptLib
3.1, with which I am playing.

Give these a try, then let me know if you are still
struggling.

----- Original Message -----
From: "Charly Avital" <shavital@mac.com>
To: "Leigh S. Jones" <kr6x@kr6x.com>; <gnupg-users@gnupg.org>
Sent: Tuesday, May 28, 2002 12:52 PM
Subject: Re: Keypair created with gpg 1.0.7


> Thanks for your feedback.
>
> Although I have complete control, including physical security, over
the
> computers involved, I choose not to enable simple-sk-checksum as an
option.
>
> I opted for the secure way you suggested.
> The Terminal's output was the two identical lines:
> gpg:generating the deprecated 16-bit checksum for secret key
protection
> gpg:generating the deprecated 16-bit checksum for secret key
protection
>
> I also tried the blank password method.
>
> In both cases, I immediately restored the passphrase, after
exporting the
> keyblock.
>
>
> Nevertheless, the exported key, first with the "deprecated 16-bit
checksum,
> and then with a blank passphrase, was not accepted.
>
> The same thing happened, PGP quit, Eudora quit (depending on which
method I
> tried to use to import the secret key).
>
> I have taken care to delete/wipe the secret key block in the
exporting and
> importing computers, as well as wiping free disk space.
>
> Thanks again for your input. If you have other suggestions, I shall
> appreciate them.
>
> Charly
>
>
>
> At 11:51 AM -0700 5/28/02, Leigh S. Jones wrote:
> >This question sounds like it could be about the
> >--simple-sk-checksum option.
> >
> >For improved security, gpg has a new database
> >storage format for the secret key.  Exported keys use
> >the new format, which is incompatible with older gpg
> >versions as well as with PGP.  To make your exported
> >keys PGP compatible, you need to store the keys in
> >the database with the --simple-sk-checksum option
> >enabled.  You could put the simple-sk-checksum into
> >your options file if you are working on a computer
> >that you have complete control over including physical
> >security.
> >
> >The secure way to work with this is to:
> >1) gpg --simple-sk-checksum --edit-key [keyID]
> >Command> passwd
> >Re-enter your password without changing it.
> >Command> save
> >2) Export the key.
> >3) Edit and re-enter your password again, this
> >time without the --simple-sk-checksum option.
> >This puts you back into high security mode.
> >
> >Treat the exported secret keys carefully and don't
> >allow them to be compromised.  Some people
> >prefer to change the password to a blank.  Then they
> >don't need to use the --simple-sk-checksum option.
> >I think this is a real security problem.
> [snip]