Mailing List Archive: Where did Trust_ go? [Re: undefined symbol: __register_frame

Where did Trust_ go? [Re: undefined symbol: __register_frame_info]

Apr 6, 1999, 4:28 AM

Post #1 of 10 (435 views)

> > I recently upgraded from GnuPG 0.9.3-1 to 0.9.4-1, upgrading also the
> > packages gpg-idea_1.deb and gpg-rsa_1.deb to gpg-idea_2.deb and gpg-rsa_2.deb
> > from the debian distribution. Everything seemed to be working fine with
> > 0.9.3, but now, if I try to sign a mail I get the following message:
> >
> > gpg: Warning: using insecure memory!
> > gpg: /usr/lib/gnupg/idea: error loading extension: /usr/lib/gnupg/idea:
> > undefined symbol: __register_frame_info
> > gpg: /usr/lib/gnupg/rsa: error loading extension: /usr/lib/gnupg/rsa:
> > undefined symbol: __register_frame_info
>
> The two packages where probably compiled with different debian
> versions of egcs or gcc. Try downloading the debian sources for both
> idea, rsa and gnupg and recompile everything with the same compiler
> (either gcc 2.7.2.3 or egcs). You might also want to send a bug report
> to debian.

I kept GnuPG 0.9.4-1 and downgraded the idea and rsa modules to
gpg-idea|rsa1, and that worked fine. The right solution though, as someone
pointed out, is to upgrade libc6.

Now, the problem (no real problem) is that I just upgraded my MUA:
mutt-i 0.93 --> mutt 0.95 and I just realized that when verifying the
signature, the "Trust_" part of it is missing:

gpg: Warning: using insecure memory!
gpg: Signature made mié 24 mar 1999 19:26:53 CET CET using DSA key ID
3A48C934
gpg: Good signature from "Andr\xe9s Seco Hern\xe1ndez <AndresSH@ctv.es>"
gpg: key DDDC215A: secret key without public key - skipped
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.

also, the fourth line, with regard to key DDDC215A, belongs to a key for
which I actually DO have both the secret and public.

GnuPG *can* see the secret key:

homega:~$ gpg --list-secret-keys Horacio
/home/homega/.pgp/secring.skr
-----------------------------
sec 2048D/DDDC215A 1998-07-20 Horacio Menezo <homega@correo.com>
ssb 8192g/06E9D714 1998-07-20

but it *cannot* see the public key (although it's in ~/.pgp/pubring.pkr):

homega:~$ pgpk -l Horacio
Type Bits KeyID Created Expires Algorithm Use
sec 2048 0xDDDC215A 1998-07-20 ---------- DSS Sign & Encrypt
sub 8192 0x06E9D714 1998-07-20 ---------- Diffie-Hellman
uid Horacio Menezo <homega@correo.com>

if I try to import that key into ~/.gnupg/pubring.gpg, I get:

homega:~$ gpg --import miclave
gpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: Warning: using insecure memory!
gpg:miclave: key DDDC215A: invalid self-signature
gpg:miclave: key DDDC215A: invalid subkey binding
gpg:miclave: key DDDC215A: no valid user ids
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

but it DOES have a self-signature!

Sorry for the long output, and thank you in advance,

Horacio.

Re: Where did Trust_ go? [ In reply to ]

wk at isil

Apr 6, 1999, 10:18 AM

Post #2 of 10 (419 views)

Permalink

Horacio <homega@vlc.servicom.es> writes:

> sec 2048 0xDDDC215A 1998-07-20 ---------- DSS Sign & Encrypt
^^^^ ^^^
2048 bit DSA key - strange. DSA is only defined for 512 to 1024 bit.

Who created this key?

> sub 8192 0x06E9D714 1998-07-20 ---------- Diffie-Hellman
^^^^
IMHO this far away from any reality.

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Re: Where did Trust_ go? [ In reply to ]

homega at vlc

Apr 6, 1999, 1:30 PM

Post #3 of 10 (422 views)

Permalink

Werner Koch dixit:
> Horacio <homega@vlc.servicom.es> writes:
>
> > sec 2048 0xDDDC215A 1998-07-20 ---------- DSS Sign & Encrypt
> ^^^^ ^^^
> 2048 bit DSA key - strange. DSA is only defined for 512 to 1024 bit.
>
> Who created this key?
>
> > sub 8192 0x06E9D714 1998-07-20 ---------- Diffie-Hellman
> ^^^^
> IMHO this far away from any reality.

Do you mean it's worthless? Well, I saw a few like this around ... it was
created with some C-KT package (not sure ... I think it's a hack of PGP);
they claimed much larger keys could be generated (I once tried, but it took
far too long). There was also another program ... pgp2.6a or so, which had
similar claims. I recall the person's name is Peter Wilson ...

I thought the reason behind not creating longer keys was that they not only
take long in being generated, but they too take long on
encryption/decryption processes. But they could be generated.

Regards

Horacio

Re: Where did Trust_ go? [ In reply to ]

ravenz at gmx

Apr 7, 1999, 1:36 PM

Post #4 of 10 (421 views)

Permalink

At 22:30 06.04.1999 +0200, you wrote:
>Werner Koch dixit:
>> Horacio <homega@vlc.servicom.es> writes:
>>
>> > sec 2048 0xDDDC215A 1998-07-20 ---------- DSS Sign & Encrypt
>> ^^^^ ^^^
>> 2048 bit DSA key - strange. DSA is only defined for 512 to 1024 bit.
>>
>> Who created this key?
>>
>> > sub 8192 0x06E9D714 1998-07-20 ---------- Diffie-Hellman
>> ^^^^
>> IMHO this far away from any reality.
>
>Do you mean it's worthless? Well, I saw a few like this around ... it was
>created with some C-KT package (not sure ... I think it's a hack of PGP);

Get it at http://members.tripod.com/IRFaiad/

>they claimed much larger keys could be generated (I once tried, but it took
>far too long). There was also another program ... pgp2.6a or so, which had
>similar claims. I recall the person's name is Peter Wilson ...
>
>I thought the reason behind not creating longer keys was that they not only
>take long in being generated, but they too take long on
>encryption/decryption processes. But they could be generated.

I always thought longer keys provide better security since the keys are harder
to crack. But the readme of "PGP 6.0.2ckt" contains a letter from Phil
Zimmermann that confuses me. See for yourself:

There is no advantage for using the keys larger than about 3000 bits.
The 128-bit session keys have the same work factor to break as a 3000
bit RSA or DH key. Therefore, the larger keys contribute nothing to
security, and, in my opinion, spread superstition and ignorance about
cryptography. They also slow everything down and burden the key servers
and everyone's keyrings, as well as cause interoperability problems
with present and future releases of PGP. Perhaps even more importantly,
they also undermine other people's faith in their own keys that are of
appropriate size. While it may have been well-intentioned, this massive
expansion of key size is a disservice to the PGP community.

Also, larger DSA keys don't contribute anything unless the hash grows
bigger with it. That requires selecting a good well-designed bigger hash
that has been specifically designed to have the full work factor for
breaking it. Using two SHA1 hashes in that manner has not been adequately
shown to achieve this result.

Anyone with a sophisticated understanding of cryptography would not make
the keys bigger this way.

Experimental code that we put into PGP during its development should not be
used. It was protected with conditional compilation flags and should never
have been revealed to uninformed users who decide to perform a "public
service" by enabling the code and releasing it. This is part of the reason
why we ask people not to release code changes on their own, but to send them
to us, so that we may incorporate some of them (if they seem like good ideas)
into our next product release. That is how PGP enhancements from the user
community have always been managed since PGP source code was released in
1991.

-Philip Zimmermann

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0b16

iQA/AwUBNcIZ0GPLaR3669X8EQIblACePP3jorZ6Y+wjYDRomxMfKgLF2h4AoNmI
tjDuzHfhdIqDd6s5BUNIlhBu
=3BJC
-----END PGP SIGNATURE-----

Dennis Voss

Re: Where did Trust_ go? [ In reply to ]

mskala at ansuz

Apr 7, 1999, 4:56 PM

Post #5 of 10 (420 views)

Permalink

On Wed, 7 Apr 1999, RavenZ wrote:
[quoting Phil Zimmermann]
> Anyone with a sophisticated understanding of cryptography would not make
> the keys bigger this way.

I think the above was an irresponsible statement for Phil to make; if long
keys are bad, there should be definite engineering reasons not to use
them - not just fear of appearing "unsophisticated". "Any sophisticated
cryptographer would agree with me" is the kind of non-argument we hear in
sci.crypt flame wars; I'm saddened to hear Phil stooping to that level.
Fortunately, in the part of the letter that I omitted, he did give some
genuine support for his position.

Personally, I don't think 2048 bits is excessive, although it's probably
unnecessary. I do think 3072 bits is excessive. I think 8192 bits is
just stupid.

Matthew Skala Ansuz BBS (250) 472-3169 http://www.islandnet.com/~mskala/

GOD HATES SPAM

Re: Where did Trust_ go? [ In reply to ]

wk at isil

Apr 7, 1999, 9:37 PM

Post #6 of 10 (423 views)

Permalink

RavenZ <ravenz@gmx.net> writes:

> to crack. But the readme of "PGP 6.0.2ckt" contains a letter from Phil
> Zimmermann that confuses me. See for yourself:
>
> There is no advantage for using the keys larger than about 3000 bits.
> The 128-bit session keys have the same work factor to break as a 3000
> bit RSA or DH key. Therefore, the larger keys contribute nothing to

Well, I think these 3000 bits are an assumption which are quite high
considering the current algorithms available to solve a dicrete
logarithm - but yes, after whitespread use uf RSA there was a big
progress factoring algorithms.

The encryption key depends on the signature key (unless you always
check the fingerprint of the encryption subkey) and therefor DSA is
the weakest link. The subkeys are easy to replace and if you have
really high needs to keep something secure for al long time you won't
use publiuc key cryptography anyway but use two conventional
algorithms in turn (so if one gets broken, the other counts as your
safety web)

> cryptography. They also slow everything down and burden the key servers
> and everyone's keyrings, as well as cause interoperability problems

Right. Not everyone has a 786-900Mhz - there are even many 386 out in
countries where cryptography may even be needed to protect lives.

> with present and future releases of PGP. Perhaps even more importantly,
> they also undermine other people's faith in their own keys that are of
> appropriate size. While it may have been well-intentioned, this massive

I think this is a very good argument.

> Also, larger DSA keys don't contribute anything unless the hash grows
> bigger with it. That requires selecting a good well-designed bigger hash

Rumors are that we will have a larger hash algorithm in some time and
then we can extend DSA. Note, that there was a debate on coderpunks,
what is the length of an DSA/ElGamal key and some folks argued that
DSA is a 160 bit algorithm and not a 1024 (or whatever) and that the
larger numbers are just used for marketing reasons :-)

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Re: Where did Trust_ go? [ In reply to ]

tony at moon

Apr 7, 1999, 9:39 PM

Post #7 of 10 (421 views)

Permalink

Peole often get confused about this "longer keys are better, but not if
they're too long"-argument. The fact is that longer keys are harder to
crack but at the same time a shorter uncrackable key is just as secure as a
longer one.

If you are using software that "only" handles 1024 bit RSA then you might
feel as if it isn't safe simply because you see people using 2048 bit keys
(or even 4096 bit long keys) but your key would be much stronger than what
anyone can crack today. It is true that it might be possible to crack such
keys in 10 years or, let's become paranoid for a sec, in as few years as 5;
but you have to ask yourself if the data that you're trying to hide is so
sensitive that people will hand on to your encrypted messages just to crack
them when and if they ever can.
When I say that it might be possible to crack such keys in 10 years then I
don't mean that any kid with the lastest PPC/Pentium will be able to do
it, it'd take very expensive hardware specially designed for such tasks.

AND... if you really were to get paranoid then you might think that the
"problem" on which most cryptography is based might not be a problem for
secret agencyies and such, or that that knowledge will be publicly
available not too far into the future.

I know that I for one would feel very safe using a 1024 bit key.

/Tony L. Svanstrom.com

Re: Where did Trust_ go? [ In reply to ]

homega at vlc

Apr 8, 1999, 10:32 AM

Post #8 of 10 (419 views)

Permalink

Tony L. Svanstrom dixit:

> Peole often get confused about this "longer keys are better, but not if
> they're too long"-argument. The fact is that longer keys are harder to
> crack but at the same time a shorter uncrackable key is just as secure as a
> longer one.

You mean longer keys should as hard to crack as shorter ones (down to 512
bits), JUST that they should take a bit longer, right?

> If you are using software that "only" handles 1024 bit RSA then you might
> feel as if it isn't safe simply because you see people using 2048 bit keys
> (or even 4096 bit long keys)

Correct, the feeling is as if you were using "outdated" cryptography.

> AND... if you really were to get paranoid then you might think that the
> "problem" on which most cryptography is based might not be a problem for
> secret agencyies and such,

Exactly! but there's no need to get too paranoid to jump to that
conclusion. One thing is believing that some governments/agencies (may) know
how to crack the code, a different thing is thinking that they might be
interested in your private/business communications and waste the resources
needed to break it.

Why I generated those keys was simply because ... it was there, so let's
have it. I never use them since it takes far too long to sign (or encrypt)
with them. But W. Koch's answer made me curious about it, both because he
said 2048bit DSA key was a strange thing, and b'c his opinion of a 8192bit
DH key being far from reality. I just have to take his word for it, but I
liked to know why.

Regards

Horacio

Re: Where did Trust_ go? [ In reply to ]

tony at svanstrom

Apr 8, 1999, 11:45 AM

Post #9 of 10 (420 views)

Permalink

On Thu, 8 Apr 1999 homega@vlc.servicom.es wrote:

> Tony L. Svanstrom dixit:
>
> > Peole often get confused about this "longer keys are better, but not if
> > they're too long"-argument. The fact is that longer keys are harder to
> > crack but at the same time a shorter uncrackable key is just as secure as a
> > longer one.
>
> You mean longer keys should as hard to crack as shorter ones (down to 512
> bits), JUST that they should take a bit longer, right?

Eh... hmmm... *tries to think* *tries even harder to understand*
I'm not really sure what you're trying to say, but this is how you should
look upon it:
If you want to blow up something then you won't use 20 pounds of C4 if half
a pound of dynamite will do the job.

> > If you are using software that "only" handles 1024 bit RSA then you might
> > feel as if it isn't safe simply because you see people using 2048 bit keys
> > (or even 4096 bit long keys)
>
> Correct, the feeling is as if you were using "outdated" cryptography.
>
> > AND... if you really were to get paranoid then you might think that the
> > "problem" on which most cryptography is based might not be a problem for
> > secret agencyies and such,
>
> Exactly! but there's no need to get too paranoid to jump to that
> conclusion. One thing is believing that some governments/agencies (may) know
> how to crack the code, a different thing is thinking that they might be
> interested in your private/business communications and waste the resources
> needed to break it.
>
> Why I generated those keys was simply because ... it was there, so let's
> have it. I never use them since it takes far too long to sign (or encrypt)
> with them. But W. Koch's answer made me curious about it, both because he
> said 2048bit DSA key was a strange thing, and b'c his opinion of a 8192bit
> DH key being far from reality. I just have to take his word for it, but I
> liked to know why.

Using RSA-keys that are too long to be compatible with PGP as we get it
from NetAss. (I don't really have a nything against 'em, I just happen to
like that abbreviation *G*) may not be the smartest thing to do but
RSA-keys can be that long; DSS/DSA on the other hand can not be longer than
1024 without not being DSA/DSS as the standard says.

/Tony L. Svanstrom.com

Re: Where did Trust_ go? [ In reply to ]

blaaf at hempseed

Apr 8, 1999, 4:39 PM

Post #10 of 10 (426 views)

Permalink

homega@vlc.servicom.es wrote:
>
> Tony L. Svanstrom dixit:
>
> > Peole often get confused about this "longer keys are better, but not if
> > they're too long"-argument. The fact is that longer keys are harder to
> > crack but at the same time a shorter uncrackable key is just as secure as a
> > longer one.
>
> You mean longer keys should as hard to crack as shorter ones (down to 512
> bits), JUST that they should take a bit longer, right?

No. He means that if you want a weight too heavy to be carried off, you
can make it 500 pounds, 500,000 pounds, or 500,000,000,000 pounds (or
kilograms if you like). A 1,024 bit DH key is about 500,000 pounds. A
8,192 bit DH key is about 5 zillion. Who are you trying to protect
against? 500,000,000,000 pounds is theoretically a million times "harder"
to lift than 500,000 pounds, but just as secure if nobody comes close to
even lifting 500 pounds.

> Why I generated those keys was simply because ... it was there, so let's
> have it. I never use them since it takes far too long to sign (or encrypt)
> with them. But W. Koch's answer made me curious about it, both because he
> said 2048bit DSA key was a strange thing, and b'c his opinion of a 8192bit
> DH key being far from reality. I just have to take his word for it, but I
> liked to know why.

Hopefully you know why now. Basically, unless the entire concept of DH/DSA
is subtly flawed, 1024 bits is so far out of range of the best available
techniques for discrete log (or prime factoring with RSA), that it is
inconceivable that conventional computing and mathematics will ever be able
to solve such problems in less than astronomical time (or even in
astronomical time). Bloated keys just weigh down servers, rings, and
encryption time.

Nate