Cryptography-Digest Digest #528, Volume #12 Thu, 24 Aug 00 18:13:00 EDT
Contents:
Re: Serious PGP v5 & v6 bug! ([EMAIL PROTECTED])
understanding RC4 ([EMAIL PROTECTED])
Re: Excerpt of SECRETS AND LIES available on-line (John Myre)
Re: Reply now to join the crypto-research-ressources group (David A Molnar)
Asymmetric Encryption Algorithms ("Paul Montgomery")
Re: Serious PGP v5 & v6 bug! ("JT")
Re: Excerpt of SECRETS AND LIES available on-line (JPeschel)
Re: SHA-1 program (cool!) (S. T. L.)
Re: blowfish problem ("Trevor L. Jackson, III")
Re: blowfish problem ("Trevor L. Jackson, III")
Re: blowfish problem (Richard Heathfield)
Re: blowfish problem ("Douglas A. Gwyn")
Re: blowfish problem (Richard Heathfield)
Re: Bytes, octets, chars, and characters (Paul Schlyter)
Re: Bytes, octets, chars, and characters (Paul Schlyter)
Re: Provably secure stream cipher (Tim Tyler)
Re: Serious PGP v5 & v6 bug! (David Kaczynski)
Re: Serious PGP v5 & v6 bug! (Shellac)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 19:04:12 GMT
>
> The problem won't go away until all vulnerable versions of PGP are
> retired, since it's the sender who is responsible for encrypting to
> the ADKs, not the recipient.
have read Ralf's paper, please correct me if i mis-understand the
following conclusion in the paper:
"Since DH-keys all have Version-4-self-signatures, you should avoid to
use those for encryption. But detecting V4-RSA-keys is sometimes
difficult. Using PGP553i for Windows V4-RSA-keys do present themselves
as V3-RSA-keys with key-IDs and fingerprints computed in Version-3-
style. Upgrading to PGP651i for Windows shows the same key with a new
V4-style key-ID and with a different new fingerprint but truncated to
the first 16 bytes, so that it looks like a V3-style fingerprint, which
it clearly is not. So if you see 16 byte fingerprints you cannot be
sure that the key does not have a Version-4-self-signature. To be sure
you have to go into byte analysis of the key packets. Using GnuPG make
things worse because all V4-signatures I have created on RSA-keys were
made using this program.
So if you want to get rid of ADKs as much as possible, you are well
advised to use PGP-Classic, PGP-2.6.x, the only PGP which guarantees
that only Version-3-signatures are made and which rejects DH-keys and
RSA-keys in Version-4-format.
You should use GnuPG as an analysis-tool to check which packets a key
or cryptogram consists of. And you can use newer PGP-versions or GnuPG
to check the validity of signatures on messages which have been made
with V4-keys by others." {end of quoted selection }
can a workaround be to use pgp 2.6.x to generate version 3 RSA keys,
and then use only those keys, but can still continue using any version
of pgp,
or did i really miss something?
vedaal
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: understanding RC4
Date: Thu, 24 Aug 2000 19:01:18 GMT
================================================
Newbie alert. At the risk of sounding silly - I pose the following
question. (I am new to cryptology).
I know the following:
1. Plaintext = "secret"
2. Encrypted string = "06E0A50B579AD2CD5FFDC48565627EE7"
3. RC4 algorithm was used (possibly modified somehow)
4. No salting was used in RC4
Given this information, is it possible to write an RC4 encryption
routine that does helps me encrypt other plaintexts in the _same_
manner?
Does no-salt-used mean that the encryption key does not depend on the
plaintext?
How can a 6 character word ("secret") lead to a 32 character hash
(""06E0A50B579AD2CD5FFDC48565627EE7") - I thought a stream cipher's
output was to same length as the input?
Any help/insights/source code snippets/websites would be most
appreciated.
- Grank.
===========================================================
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Excerpt of SECRETS AND LIES available on-line
Date: Thu, 24 Aug 2000 13:48:34 -0600
Bruce Schneier wrote:
>
> A couple of weeks ago, someone asked about on-line distribution of my
> latest book. I just noticed that Chapter 3 is up on Amazon:
<snip>
> Not the chapter I would have picked to excerpt, but no one asked me.
<snip>
I notice that at the bottom is the phrase "used by permission". What
permission did they get, from whom? Is the author involved at all?
JM
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Reply now to join the crypto-research-ressources group
Date: 24 Aug 2000 19:55:39 GMT
[EMAIL PROTECTED] wrote:
> A new cryptography e-mail list in which you may be interested has been
> created. Please feel welcomed to join!
Hi,
Could you provide more information on why I may be interested?
Do you have a specific charter?
and why is it spelled "ressources" ?
thanks,
-David
------------------------------
From: "Paul Montgomery" <[EMAIL PROTECTED]>
Subject: Asymmetric Encryption Algorithms
Date: Thu, 24 Aug 2000 16:02:04 -0400
I'm working on some cryptography projects for "fun" and I have run into
an interesting question:
Which Asymmetric encryption algorithm is considered to be most secure (I
know that is an very subjective term)? I did some research on
Diffie-Hellman, DSA and Elgamal (not going to touch RSA til Sept. 21st) and
it appears to me that Elgamal is superior at first appearance. I liked DSA
except for the 1024 bit key limitation but DH and Elgamal seemed to support
up to 4096 by default. DH seems to have a few more weaknesses documented
that kind of scared me away from that option.
Also, does anyone know of any good places to search for (preferably
public domain) Elgamal code in C or C++?
Thanks in advance,
Paul Montgomery
------------------------------
From: "JT" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: 24 Aug 2000 20:04:13 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Michel Bouissou" <[EMAIL PROTECTED]> wrote in message
news:8o3jrh$kjj$[EMAIL PROTECTED]...
>
> The problems are that:
>
> - For (1) and (2) I'm not quite sure that these options are the
> default in PGP preferences. I mean, I'm almost sure they're not, at
> least for the ADK column display. It would need reinstalling PGP to
> make sure ;-)
I'll save you the trouble. I'm quite confident I didn't change the
defaults when I installed a week or so ago because I didn't know what
ADK was until now.
The ADK column does not show up by default in your list of keys. The
box marked "Warn when encrypting to keys with an ADK" WAS marked by
default. This is version 6.5.3 freeware.
JT
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOaV/u8Z6MGGi0X1nEQLs9ACeNXuGGXLUhc6PkOTKdoiUhy32riUAn3zo
nNG80/R1pwFp0pvg+YHBcrTX
=GR/J
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Excerpt of SECRETS AND LIES available on-line
Date: 24 Aug 2000 20:13:50 GMT
John Myre [EMAIL PROTECTED] writes:
>Bruce Schneier wrote:
>>
>> A couple of weeks ago, someone asked about on-line distribution of my
>> latest book. I just noticed that Chapter 3 is up on Amazon:
><snip>
>> Not the chapter I would have picked to excerpt, but no one asked me.
><snip>
>
>I notice that at the bottom is the phrase "used by permission". What
>permission did they get, from whom? Is the author involved at all?
Looks like they got permission from the publisher to excerpt a part
of the book. The publisher usually gives the writer a heads-up on
this sort of thing, but not always. Whether the writer is consulted,
or additionally compensated, depends on which rights the publisher
purchased.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 24 Aug 2000 20:19:41 GMT
Subject: Re: SHA-1 program (cool!)
<<Use unsigned long long instead of unsigned long int, unsigned long int
are about 32 bits while unsingned long long are about 64 bits (as
"required" by fips 180-1).>>
I'm certain that unsigned long long is *not* C89 standard. It might be C99
standard, but I know nothing about C99 yet. I don't know if DJGPP supports
long longs.
<<If you do not want to use unsigned long long, you can look into the code
of MD5 in RFC1321, Rivest does arithmetics on two unsigned long int to
mimics a 64 bit integer.>>
Yes, this is the crufty solution that I may end up adopting if DJGPP can't do
long longs. (I'd sacrifice portability for ease of coding.) Since all that I
do, basically, is addition and right-shifting, it shouldn't be too hard to
cruft up something.
<<Diablo II might :)>>
Crufty game. Deus Ex kicks Diablo II any day of the week. :-P
<<12 1's followed by 7 0's then by 11 1' ...>>
Yeah, I looked at that too. Since my problems appear to come from really long
files, those vectors aren't useful to me. I'd like it if someone could
independently hash a file of 1,000,000,000 "a" characters, using a program
that's not SHA1.EXE, SHA1.COM, or HASHcipher.
<<DJGPP supports unsigned long long>>
Oooh, good. Cool. I'll probably be using that now.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
Date: Thu, 24 Aug 2000 16:28:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
It is all perfectly clear now. It's a terminology issue. The terms char, byte,
and character are synonyms, but we'll refrain from stipulating that fact in the
interest of ... pedantry?
If the referents are identical, why are there multiple terms that are not defined
to be synonymous?
If the referents are not identical, what are their distinguishing characteristics?
Kaz Kylheku wrote:
> On Wed, 23 Aug 2000 21:55:43 -0700, Spud <[EMAIL PROTECTED]> wrote:
> >"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Kelsey Bjarnason wrote:
> >> > Nope; neither of those do it. #2 refers to the size "in bytes";
> >> > if a "byte" on the implementation is 16 bits, but a char 8, the
> >> > implementation is still free to refer to both as having size 1.
> >>
> >> No, because a char has no padding bits.
> >
> >So? A char doesn't _have_ to have padding bits for this to hold true.
> >
> >Byte: 16 bits
> >char: 8 bits, no padding
> >sizeof(char): 1
>
> Sheer nonsense.
>
> A byte is the smallest unit of storage in C. Every object has a storage
> representation that is a multiple of the byte. (Other than bitfields,
> which are regions within objects).
>
> The representation of a character type occupies a full byte of storage.
>
> In this case, since a byte is 16 bits wide, a character type occupies 16 bits.
> Moreover, since there are no padding bits, then each of these 16 bits is a
> value bit. A value bit is one that contributes to the value of the type. The
> width of a type is the number of value bits that it has; thus char must be 16
> bits wide. The only way a char could be narrower than 16 would be if it had
> padding bits, but that is prohibited.
>
> >> Whatever a "byte" is,
> >> the fact that a char has size precisely 1 byte means that every
> >> bit of the byte is used in the representation for type char.
> >
> >No, it means that every bit of the _char_ is used; unless and until it is
> >shown that a byte _cannot_ be bigger, physically, than a char.
>
> Here is a word of advice: if you reply to Doug Gwyn with a ``No,'' chances are
> you are setting youself up to be burned, unless your name is something like
> Clive Feather or Paul Eggert. :)
>
> As long as
> >sizeof(char) still evaluates to 1, and as long as the _char_ has no unused
> >bits, all of what you say above still holds true - despite the _byte_ having
> >more bits than the char.
>
> Except that the sizeof operator counts how many bytes an object occupies.
> A size of 1 means one byte. One full byte, not half a byte, or a quarter
> of a byte. Objects cannot have fractional sizes in C; they are regions of
> bytes.
>
> >> Keep in mind that I'm not guessing -- if there is ever any
> >> reason to request an official interpretation on this point,
> >
> >Well, here's a reason: it's not specified by the document, and as I've
> >pointed out in a couple of different places, unless it is specified, some
> >*very* nasty things can potentially occur. See the issue of reading files
> >written by a Pascal program which _does_ use 16 bit chars, then being read
> >by a C program which uses 16 bit bytes but 8 bit chars. I still see nothing
> >to indicate that this isn't perfectly legal.
>
> Gradeschool math tells you that it's not legal.
>
> Consider V to be the number of value bits and P to be the number of padding
> bits. The following holds true for the char type in this example
> implementation:
>
> V + P = 16
> P = 0
>
> Now solve for V.
>
> --
> Any hyperlinks appearing in this article were inserted by the unscrupulous
> operators of a Usenet-to-web gateway, without obtaining the proper permission
> of the author, who does not endorse any of the linked-to products or services.
------------------------------
Date: Thu, 24 Aug 2000 16:42:35 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
"Douglas A. Gwyn" wrote:
> Spud wrote:
> > > The type unsigned char has no padding bits.
> > Right. The byte, however, does.
>
> No, because the (single) byte *is* the representation
> of the unsigned char object. The bits of any
> representation are either padding bits or significant
> (value) bits, and the standard says that padding bits
> are not allowed for this type. Therefore all bits of
> the byte participate in determining the value for that
> type. Since every object is represented by an array of
> bytes, that means that all bits of *any* object are
> accessible via aliasing to array of unsigned char.
> A conforming implementation cannot pick the widths
> for "byte" and "char" independently of each other.
By this reasoning the draft would mean the same thing if it were transformed
by replacing all use of the term byte with the term unsigned char. Thus
either the draft is fatuously flawed, or there is distinction between "C byte"
and "C unsigned char" that cannot be deduced from their (joint) referent.
------------------------------
Date: Thu, 24 Aug 2000 22:15:47 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Spud wrote:
>
> "Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Not quite true. We've had a member of the ANSI C committee saying that
> > the intent of the Standard is to say that char and byte are necessarily
> > the same size. Now, please produce either a quote from the Standard
> > which makes it clear that he is wrong,
>
> You know, there is a difference between "It's not clear he's wrong, so he
> must be right" and "See, it says he's right, right there on page three."
Agreed. Nevertheless, consider the practicality of the situation. You
have a Usenet discussion with a member of the ANSI C committee, who
gives an interpretation of the Standard with which you disagree. What is
the correct course of action, if you cannot reach agreement with him?
Well, the obvious thing to do if you're stuck on an interpretation of
the Standard is to ask ANSI to clarify it for you. So (and from now on,
we're getting hypothetical) you send off an email to ANSI, asking for
clarification. Well, it's not deeply unlikely that the person who ends
up sending you an answer is the very person you were arguing with. I
wonder what he'd say? :-)
Had Doug Gwyn /not/ been a member of the ANSI committee, /or/ if you
/were/ a member, I'd understand your objection.
However, IMHO, what you've achieved is useful - you've managed to get a
clarification of a point which had mildly worried some of us (me, for
instance).
> It
> was the latter I was looking for. Chris Torek resolved the issue, by
> pointint out something I'd totally managed to overlook - the very point I'd
> repeatedly asked for, namely, where in the standard it actually _says_ he's
> right. It's 5.2.4.2.1, and I'll be stonkered if I can explain how I missed
> it. (I will, however, note in my own defense that it took a good three days
> for anyone else to come up with it. :) )
Yes, I think it was a most useful discussion. And relatively polite,
too. Are comp.lang.c's standards slipping? ;-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 20:15:59 GMT
Spud wrote:
> > 5.2.4.2.1 Sizes of integer types <limits.h>
> Aha, ... it quite happily settles the matter.
Well, that's not really where it is determined, but since you
kept rejecting the other explanations I'm glad that one
finally convinced you.
------------------------------
Date: Thu, 24 Aug 2000 22:17:56 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
"Trevor L. Jackson, III" wrote:
>
> It is all perfectly clear now. It's a terminology issue. The terms char, byte,
> and character are synonyms,
Not quite.
> but we'll refrain from stipulating that fact in the
> interest of ... pedantry?
>
> If the referents are identical, why are there multiple terms that are not defined
> to be synonymous?
>
> If the referents are not identical, what are their distinguishing characteristics?
A byte is what you can fit a char exactly into.
A char is what you can fit exactly into a byte.
It's like the difference between the coffee and the cup (if you fill it
right up to the brim...)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 24 Aug 2000 22:07:30 +0200
In article <[EMAIL PROTECTED]>, Keith Thompson <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Schlyter) writes:
>
>> X = the width, in bits, of the data bus.
>
> I think the size of the integer register(s) is a more useful measure
> of the "bitness" of a machine. There was a posting on, I think,
> comp.arch not too long ago listing various characteristics of several
> architectures, including data bus width, register size, etc; register
> size almost universally matched what most people would call the
> "bitness" of the architecture. Note that this makes the VAX and 68k
> (all versions) 32-bit machines. (Whether this is called a "word" is
> another matter.)
Would that make e.g. the 8080 or the Z80 an 8-bit or a 16-bit CPU?
They're usually regarded as 8-bit CPU's, but several of their 8-bit
registers could be treated as pairs, i.e. one 16-bit register (DE, HL)
and they had several 16-bit opcodes.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 24 Aug 2000 22:08:06 +0200
In article <8o384u$geo$[EMAIL PROTECTED]>, Dan Pop <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]> Keith Thompson <[EMAIL PROTECTED]> writes:
>
>> To get back to the topic of the newsgroup, the size of the integer
>> registers is *usually* the most appropriate size for type int.
>
> s/is/was
>
> Nowadays, the most appropriate size for type int seems to be 32 bits.
> The only exceptions are implementations for chips designed over 20 years
> ago, but still in use.
>
>> The
>> only reasons I can think of for using a different size are (1)
>> compatibility with another, usually smaller, architecture, and (2) the
>> integer registers are smaller than 16 bits.
>
> You've missed the most sensible reason: if you were to write a compiler
> for a processor with 64-bit registers and no backward compatibility
> issues and you made int a 64-bit type, how would you map the 8-bit,
> 16-bit and 32-bit integers on the C89 standard types?
>
> If you make int a 32-bit type, the solution becomes obvious:
>
> char 8-bit
> short 16-bit
> int 32-bit
> long 64-bit
Java prescribes:
byte 8-bit
char 16-bit
short 16-bit
int 32-bit
long 64-bit
The reason for 16-bit chars are that Java always uses Unicode internally.
In C though, the most common solution seems to be:
char 8-bit
short 16-bit
int 32-bit
long 32-bit
(long long 64-bit)
On 64-bit machines, one alternative could be:
char 8-bit
short short 16-bit
short 32-bit
int 64-bit
long 128-bit
long long 256-bit
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Provably secure stream cipher
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Aug 2000 21:12:58 GMT
[EMAIL PROTECTED] wrote:
[snip]
It sounds odd - you say:
``Here is an idea for a somewhat slow provably secure (as long as the
underlying prng is statistically random, but need not wholely random).''
Then:
``f(x) = ax + b [...] in GF(2^n) (n = 8, 32, 64 ...)
The idea is that the prng will make the (a, b) values for each 'x' that
is being encrypted. Since this is pairwise decorrelated and the values
(a, b) are made anew with each output this is provably secure if the
stream (a, b) is not guessable (in this case without any known stream).''
>From this, it appears that you need the underlying PRNG to be
cryptographically secure. I'm not sure if this is clearly implied
by the term "statistically random".
If you're applying the term "provably secure", you might want to consider
the question of whether the PRNG it's based on is "provably secure".
I expect a security proof based on an unproven assumption of randomness of
a PRNG would be of minor interest.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: David Kaczynski <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 14:35:54 -0700
Reply-To: Remove the dot in "HUS.HMAIL" to reply.
FWIW, it would be nice if someone could crank out a shell, perl, or
better yet, C program, that could examine your public keys for any of
these mischeviously inserted ADKs.
Beyond my ability.
------------------------------
From: Shellac <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: 24 Aug 2000 23:04:28 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[EMAIL PROTECTED] writes:
> >
> > The problem won't go away until all vulnerable versions of PGP are
> > retired, since it's the sender who is responsible for encrypting to
> > the ADKs, not the recipient.
>
> have read Ralf's paper, please correct me if i mis-understand the
> following conclusion in the paper:
>
> "Since DH-keys all have Version-4-self-signatures, you should avoid to
> use those for encryption. But detecting V4-RSA-keys is sometimes
> difficult. Using PGP553i for Windows V4-RSA-keys do present themselves
> as V3-RSA-keys with key-IDs and fingerprints computed in Version-3-
> style. Upgrading to PGP651i for Windows shows the same key with a new
> V4-style key-ID and with a different new fingerprint but truncated to
> the first 16 bytes, so that it looks like a V3-style fingerprint, which
> it clearly is not. So if you see 16 byte fingerprints you cannot be
> sure that the key does not have a Version-4-self-signature. To be sure
> you have to go into byte analysis of the key packets. Using GnuPG make
> things worse because all V4-signatures I have created on RSA-keys were
> made using this program.
>
> So if you want to get rid of ADKs as much as possible, you are well
> advised to use PGP-Classic, PGP-2.6.x, the only PGP which guarantees
> that only Version-3-signatures are made and which rejects DH-keys and
> RSA-keys in Version-4-format.
>
> You should use GnuPG as an analysis-tool to check which packets a key
> or cryptogram consists of. And you can use newer PGP-versions or GnuPG
> to check the validity of signatures on messages which have been made
> with V4-keys by others." {end of quoted selection }
>
> can a workaround be to use pgp 2.6.x to generate version 3 RSA keys,
> and then use only those keys, but can still continue using any version
> of pgp,
>
> or did i really miss something?
>
> vedaal
>
My suggestion, to a friend using windows PGP v 6.5.(something)i was
simply to enable the ADK marks in PGPKeys (or whatever it is on
windows). Contact the person who owns the key if there is an ADK
indicated. I guess very few people should have ADKs on their keys (but
I may be wrong). Does that seem fair?
Detecting whether someone has a compromised key of yours seems much
harder. I guess you just have match the recipient list to the
keys. That might indicate a problem.
The suggestion in the article seemed a little over the top for most
users - quite a hassle in fact. But it is the only way if you want to
be certain of security, I guess.
I assume this problem will be fixed, and all PGP users will have to
update their applications. Bit of a mess, but that's the nature of
PGP - bugs can cause serious problems.
Shellac (using GnuPG)
- --
Key fingerprint = FC31 23CA 3EBA E30D 2F20 D7EA 8C8F BB0A 49CA 5201
I use and endorse MkLinux, MacOS, GnuPG, Xemacs, Alpha (text
processor), wwwoffle, w3m, Gnus, Leafnode, Cherry Coke, PG Tips. They
do not sponsor me. Despite endless requests.
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE5pZvpjI+7CknKUgERAnzyAJ4tuIqNEjsHqau2Ahb204BBGwH6xwCgyZnV
0IZ2by3jx0Ea91/43zHNPzw=
=8YfP
=====END PGP SIGNATURE=====
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
