Cryptography-Digest Digest #523, Volume #12 Thu, 24 Aug 00 08:13:01 EDT
Contents:
Re: Serious PGP v5 & v6 bug! (Mok-Kong Shen)
Re: blowfish problem ("Phil Tregoning")
Re: 1-time pad is not secure... (Tim Tyler)
Re: help needed to break KRYPTOS ([EMAIL PROTECTED])
Apart from Generation...? ("Sergio Arrojo")
Re: blowfish problem (Chris Torek)
Re: On pseudo-random permutation (Tim Tyler)
Re: A few big primes? (Michael Brown)
Re: OTP using BBS generator? (Tim Tyler)
Re: understanding RC4 (Runu Knips)
Re: The future direction ... (John Savard)
Re: Serious PGP v5 & v6 bug! (Anders Thulin)
Re: blowfish problem (Richard Bos)
Re: Serious PGP v5 & v6 bug! ("JL")
Re: My unprovability madness. (Nathan the Great)
Re: Serious PGP v5 & v6 bug! ("Michel Bouissou")
Re: New algorithm for the cipher contest (Mark Wooding)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: The DeCSS ruling (Jeffrey Williams)
Re: Serious PGP v5 & v6 bug! ("JL")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 11:24:22 +0200
Sam Simpson wrote:
>
> Original from Dr R.Anderson, uk-crypto mailing list.
[snip]
This once again stresses the fact that one can't entirely
depend on stuffs from others being error-free, bug-free,
etc. etc. One has to do something oneself, if security is
really at stake.
M. K. Shen
------------------------------
From: "Phil Tregoning" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 24 Aug 2000 09:24:48 GMT
Kaz Kylheku <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
>
> The C99 draft has this text:
>
> Values stored in objects of any other object type consist
> of n×CHAR_BIT bits, where n is the size of an object of that
> type, in bytes. The value may be copied into an object of
> type unsigned char [n] (e.g., by memcpy); the resulting
> set of bytes is called the object representation of the value.
>
The standard has the same paragraph in 6.2.6.1. In paragraph
6.2.6.2 it says this about unsigned ints (here I use 2^N to mean
2 to the power N):
For unsigned integer types other than unsigned char, the bits
of the object representation shall be divided into two groups:
value bits and padding bits (there need not be any of the
latter). If there are N value bits, each bit shall represent a
different power of 2 between 1 and 2^(N-1) , so that objects of
that type shall be capable of representing values from 0 to
2^N - 1 using a pure binary representation; this shall be
known as the value representation.
So unsigned ints are capable of representing values from 0
to 2^N-1 where N is the number of value bits, and values
stored in unsigned ints consist of sizeof(unsigned) * CHAR_BIT
bits.
Surely these two paragraphs together mean that unsigned ints
can have no padding bits (or is the value stored in an unsigned
int not the same as the value it represents)?
Maybe 6.2.6.1 should be changed to:
_Representations_ of objects of any other object type consist
of n×CHAR_BIT bits...
Phil T
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Aug 2000 09:08:58 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Even if events do not have predictable casuse, there's still weird
:> faster-than-the-speed-of-light, non-local happenings going on.
: To the contrary, one has to invoke such "non-physical"
: ideas like FTL or nonlocal causation only if one
: stubbornly *insists* on underlying predictability.
I believe this goes against the facts of the matter.
EPR experiments "pretty much" rule out the idea that physics
depends only on local interactions.
Invoking random events doesn't somehow miraculously provide
one with a purely local theory again.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: help needed to break KRYPTOS
Date: Thu, 24 Aug 2000 09:21:05 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > > ...could indicate that the method of
> > > encipherment involved as its last stage finding the
> > > ciphertext character at some coordinates (determined
> > > by key and plaintext) within a normal sequence A..Z.
> > may you give me a very brief example of it ??
>
> Key -> FRIE...
> PT: CT:
> K ABCD...
> R BCDE...
> Y CDEF...
> P DEFG...
ok, i agree,
what's is important is that the table
(which represent "the last stage")
must contain the normal sequence ABC...Z.
..or the reversed sequence Z...CBA (Beaufort cipher?)
thanks a lot, Douglas
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Apart from Generation...?
Date: Thu, 24 Aug 2000 11:20:25 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
I am aware that making software capable of
generating elliptic curves in a reasonable amount of time is a difficult
stuff. But tell me, is it really so difficult to make ECDSA, encryption,
decryption and key exchange software once you have an appropiate curve?. I
mean, it seems to me that the strong mathematics are involved on generating
the curve, and that most of the implementations are really just operations
with
big numbers. Am I misssing something here?
Do you thing we could find specific software for less price that would not
include the generation of curves?
Sergio
------------------------------
From: [EMAIL PROTECTED] (Chris Torek)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 09:44:22 GMT
In article <xd3p5.29321$[EMAIL PROTECTED]>
Spud <[EMAIL PROTECTED]> writes:
>Let me put to you this challenge. Pick anything you like from the standard,
>anywhere, in any combination. Do not assume that byte and char are
>synonymous; assume that my suggested implementation is conforming. Now try
>to show me *why* it is in fact *not* conforming - without resorting to an
>assumption that they are equivalent.
>
>If you don't, a priori, assume that byte and char are synonymous, I think
>you'll have a hell of a time doing it. About the best you'll manage is
>either Doug Gwyn's comment that this was the intention, or Dann Pop's
>comment that a (strictly) conforming program should not be able to tell the
>difference anyway... but that's a little different from actually
>demonstrating that they are, in fact, equivalent.
If a tree falls in the forest and there is no one around to hear it,
does it make a "gawdawful racket"? :-)
Seriously, the thrust of your argument appears to lie in the following
wording:
3.4 Byte
[#1] The unit of data storage large enough to hold any
member of the basic character set of the execution
environment. It shall be possible to express the address of
each individual byte of an object uniquely. A byte is
composed of a contiguous sequence of bits, the number of
which is implementation-defined. The least significant bit
is called the low-order bit; the most significant bit is
called the high-order bit.
3.5 Character
[#1] A bit representation that fits in a byte. The
representation of each member of the basic character set in
both the source and execution environments shall fit in a
byte.
Now, "fits in" certainly allows one to read this as "is a bitwise
subset of". So we might begin with a hypothetical implementation
having 16-bit "byte"s and 8-bit "char"s. However...
5.2.4.2.1 Sizes of integer types <limits.h>
[#1] The values given below shall be replaced by constant
expressions suitable for use in #if preprocessing
directives. ... Their implementation-defined values shall be
equal or greater in magnitude (absolute value) to those
shown, with the same sign.
- number of bits for smallest object that is not a bit-
field (byte)
CHAR_BIT 8
So 5.2.4.2.1 (n2620 draft) says that CHAR_BIT is the "number of
bits for [a] ... byte". If a byte has *more* bits than a char --
e.g., if a byte has 16 bits and a char has 8 -- then CHAR_BIT must
be the larger number. (Our hypothetical implementation with 16-bit
"byte"s and 8-bit "char"s has to have CHAR_BIT set to 16.)
(The only way to get around this is to pretend that the word "byte"
in parentheses is not there at all.)
6.3.3.4 The sizeof operator
Constraints
[#1] The sizeof operator shall not be applied to an
expression that has function type or an incomplete type, to
the parenthesized name of such a type, or to an lvalue that
designates a bit-field object.
Semantics
[#2] The sizeof operator yields the size (in bytes) of its
operand ...
[#3] When applied to an operand that has type char, unsigned
char, or signed char, (or a qualified version thereof) the
result is 1. ...
Therefore the size of a "char" is 1 byte.
6.1.2.8 Representations of types
[#1] The representations of all types are unspecified except
as stated in this subclause.
6.1.2.8.1 General
[#1] Values of type unsigned char shall be represented using
a pure binary notation.[footnote36]
[#2] When stored in objects of any other object type, values
of that type consist of n*CHAR_BIT bits, where n is the size
of an object of that type, in bytes. ...
Thus, CHAR_BIT is the number of bits in a byte, because values of
type "char" consist of 1*CHAR_BIT bits. But what if some of these
are "padding bits"?
6.1.2.8.2 Integer types
[#1] For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided into
two groups: value bits and padding bits (there need not be
any of the latter). If there are N value bits, each bit
shall represent a different power of 2 between 1 and 2N - 1,
so that objects of that type shall be capable of
representing values from 0 to 2N - 1 using a pure binary
representation; this shall be known as the value
representation. The values of any padding bits are
unspecified.[footnote39]
For unsigned char, there are no padding bits; all the bits are
value bits, so there are 1*CHAR_BIT bits in an "unsigned char".
All 1*CHAR_BIT bits must be used. (Our hypothetical implementation,
with 8-bit "char"s, has to have a UCHAR_MAX of 65535. We have a
problem.)
Your argument boils down to "a byte could have more bits than a
char", but 6.1.2.8.2 contradicts this. If a byte has exactly as
many bits as a char, and a char has exactly as many bits as a byte,
and all bits in an (unsigned) char contribute to the value, then
the two must be exactly equivalent. Any bits that are not visible
are *never* visible, so any "extra" bits in a byte have as much
substance as the extra tea in each byte.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA, USA Domain: [EMAIL PROTECTED] +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
------------------------------
Crossposted-To: comp.programming
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: On pseudo-random permutation
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Aug 2000 09:27:30 GMT
In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Mok-Kong Shen wrote:
:> Tim Tyler wrote:
:> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> > : Tim Tyler schrieb:
:> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> > :> I observe that you omit any form of detection of collisions between
:> > :> the first components of B. Without such a check the result does
:> > :> not form a truly unbiased random permutation [...]
:> >
:> > : That collision is to be resolved by the sorting process.
:> > : One has to decide on a resolution rule, though.
:> >
:> > No resolution in the sort routine can possibly produce an unbiased
:> > sequence.
:> >
:> > You can see this by a counting arument, after observing that n! doesn't
:> > usually divide exactly into 2^(n * x) very well [x is the width of the
:> > RNG output in bits].
:>
:> I am not yet convinced. You have to consider from a probabilistic
:> point of view, i.e. consider a large number of occurences
:> and the average effects [...]
: If the collision resolution is chosen such that the first
: element of the pair is always considered less than the
: second, then indeed there is a bias. The effect is [usually small].
: One can on the other hand use a random choice rule to resolve
: collision, in which case no bias can occur.
Yes. It was not correct for me to have written: "No resolution
in the sort routine can possibly produce an unbiased sequence."
As you say, use of a rule based on bits from the random stream
would be likely to provide a possible way of removing the bias.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Michael Brown <[EMAIL PROTECTED]>
Subject: Re: A few big primes?
Date: Thu, 24 Aug 2000 21:51:01 +1200
> Primes under 512 bits can be generated by a TI-92+ calculator, actually.
Cool. How do I do it?
New TI-92+ user :)
Michael
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Aug 2000 09:40:29 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
: Oh, do you have a pointer to Alexi-Chor-Goldreich-Schnorr?
FWIW: two /possible/ papers at:
http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/s/Schnorr:Claus=Peter.html
Alexi, W.; Chor, B.; Goldreich, O.; Schnorr, C. P.:
RSA/Rabin Bits are 1/2 + 1/poly(\logN) Secure.
25th Annual Symposium on Foundations of Computer Science (FOCS84).
Singer Island, Fla., USA, 1984. 449-457.
W. Alexi, B. Chor, O. Goldreich, and C.P. Schnorr,
RSA and Rabin functions: Certain parts are as hard as the whole,
SIAM Journal of Computing (2) 17 (1988), 194-209.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Date: Thu, 24 Aug 2000 12:23:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: understanding RC4
[EMAIL PROTECTED] wrote:
> 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?
If there would be such a thing, RC4 would be broken. However,
if no salting is used, there has to be a different key for each
message.
> Does no-salt-used mean that the encryption key does not depend on the
> plaintext?
The encryption key never depends upon the plaintext.
No salt means there is no IV. Normally, you put some random data
in front of the message, the IV (initialization vector), and
append this random data to the key. This is done because else
the stream cipher would be easily broken just like an OTP which
has carelessly been used multiple times (build the XOR of the
messages and test the statistical properties of the messages.
It will be the same as the XOR of the original messages. This
is often enough to decrypt the original message).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The future direction ...
Date: Thu, 24 Aug 2000 10:29:06 GMT
On Wed, 23 Aug 2000 22:46:47 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>You might also consider how quantum computing could be used in
>*producing* security.
Although quantum cryptography is well known, I think the application
of quantum computers to encipherment is limited - although perhaps
some novel types of public-key system could make use of them - because
parallelism isn't normally useful when putting a message into cipher.
With a quantum computer, though, (sufficiently small) one-way hash
functions would be invertible - while this wouldn't make them useful
in public-key systems, one could combine it with a secret key to
'double' the attacker's workload.
Although I think that the idea of using a keyed hash function as a
cipher wouldn't be the best way to make a stronger cipher, even if a
quantum computer would make it practical, I suppose this might suggest
some useful ideas.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 10:42:08 GMT
Mok-Kong Shen wrote:
> This once again stresses the fact that one can't entirely
> depend on stuffs from others being error-free, bug-free,
> etc. etc. One has to do something oneself, if security is
> really at stake.
I'm not sure why that should produce something that's
error-free or bug-free or even etc.
From the point of the PGP developers they probably did
do something themselves ....
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malmö, Sweden
------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 11:07:58 GMT
"Spud" <[EMAIL PROTECTED]> wrote:
> 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.
If the C program uses 8 bit unsigned chars, then _all_ data from that 16
bit "byte" must be able to be read using an array of unsigned char - of
one unsigned char, to be precise, because sizeof(one byte)==1. This
means that the other 8 bits may _not_ be used by the C implementation
for anything else - including for reading data from a file. In
particular, all data read from your Pascal-written file must be put in
the 8 bits of your "byte" that are occupied by the unsigned char.
Therefore, the rest of the bits just don't exist from a C point of view;
and your "byte" of 16 bits is not what the C standard talks about when
it uses the word byte.
Richard
------------------------------
From: "JL" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 11:19:53 GMT
"Sam Simpson" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> The effect is that GCHQ can create a tampered version of your PGP
> public key containing a public key whose corresponding private key is
> also known to themselves, and circulate it. People who encrypt
> traffic to you will encrypt it to them too.
The bug isn't that nasty, since the receiver would see that the message has
been encrypted with additional keys, and can then send a non-tampered version
of his public key to the sender. Only the first message would then be
compromised, and both the sender and the receiver would know about it.
JL.
------------------------------
From: Nathan the Great <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Thu, 24 Aug 2000 11:17:42 GMT
In article <DtSo5.2462$[EMAIL PROTECTED]>,
"Adam Russell" <[EMAIL PROTECTED]> wrote:
> <other logic systems snipped>
> > Constructive logic:
> > Logics in which a wff is true iff it is provable. Therefore,
> > undecidable truths (like Godel's G) are ruled out by
> > definition.
>
> So would an undecidable statement be false and
> it's negation also be false?
It's hard avoiding 'double speak' when discussing logic
with an 'outsider' (one accustomed to a different flavor).
Here 'truth' translates into 'provability', and 'undecidable
truth' becomes a meaningless contradiction of terms.
--
Nathan the Great
Age 12
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 13:32:38 +0200
JL <[EMAIL PROTECTED]> a écrit dans le message :
tx7p5.4992$[EMAIL PROTECTED]
>
> The bug isn't that nasty,
It is, unfortunately.
> since the receiver would see that the message has
> been encrypted with additional keys,
Not necessarily. If the receiver has cached his decryption passphrase as
many do, the message will be decrypted without him being shown the
corresponding list of possible decryption keys, and thus he will not see the
unexpected ADK.
If he sees it, he will just see it as an "unknown public key" because he
will not have any copy of the forged ADK in his keyring, thus he may not
correctly identify the risk.
The recipient may think that the sender has also copied the message to
somebody else (which can be possible and normal in some cases) or maybe that
the sender has encrypted the message to one ot the sender itself's keys
which the recipient is not aware of.
> and can then send a non-tampered version
> of his public key to the sender. Only the first message would then be
> compromised, and both the sender and the receiver would know about it.
Not so sure. Especially for unexperimented PGP users who may not be able to
diagnose and understand what is going on.
This bug, if confirmed, is the worst bug ever reported in any version of
PGP, and, IMHO, immediately disqualifies continuing using DH/DSS keys in PGP
until further investigations / fixes are available.
If this bug is confirmed, I'm afraid that every PGP user should consider
immediately revoking his DH/DSS keys and revert back to RSA for the time
being.
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: New algorithm for the cipher contest
Date: 24 Aug 2000 11:48:03 GMT
Alexis Machado <[EMAIL PROTECTED]> wrote:
> I didn't understand how the multiplication got into the M function in your
> last equation.
I might have got it wrong! I did just work it out in my head in a brief
period of lucidity.
The working goes like this. M(M(x)) = x for all x. I made some changes
of variables:
x_i = M(x'_i), K_{2i} = M(K'_{2i}), K_{2i+1} = K'_{2i+1}
The primed variables are the ones from the original formulation; the
non-primed ones are my new notation. Note that there are (implicit)
input and output transformations, and a modification to the key
schedule. These differences can be neglected for the purposes of
cryptanalysis, except inasmuch as they affect the distributions of
plaintexts.
We start with
x'_{i+1} = M(x'_i \xor K'_{2i}) * K'_{2i+1}
= (M(x'_i) \xor M(K'_{2i}) * K'_{2i+1}
Mirroring both sides gives:
M(x'_{i+1}) = M( M(x'_i \xor K'_{2i}) * K'_{2i+1} )
= M( (M(x'_i) \xor M(K'_{2i})) * K'_{2i+1} )
Now applying the rewrites above:
x_{i+1} = M((x_i \xor K_{2i}) * K_{2i+1})
as claimed.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography vs. Security through Obscurity
Date: Thu, 24 Aug 2000 11:39:44 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> In fact there are steganographic systems that meet that
> requirement -- even if the enemy is looking for your
> message and knows how you're hiding it, he cannot prove
> that it is present.
Great! Can you list a reference?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography vs. Security through Obscurity
Date: Thu, 24 Aug 2000 11:45:36 GMT
In article <8o1e60$r4g$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Even an adversary who magically guesses which bits are "message" bits
> and which bits are "random" bits will be unable to confirm its guess.
But the can if they have access to more than one message, correct?
Therefore it is possible to at least remove the message, which would
remove the watermarking (which is what I am doing.)
If a system exists that resists this, I'd like to know about it.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Thu, 24 Aug 2000 07:03:06 -0500
Good point but, given the general lack of sophistication of the average
computer user today, irrelevant. In, say, 10 or 20 years, the level of
sophisitication of the average user might be high enough that they simply
won't accept software with such ridiculous restrictions (or software of
generally poor quality). For now, the best we can hope for is the
opportunity to educate some of our fellow carbon-based lifeforms.
"Mr. I. N. Oakley" wrote:
> [EMAIL PROTECTED] (Gisle Sælensminde) wrote:
>
> >The intention of this law is to allow revese engineering
> >if there is sensible reason for doing so.
>
> I think it's outrageous that there could be a law restricting you from
> examining the instructions that someone else is giving to YOUR computer.
> --
> "Mr. I. N. Oakley" is actually 0268 359741 <[EMAIL PROTECTED]>.
> 01 2 3 456789 <- Use this key to decode my email address and name.
> Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "JL" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 12:09:57 GMT
"Michel Bouissou" <[EMAIL PROTECTED]> a écrit dans le message news:
8o314o$k1n$[EMAIL PROTECTED]
> > since the receiver would see that the message has
> > been encrypted with additional keys,
>
> Not necessarily. If the receiver has cached his decryption passphrase as
> many do, the message will be decrypted without him being shown the
> corresponding list of possible decryption keys, and thus he will not see the
> unexpected ADK.
True, but that's just an other reason not to use passphrase chaching.
> If he sees it, he will just see it as an "unknown public key" because he
> will not have any copy of the forged ADK in his keyring, thus he may not
> correctly identify the risk.
True, but it should be a hint to proceed to deeper verification.
> The recipient may think that the sender has also copied the message to
> somebody else (which can be possible and normal in some cases)
Not if he is the only recipient of the message.
> or maybe that
> the sender has encrypted the message to one ot the sender itself's keys
> which the recipient is not aware of.
Tha should also be a hint.
> > and can then send a non-tampered version
> > of his public key to the sender. Only the first message would then be
> > compromised, and both the sender and the receiver would know about it.
>
> Not so sure. Especially for unexperimented PGP users who may not be able to
> diagnose and understand what is going on.
That's the main point. It's mostly unexperienced users who are vulnerable to
this bug.
> This bug, if confirmed, is the worst bug ever reported in any version of
> PGP,
True, and I'm not discussing that. The bug creates and unacceptable level of
risk, but it can be greatly reduced with simple precautions, and most of all
it's easy to check if a message has been compromised or not (if you have
checked that there are no ADK you can be 100% certain that no one else can
decrypt it).
> and, IMHO, immediately disqualifies continuing using DH/DSS keys in PGP
> until further investigations / fixes are available.
In some versions of PGP, the 6.5.1ckt that I use for example, there is a red
button which indicates when keys have an ADK. If all users were to use this
feature it would also help reduce the risk.
And since the bug resides in the sender's sofware no fix can erradicate the
problem, since you can't force everybody to update.
> If this bug is confirmed, I'm afraid that every PGP user should consider
> immediately revoking his DH/DSS keys and revert back to RSA for the time
> being.
Simply revoking a DH/DSS key and issuing a new RSA one is also risky, since
you need to re-create the whole signature chain, which makes you vulnerable.
If you think the risk justifies that you should revert back to RSA, the best
way to do it is to only revoke the DH/DSS subkey, which is used for
encryption, and keep the main keep valid, which is used for signing. You can
then sign your RSA key with your existing DH/DSS key, thus preserving the
signature chain.
JL.
------------------------------
** 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
******************************
