Cryptography-Digest Digest #526, Volume #12 Thu, 24 Aug 00 13:13:01 EDT
Contents:
Re: Serious PGP v5 & v6 bug! (Runu Knips)
Re: Steganography vs. Security through Obscurity (David A Molnar)
Re: Serious PGP v5 & v6 bug! ("Howard")
Re: Serious PGP v5 & v6 bug! ("Howard")
Re: Serious PGP v5 & v6 bug! ("Sam Simpson")
NIST SHA-1 test data (John Myre)
Re: Serious PGP v5 & v6 bug! ("Howard")
Re: Testvectors for DES and 3xDES (John Myre)
Re: Serious PGP v5 & v6 bug! ("Sam Simpson")
Re: Serious PGP v5 & v6 bug! ("JL")
Re: Steganography vs. Security through Obscurity (Guy Macon)
Re: blowfish problem ("Douglas A. Gwyn")
Re: Serious PGP v5 & v6 bug! (Mack)
Re: Provably secure stream cipher ("Douglas A. Gwyn")
Re: The DeCSS ruling ("Douglas A. Gwyn")
Re: Steganography vs. Security through Obscurity ("Douglas A. Gwyn")
Re: New algorithm for the cipher contest ("Alexis Machado")
Re: The DeCSS ruling (Mark Wooding)
Re: blowfish problem ("Spud")
Re: blowfish problem ("Spud")
Re: blowfish problem ("Spud")
Re: understanding RC4 (Bill Unruh)
Re: Serious PGP v5 & v6 bug! ("JL")
Re: Serious PGP v5 & v6 bug! ("Michel Bouissou")
Re: Serious PGP v5 & v6 bug! ("JL")
----------------------------------------------------------------------------
Date: Thu, 24 Aug 2000 16:26:17 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
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.
Sorry, but this statement is silly. One better depends upon
something from the specialists than depending upon the own
code. There is no error free code anyway, but one has a
better chance for it if one uses something which got
public review, such as PGP, GnuPG, OpenSSL etc.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: 24 Aug 2000 14:01:28 GMT
[EMAIL PROTECTED] wrote:
> 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?
I don't think so, at least not in the model I had in mind.
In this model, the messages are surrounded by random - and non-repeating -
bits streaming from a truly random source. You can't just compare two
streams, see where they differ, and conclude "a-HA, I have found a
message!" because two random streams will differ from each other with
high probability.
This is, of course, totally not the model for watermarking.
I had in mind the "hidden transmission of message" notion of
steganography, in which I think the model I was thinking of
makes sense, though contrived. For watermarking, though, it doesn't.
> Therefore it is possible to at least remove the message, which would
> remove the watermarking (which is what I am doing.)
Yes, it seems that merely embedding an encrypted message into the
binary is *not* sufficient for watermarking, for the reason you outlined
: an adversary can easily compare it to a copy of the file known not
to be watermarked and diff. Oops.
Watermarking and traitor tracing is something which I know exists,
but not much more. If you want to see if your new watermarking and
traitor tracing scheme is new, I'd suggest
a) finding some of the recent papers -- Dan Boneh has one from CRYPTO '99
on "Black Box Traitor Tracing" which is intriguing in its own right,
probably has references. The citeseer service is good for this; so is
the Cora search system (cora.justresearch.com).
b) finding someone who's published watermarking work near you to ask
directly. such people probably also read this group, but asking someone
directly increases the chances of a useful answer.
c) patent searches. lots of stuff ends up patented which never makes
it into normal print. sometimes this is legitimate, real research.
d) if you are willing to spend the time, you can submit it to a
conference for peer review. the referees will have some idea of
what is novel and what is not (we hope). while it's unrealistic
to expect them to break it for you if it is broken, publishing
it increases the odds that you'll hear about it when it is broken.
-David
------------------------------
From: "Howard" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 14:22:39 +0100
=====BEGIN PGP SIGNED MESSAGE=====
<[EMAIL PROTECTED]> wrote in message
: but even RSA keys can have ADK, see:
: http://senderek.de/security/key-experiments.html
:
: but you can avoid ADKs by removing self-signature from key
: if you do not self sign the key - no ADKs can be added tu that key.
: very good reason not to self-sign keys
I didn't know that either...
Cheers
Howard
PGP Keys:
0xECFEF05F (DH/DSS)
0x96302AD7 (RSA)
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQEVAwUBOaUhm/ex36KWMCrXAQGAbAgA23Mk3zfdaIa0B1i5/tXBTxccALI0r3JN
+w/QUUv4A2lEqyP3OrFlNYOdhIpg+sulAKJxwyHDWhkzURPMQC3Kp3AiiYOj6SVb
vK0BLAht7T99qb7fFa210dlT4H82IjUiTlDz+7VD3Z3+v8GqBxzA9HJTjIEJII+h
co44ksCc3YbsrIhgyLJSUAebA+BqU5XgiPAZ+8EVeRLISUmIHxC1cZULAQUGuJNR
ORla01iNMFomUGh39Bwq51tNrmAMhpv21lj108qN7yYJPfExyVC+6wbbMbfulCCM
ayj5BmKugfs5iZQ/sDlrAYHOKejAPeSaANnXmpPUYnIZ1XE/6gjbMA==
=FM84
=====END PGP SIGNATURE=====
------------------------------
From: "Howard" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 15:30:12 +0100
=====BEGIN PGP SIGNED MESSAGE=====
"JL" <[EMAIL PROTECTED]> wrote in message
news:pg8p5.5011$[EMAIL PROTECTED]...
: "Michel Bouissou" <[EMAIL PROTECTED]> a écrit dans le message news:
: 8o314o$k1n$[EMAIL PROTECTED]
: 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.
My understanding of Ralf's paper is that the ADK is undetectable. Is this
what everyone else understands? For this reason he advocates the use of
version 2.6.x which will reject all version 4 signed keys.
Ok fine, there's effectively no difference in the security of DH keys and
RSA version 4 signed keys, since they can both be manipulated, (although
the RSA version is a little more difficult), the problem lies instead with
the PGP version number. However, using V 6.5.3, what I'm relying on is that
the ADK is visible and that warnings actually work.
The crux of this problem is it's delectability, since "illegal"
manipulation does not affect the keys fingerprint. However PGP software is
supposed to declare the existence of and ADK. As the manual (freeware)
does not go into any detail at all, I can't fathom at which stage an ADK is
normally added , and in what respect this differs from a "doctored" or
manipulated key.
When are ADKs normally added to a users Public Key?
Does Ralf's paper describe the ADK addition as being wholly different from
the way the ADK is normally added?
Is it Ralf's opinion that manipulated keys do not reveal the presence of
ADKs?
If so, why do keys containing "legal" ADKs differ from manipulated ones in
failing to announce the presence of the second key?
Rgds
Howard.
PGP Keys:
0xECFEF05F (DH/DSS)
0x96302AD7 (RSA)
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQEVAwUBOaUxcfex36KWMCrXAQFabwf/YbQW2QiKlNiH5ERaIpBPuxppM0auDoux
Cnb53Gy74gRbx90c2C6zkTevR6BRYaRC29SOkImm/BiD+vDn/xLAJFei7S7/JyBg
jChdIyyHUeN/22seSGjj3r22u4orv41uBMes3nDomPrZqhDkyXwZd63emly/WTwj
XAhmVcFqVyaOHaOMHW5AUkV6z3anCwTvb6oS2p/BCeXreRBmRVU1I/Eh157/l0em
qZ+IxggDYwwUVNvTZQDLqlsGeWIvYG22i4NqxLBVJQl/Sf7lQImvo8SDsHafd88/
MScYiLrqUNNhSltDUQRM2MeCF3uqOb4YkDKvXHrelG0q2KFOa6Q/6g==
=tcrS
=====END PGP SIGNATURE=====
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 15:45:08 +0100
It's interesting to note that GnuPG doesn't suffer from this
problem - GnuPG just doesn't recognise the packet identifier as it's
never been put into RFC2440. I agree with Runu, this certainly isn't
a case for not using open / peer-reviewed software. It certainly
will cause a few "I told you so" from people who campaigned to NOT
implement this feature in the first place....
So, specifically, this problem is only an issue if the sender is
using an effected version of NAI PGP....Which just so happens to be
most users!
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Runu Knips <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
>
> Sorry, but this statement is silly. One better depends upon
> something from the specialists than depending upon the own
> code. There is no error free code anyway, but one has a
> better chance for it if one uses something which got
> public review, such as PGP, GnuPG, OpenSSL etc.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: NIST SHA-1 test data
Date: Thu, 24 Aug 2000 08:49:22 -0600
Near the end of http://csrc.nist.gov/cryptval/ there is a
pointer to "SHA-1 Sample Vectors", which is
http://csrc.nist.gov/cryptval/shs/sha1-vectors.zip
The input format is a little peculiar (it lists the run
lengths of 0 and 1 bits), and the longest input is not
that big, but it does have a lot of cases, and many inputs
with lengths that are not a multiple of 8 bits.
JM
------------------------------
From: "Howard" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 16:01:08 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: It's interesting to note that GnuPG doesn't suffer from this
: problem - GnuPG just doesn't recognise the packet identifier as it's
: never been put into RFC2440
Sorry to be a pain Sam, but as a concerned NAI user ;-) Can you expand on
the above please? I'm not familiar with GnuPG. Are you referring to a
different method of implementing public key encryption?
Rgds
Howard
Staffordshire, England
PGP Keys:
0xECFEF05F (DH/DSS)
0x96302AD7 (RSA)
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOaU4sgAiYvTs/vBfEQJ2BgCg3n1g0z4dSNCuZvEl89SBU+m08oUAoOs2
muhyORK9WmBxiZHKwBMlhEgc
=3O7z
=====END PGP SIGNATURE=====
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Testvectors for DES and 3xDES
Date: Thu, 24 Aug 2000 09:25:41 -0600
kihdip wrote:
>
> Has somebody knowledge of a site with testvectors for DES and 3xDES ??
See also
http://csrc.nist.gov/nistpubs/800-17.pdf
http://csrc.nist.gov/nistpubs/800-20.pdf
which contain all sorts of implementation information, including
some test vectors and intermediate results in the appendices.
They're sort of large, however.
JM
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Thu, 24 Aug 2000 16:34:44 +0100
GnuPG is a free, open-source implementation of the PGP algorithms
(more formally known as RFC2440). See for example: www.gnupg.org.
It's all command line at the moment, doesn't support DOS/WIN32 well
and is really aimed at UNIX users - but it does work VERY well and is
the version I recommend if users have the right operating system.
Regards,
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Howard <[EMAIL PROTECTED]> wrote in message
news:3Qap5.719$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Sam Simpson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> : It's interesting to note that GnuPG doesn't suffer from this
> : problem - GnuPG just doesn't recognise the packet identifier as
it's
> : never been put into RFC2440
>
> Sorry to be a pain Sam, but as a concerned NAI user ;-) Can you
expand on
> the above please? I'm not familiar with GnuPG. Are you referring to
a
> different method of implementing public key encryption?
>
> Rgds
> Howard
> Staffordshire, England
>
> PGP Keys:
> 0xECFEF05F (DH/DSS)
> 0x96302AD7 (RSA)
------------------------------
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 15:42:22 GMT
"Ron B." <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> If Jane [...] is not available to
> decrypt important data, the company may have legitmate reasons to
> have access to her messages.
Jane has of course given a copy of her private key to other trusted employees,
there's no need for ADKs for that.
JL.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Steganography vs. Security through Obscurity
Date: 24 Aug 2000 15:47:20 GMT
[EMAIL PROTECTED] wrote:
>
>
>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?
Not needed - the solution is trivial.
Get a good hardware RNG and send me a maeesage every day consisting
of random data from the RNG.
Every so often, use the OTP encrypt a message with a pad from the
same RNG and send that.
No attacker can tell whether you sent a message or not.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 14:58:50 GMT
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.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 24 Aug 2000 15:56:21 GMT
Subject: Re: Serious PGP v5 & v6 bug!
>"Ron B." <[EMAIL PROTECTED]> a écrit dans le message news:
>[EMAIL PROTECTED]
>
>> If Jane [...] is not available to
>> decrypt important data, the company may have legitmate reasons to
>> have access to her messages.
>
>Jane has of course given a copy of her private key to other trusted
>employees,
>there's no need for ADKs for that.
>
>JL.
>
>
Jane could also provide her public key to other trusted employees
using a threshold scheme. That way the information is secure
until m of n people decide the need it.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Provably secure stream cipher
Date: Thu, 24 Aug 2000 15:07:06 GMT
wtshaw wrote:
> By definition, pure stream ciphers tend to fall apart with reuse of the
> key stream, plaintext attacks making all possiblities transparent.
No more than for block ciphers.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Thu, 24 Aug 2000 15:11:41 GMT
Daniel Leonard wrote:
> Well the code can be found, in clear, from the court transcript.
> http://cryptome.org/dvd-hoy-reply.htm
> as exhibit B
That's funny!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Thu, 24 Aug 2000 15:16:31 GMT
[EMAIL PROTECTED] wrote:
> Great! Can you list a reference?
Unfortunately our Web site is apparently undergoing renovation,
but the person to talk to is Lisa Marvel (ARL, APG site).
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Thu, 24 Aug 2000 13:19:57 -0300
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Alexis Machado <[EMAIL PROTECTED]> wrote:
>
>
> 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})
>
I got your point.
I think this relates with my early concern that the first M (mirror)
function doesn't do much to cipher security (at least for diffusion). I
conserved it to have a similar structure in the decipher function
(DecipherBlock). The first M in the cipher becomes the last in decipher. I
believe the last M contributes to security in the decipher. So, if the enemy
decides to work backwards ...
Alexis
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: The DeCSS ruling
Date: 24 Aug 2000 16:31:07 GMT
Barry Adams <[EMAIL PROTECTED]> wrote:
> Quid custodes ipso custodian
I think you mean `Quis custodet ipsos custodes?' What you've written
makes no sense.
-- [mdw]
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 09:32:24 -0700
[snips]
"Chris Torek" <[EMAIL PROTECTED]> wrote in message
news:8o2qp5$sci$[EMAIL PROTECTED]...
> 5.2.4.2.1 Sizes of integer types <limits.h>
Aha, she cried, waving her wooden leg aloft, sticking it in the butter - as
my granny used to say. By some dint of fate, I managed to miss this one
completely - but it quite happily settles the matter. Thank you, thank you.
:)
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 09:33:27 -0700
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
Well, such was the theory; it took Chris Torek to actually dig it up.
5.2.4.2.1.
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 09:36:42 -0700
"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." 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. :) )
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: understanding RC4
Date: 24 Aug 2000 16:39:50 GMT
In <8o1c2t$d7i$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
]------------------------------------------------
]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.
Something strange is happening here. If there were really no salting,
or IV, then the encrypted string should be as long as the original
message-- 6 bytes ( or 8 if the quote marks were part of the message).
It is not. It is 16 bytes long. RC4 is just a stream cypher in which a
stream of pseudo random bits is Xored witht he message.
]Given this information, is it possible to write an RC4 encryption
]routine that does helps me encrypt other plaintexts in the _same_
]manner?
RC4 ( or rather ARC4) implimentations are pleantiful on the net.
However as with any crypto system you need the key to decrypt. If you
do not have the key, no-one knows how to decrypt RC4 nor find the key
even if plaintext and encrypted text are known.
]Does no-salt-used mean that the encryption key does not depend on the
]plaintext?
The encryption text must depend on the plaintext plus the key, or else
the encryption is somewhat useless.
------------------------------
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 16:44:59 GMT
"Michel Bouissou" <[EMAIL PROTECTED]> a écrit dans le message news:
8o39ko$k97$[EMAIL PROTECTED]
> Still worse, being able to read the message probably means that the attacker
> was able to intercept your e-mail. If the attacker is able of a true MITM
> attack, he can remove the message (that he was able to decrypt) and
> re-encrypt it to a genuine copy of your key, so you will receive the
> original message encrypted to your key only, and have no way to directly
> discover the manipulation. Only, of course, that the such re-encrypted
> message could not be PGP-signed by the sender.
An invalid signature would be enough to warn you, and this would therefore not
be a successfull MITM attack.
> I'm not myself expert in the PGP packet structure (and so request expert
> advice), but could it be possible that the MITM attacker gets the message,
> and then only removes the packets corresponding to the additional ADK
> encryption before forwarding the message to its intented recipient, thus
> keeping the signature intact and making the interception unnoticeable to the
> recipient?
Hum... I hadn't thought of that. It all has to do with whether the message is
signed before or after encryption. From what I understand from RFC 2440 the
message is signed BEFORE encryption, and that would seem logical since it
enables only the recipient to check the signature:
First, a signature is generated for the message and
attached to the message. Then, the message plus signature is
encrypted using a symmetric session key. Finally, the session key is
encrypted using public-key encryption and prefixed to the encrypted
block.
It is therefore very possible for a MITM attacker to remove the ADK packets
unoticed. This bug is much more devastating than I originally thought.
The only workaround is to manually sign your message AFTER encryption, so that
the recipient can check the packets haven't been tampered with.
What still needs to be checked is whether a tampered key will trigger and ADK
warning on the sender's software or not.
> For all these reasons, and if this "bug" is confirmed, the only reasonable
> and secure choice would be to immediately quit using any key format or
> software that might allow an attacker to append its own ADK to one's public
> key.
>
> Which unfortunately means quit using any PGPv5 or PGPv6 DH/DSS keys, or
> PGPv5 or PGPv6 created RSA keys.
That wouldn't be a solution at all, since you don't have control over which
software the sender uses to send encrypted messsages to you. Even if you use
GPG, the sender could still use PGP 6.x.
JL.
------------------------------
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 18:51:57 +0200
Howard <[EMAIL PROTECTED]> a écrit dans le message :
Cnap5.687$[EMAIL PROTECTED]
>
> My understanding of Ralf's paper is that the ADK is undetectable. Is this
> what everyone else understands?
No, I don't think so. There are 3 ways that you can detect that an ADK is
out there:
1) When displaying your keyring, you can show an (optional) ADK column that
will indicate which keys do have an ADK.
2) When encrypting to a key which includes an ADK, you can get an (optional,
set from PGP preferences) warning that you will be encrypting to a key with
an ADK.
3) When decrypting a message that was sent to you, if not using a cached
passphrase, you will be presented with the list of keys the message was
encrypted to, and there you can notice the presence of an "Unknown recipient
key", that would mean that the copy of your public key that the sender is
using *could*possibly* have been forged with a supplementary ADK.
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 ;-)
- For (3), you won't notice anything if you have a cached passphrase. And,
even if you see that the message has been encrypted to some other unknown
key than yours, it doesn't necessarily make an evidence that a forged ADK is
the cause for that.
> The crux of this problem is it's delectability, since "illegal"
> manipulation does not affect the keys fingerprint. However PGP software is
> supposed to declare the existence of and ADK. As the manual (freeware)
> does not go into any detail at all, I can't fathom at which stage an ADK
is
> normally added , and in what respect this differs from a "doctored" or
> manipulated key.
>
> When are ADKs normally added to a users Public Key?
Freeware versions of PGP doesn't seem to allow creating keys with ADKs,
AFAIK. And I have never used a PGP version which creates such keys. But I
would bet that the ADK is made at key generation time, when the key is
self-signed.
> Does Ralf's paper describe the ADK addition as being wholly different from
> the way the ADK is normally added?
Normally, the ADK resides in the hashed portion of the self-signature of the
key, and as such is protected by this signature.
The matter is that you can forge and ADK in a non-hashed portion of the
self-signature of the key (why the hell is there such a non-hashed portion
?????) and the ADK will actually be used by PGP even if found there,
although it is not validated by the key self-signature, and thus this
addition doesn't make this signature invalid either.
> Is it Ralf's opinion that manipulated keys do not reveal the presence of
> ADKs?
As far as I understood, the ADK is visible not more and not less than a
normal ADK, but PGP cannot tell that it is a faked ADK although it doesn't
reside in the portion of the signature where it should normally reside.
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
------------------------------
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 16:58:15 GMT
"Howard" <[EMAIL PROTECTED]> a écrit dans le message news:
Cnap5.687$[EMAIL PROTECTED]
> My understanding of Ralf's paper is that the ADK is undetectable.
That's not what I understand.
I understand that it's only whether ADKs are signed or not which is not
checked:
« the "phashed" parameter is used to return whether the subpacket was in the
hashed region [...] the "phashed" value isn't checked ». But the presence of
ADKs itself is checked as required.
That's why he talks about « generating BIG WARNINGS when ADKs are found in the
non-hashed area », that is bigger warnings than when they're found in the
hashed area.
> Is it Ralf's opinion that manipulated keys do not reveal the presence of
> ADKs?
Not from what I understand from what has been quoted.
> If so, why do keys containing "legal" ADKs differ from manipulated ones in
> failing to announce the presence of the second key?
"Legal" ADKs are signed by the key holder, not manipulated ones. But PGP
doesn't check whether sthey're signed or not, that's the bug.
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
******************************
