Cryptography-Digest Digest #542, Volume #12 Sat, 26 Aug 00 13:13:00 EDT
Contents:
Re: Best way! ([EMAIL PROTECTED])
Re: Asymmetric Encryption Algorithms (DJohn37050)
Re: PGP 6.5.8 test: That's NOT enough !!! ("Nathan Williams")
Re: Serious PGP v5 & v6 bug! ("Nathan Williams")
Re: PGP 6.5.8 test: That's NOT enough !!! ("Peter Ihm")
Bytes, chars, and I/O (David Hopwood)
Re: Bytes, octets, chars, and characters (David Hopwood)
Re: New algorithm for the cipher contest ("Scott Fluhrer")
Re: PRNG Test Theory (Mok-Kong Shen)
Re: Serious PGP v5 & v6 bug! (Dave Howe)
Re: Best way! ("Big Boy Barry")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Best way!
Date: Sat, 26 Aug 2000 15:13:03 GMT
In article <8o8j83$it4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8o8iji$i97$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Obviously you have no clue what you are talking about.
> >
> > PGP is still secure iff you do not share your keys indirectly. Or
if
> > you use PGP 2.6.2.
> >
> > You can always try the Entrust package or GnuPG, or write your own.
> >
>
> You are the one who misunderstands the flaw in the PGP key packet
> specification. Even if you take all the precautions possible against
> someone attaching an ADK to your public key and use PGP 2.6.2,
somebody
> else might not be so careful when they are sending a message to you.
> They could have have obtained your public key and checked the key
> fingerprint and signature: doing either would not have detected the
> presence of an ADK without special effort. BTW, if you have to share
> keys directly, why are you using a PKCS. The flaw in PGP is real, and
> presents a potential DoS, if not a practical security risk. Which is
> not to say that the encryption used in PGP is not neccesarily strong,
> but the weakest link in a cryptosystem is usually the protocol or
> implementation.
And how, pretell do you attach an ADK to a key if you don't have
physical access to it?
And I would be using PKCS or something similar because it would offer
more key entropy then if I made up a conventional key with a friend.
If PGP could make up usefull 256 bit keys that I could lug around I
would use that instead.
>
> It's not iff, just if. Sharing keys directly is not a sufficient
> condition for the secure use of PGP. Your advice to the OP to write
his
> or her own security package is just wrong.
Why? I have, have you heard of Peekboo?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 26 Aug 2000 15:28:16 GMT
Subject: Re: Asymmetric Encryption Algorithms
Not online, distributed at a past ANSI X9F1 meeting. Come on Roger, at least
sometimes one would want to distribute a symmetric key with authentication
regarding where it came from!! Of course, key establishment itself is a
different matter, not provided by a signature.
Don Johnson
------------------------------
From: "Nathan Williams" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Sat, 26 Aug 2000 15:31:15 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Keith,
I am surprised at your viewpoint. I would have to agree with the
others. PGP should at least warn the user that the key has
unrecognized elements or even show that the key has been subject to
this kind of attack.
I am assuming that this is a quick patch to stop the loophole in the
ADK and a more robust version will be forth coming.
Nathan Williams
"Keith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> On Sat, 26 Aug 2000 12:49:17 +0200, Michel Bouissou
> <8o87bf$p7m$[EMAIL PROTECTED]> wrote:
>
> >Where previous versions would show this key as having an ADK, and
> >use the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as
> >being a normal, valid key, without any ADK.
>
> There is no way for PGP to detect a forged key. That is what a
> signature and trust values are for. As long as PGP removes and/or
> doesn't recognize the forged ADK on a tampered key, which will lead
> to the encryption of a file or message to the forged ADK, then that
> is the proper action.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use
> <http://www.pgp.com> Comment: pgp keys available at
> http://strongsignals.com/pgpkeys.txt
>
> iQEVAwUBOae+QHbKVHAo46vlAQEXhQgAsz6jNjGzBYeaT4Bpu+h1M3kgeHepXFfk
> n86dx+j54MTiUj6y0fkgmtT2CR5Ev/hdqpLlDOdpOD3IoSJ3jFN1P2kZJWepdr+a
> Aj4i1NVvwfrt5OFMtxlPtCr3GXv6e6JiGsTcoIeq5RmFm16BFHh2Zldryv5qfL+R
> 9HxWtMzoWPq5DZbg6+ZflaprV+VsnpPeWkObcFwryq/ZgrS8eXMrAFsQE7YoNJQB
> 5JgB2TXJSLp/tklR3blToA1XjSefbfZwJZ2YJfoq/n+jm1xC1sb+hSwrxiJS6RlK
> u8qgTzkZenIUSXudLk3szp+JG/Cp5gBZaYmGarNpK5VwbplFi+1dBA==
> =8L4/
> -----END PGP SIGNATURE-----
>
> --
> Best Regards,
>
> Keith
> --------------------------------------------------------------------
> --------- Where do you discover free software for Windows?
> Strongsignals DOT COM is a great place to start:
> http://Strongsignals.com "If a man hasn't discovered something
> that he will die for, he isn't fit to live." --Martin Luther King,
> Jr
> --------------------------------------------------------------------
> --------
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOafdyt8G10zX/RREEQIu+wCfdmrNuMTDQMEpCNa3t28xtROvK5cAoPiC
jol/XHyGUFlK5wGUIRGlhx9+
=3TJf
=====END PGP SIGNATURE=====
------------------------------
From: "Nathan Williams" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Sat, 26 Aug 2000 15:31:16 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Sundial,
I'm not sure I agree with that. There is no need for a "enterprise"
environment to have to use the ADK system to have a key escrow.
Company policy could simply require that employees use keys furnished
by the IT or security departments. They would keep copies of both
keys and of its passphases. Simple solution that allows for the use
of PGP without adding the complexity( and therefore the added risk)
of a an ADK.
Nathan Williams.
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You know, Sam, this may be "PGP's nightmare come-true" but ... then
> again *in-practice* people DO lose keys sometimes, and people DO
> get smooshed by bread-trucks sometimes and mission-critical
> messages DO become unrecoverable (with, perhaps, millions of
> hard-dollars lost as a result) and ... "what in the hell do you
> do?" :-/
>
> The way I see it, there -does- come a time when you have to balance
> the perfection of cryptographic security against the reality of the
> fact that people ... are flesh-and-blood carbon units. "****
> happens, and does your real-world cryptographic system recognize
> this or does it not?"
>
> Yes, key-escrow and key-recovery and yada-yada-yada DOES introduce
> a cryptographic risk and a cryptographic exposure into any system.
> But can we truly say that "in no case at all should it be there?"
> Can we say that "in no case at all is there a business need for
> such a thing?" I'm just not-so-sure.
>
> The true problem that I see that Ralf "uncovered" is that, with the
> presence of a "hidden second key," there are now "two bits" and
> therefore "three (11) not one (01) possibilities" in the overall
> trust equation. Existing schemes for validating secure
> communication between Bob and Alice are not adequate to handle the
> possibility that Matt (Bob's manager) might be in the picture too,
> and therefore that Eve might be able to impersonate either Bob *or*
> Matt and thereby gain entry into the system.
>
> The knee-jerk reaction (expressed so far) seems to be... "SHOOT
> MATT!"
>
> Or, "MATT HAS NO RIGHT TO EXIST!!" ;-)
>
> Or, "IT SCREWS UP MY SYSTEM ;-) ;-) IF MATT EXISTS!!" ;-)
>
> { hey, hasn't that -always- been true of management? } :->
>
> But lurking under all of this is probably .. not a flaw, but a fine
> new wrinkle on cryptology:
>
> WHAT IF WE TRULY -NEED- MATT-THE-MANAGER?
>
> "In the real world," most businesses -do.- (And instead of
> debating that point until all the bits in the Internet turn blue,
> what if we take the preceding statement as a logical premise and
> explore the
> implications to existing cryptographic systems that exist if that
> premise is simply assumed to be true?
>
>
> Sam Simpson wrote:
> > Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> > It's of scientific interest because it spectacularly confirms a
> > prediction made by a number of us in the paper on `The Risks of
> > Key Recovery, Key Escrow, and Trusted Third-Party Encryption'
> > <http://www.cdt.org/crypto/risks98/> that key escrow would make
> > it much more difficult than people thought to build secure
> > systems.
> >
> > He's written a paper on his work and it's at
> >
> > http://senderek.de/security/key-experiments.html
> >
> > Since NAI joined the Key Recovery Alliance, PGP has supported
> > "Additional Decryption Keys" which can be added to a public key.
> > The sender will then encrypt the session key to these as well as
> > to your main public key. The bug is that some versions of PGP
> > respond to ADK subpackets in the non-signed part of the public
> > key data structure. 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.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOafh0N8G10zX/RREEQJWyACfYtXBU5KyimB84WULD1EZ2bfPIqwAmwdT
IjBEqn2vAgwsicdstVGEbl20
=YAGc
=====END PGP SIGNATURE=====
------------------------------
From: "Peter Ihm" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Sat, 26 Aug 2000 17:40:57 +0200
Michel Bouissou schrieb in Nachricht <8o87bf$p7m$[EMAIL PROTECTED]>...
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1
>forged key that holds a faked ADK.
>
>Where previous versions would show this key as having an ADK, and use
>the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being a
>normal, valid key, without any ADK.
>
>PGP 6.5.8 will not use the forged ADK for encryption, and will just
>behave as for a normal key.
>
>Well, okay, it "fixes" the bug.
>
>BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS BEEN
>FORGED. You just see a valid key and the forged ADK is ignored.
well, they never intend to fix it right. As that would make invalid all 5.x
and later versions.
Understand, it's not a bug! Its planned. Otherwise the 2.6.x version they
would had taken as base to create a user friendly Windows version.
Peter
------------------------------
Date: Fri, 25 Aug 2000 20:44:31 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Bytes, chars, and I/O
=====BEGIN PGP SIGNED MESSAGE=====
Kelsey Bjarnason wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Kelsey Bjarnason wrote:
> > > We don't. However, we cannot blithely assume that char "precisely"
> > > fits a byte ...
> >
> > It is not a "blithe assumption". It is embedded in the use of
> > those terms in the C standard, which I helped write.
[snip]
> 6.5.3.4 The sizeof operator
>
> [#2] The sizeof operator yields the size (in bytes) of its
> operand, which may be an expression or the parenthesized
> name of a type. The size is determined from the type of the
> operand. The result is an integer. If the type of the
> operand is a variable length array type, the operand is
> evaluated; otherwise, the operand is not evaluated and the
> result is an integer constant.
>
> [#3] When applied to an operand that has type char, unsigned
> char, or signed char, (or a qualified version thereof) the
> result is 1. When applied to an operand that has array
> type, the result is the total number of bytes in the
> array.75) When applied to an operand that has structure or
> union type, the result is the total number of bytes in such
> an object, including internal and trailing padding.
>
> Nope; neither of those do it.
Yes, they do. The first sentence of #2 and the first sentence of #3
together imply that "the size of operands of type char, unsigned char,
or signed char, is 1 byte".
> #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.
Indeed an 8-bit char can be *represented* as a 16-bit machine byte,
but the size of a byte as defined in the C spec is still 8 bits in
that case.
As for implementations where files could not be transferred portably
between languages, I'm sure that users would complain vociferously.
- From the formal standards point of view, though, I/O interoperability
between two languages is not ensured by either language spec; it is
supposed to be defined by the operating system's Application Binary
Interface (or by networking standards, if files are being transferred
over a network).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOabMYjkCAxeYt5gVAQGDDAf+MEbDfrRReLPdUtducXfzfXX46JuC84A+
R+LPe/SIfEwhwJ9kAI9YO4GgYp/7JY6cdjaZ5MkTlebQ6eXqfzyvHVJRX3V/Ctfl
msv75c1LNc+ZLDJDHq9rHBHPg3aYpHLaUZkJiYZcrng7cBSQ7mwTULPBgNR52Xq7
OAbpSykTXNW1S7Z9sB6KSPLe7bmLnD213ZfW8PFFkMwbyqN4pKN+7T8ZR9n2Pt8B
GZzyKh4FJnz6yjH7n2VZ2zgAQJAiWuxsZ01k5Wq02ID0meBcl2Tr1+jbxh6jGA/h
vh4ZoFDt43ZCDBYyH9FJmiKrGIe/zIXsbs7zkr3nrV9WeajbHT050A==
=6kDb
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 26 Aug 2000 16:20:59 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
=====BEGIN PGP SIGNED MESSAGE=====
"Trevor L. Jackson, III" wrote:
>
> 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?
char is a C type, a byte is a unit of storage (synonymous with octet in modern
systems, although not historically), and a character is a symbol, numeral,
letter, or control code [*].
They are almost synonymous in the C specs, but that's because the C specs are
using terminology that is unhelpful in a more general computing context (this
isn't by any means the only example of that; also note that the terminology
was always poorly thought-out, it hasn't become so just with the advent of
Unicode).
To get back on-topic for one of the newsgroups this is cross-posted to, the
C terminology is particularly unhelpful in the design of systems that involve
converting character strings to and from binary formats, and systems that use
cryptography almost always need to do that.
[*] control codes here include things like diacritical marks, codes that
determine text spacing, positioning, direction, etc., and various other
things that it's useful to encode as part of a text string (or that are
not really anything to do with text, but are there for historical
reasons).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOafgKjkCAxeYt5gVAQFdpggAtpe+piMxo+KjH4W4g4WEVg6LFoVEwOhp
fhzf7QcA6tDFVc4HalYHIQ7joI2ACwns7Kvc/fHe6U910YH8l10OUbbVGYjeI2WE
3j6GOoyG96etjkkBpkCcjuOR7LxC5QxwnENZA9J/xOBben6d4pVGEeJOm4QaCfxa
N5V4MplSHc5U8FVO/RQ77H67TwhmpmKJEPzowBx/xXNhXGpOGonTVtfhyioToBGb
alw6E/DkE0rkwYf/JFtbAJ40+ZnZr0GMqV4ibXv1MAsGcBCwtCicRTEjaXEYI50L
vOxnBYkfMEuqJVoolZmAV21qTXE3IyT0cvHcFKTHC8JvOMlsfzYxbA==
=a26Y
=====END PGP SIGNATURE=====
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Sat, 26 Aug 2000 09:15:54 -0700
<[EMAIL PROTECTED]> wrote in message
news:8ns07a$4ne$[EMAIL PROTECTED]...
> Hi,
>
> I'm submitting a new algorithm to the cipher contest.
>
> The algorithm main characteristics are:
>
> - Doesn't have a Feistel structure.
>
> - The block encryption function presents only four C commands (four
> rounds).
>
> - Each round uses 3 primitives operators: one multiplication, one
> XOR and one bit-reversal function.
>
> - My old Pentium 166 MHz encrypts 3.06 MBytes/s (54 Cycles/Byte) in
> CBC mode. Since the bottleneck is 64-bit multiplications and bit-
> reversal, I think a 64-bit processor and some assembly can give
> competitive performance.
>
> A simple algorithm like this may be easy to analyze, but I couldn't
> break it yet.
I believe I have a way that, given K[3] (which is the fourth multiplicative
key), distinguishes it from randomness with a relatively few amount of
chosen plaintexts and effort, and the actual chosen plaintexts do not depend
on K[3]. This immediately leads to a method of rederiving K[3] with about
O(2**64) effort and circa 100-1000 chosen plaintexts. (It actually consists
of two tests, and the success rate of either depends on the value of K[1],
and they both combined cover the entire range of K[1]'s)
Outline of Nimbus (which is what he calls the cipher in the documentation):
- He treats the plaintext data as a 64 bit word
- A round (in the encrypt direction) consists of:
- Xoring in key dependent value into the data word. This key dependent
value is called K[4]..K[7] in the documentation
- Reversing the order of the bits of the data word (so bit 63 gets moved
into bit 0). He calls this operation "mirroring" in the literature.
- Multiplying (mod 2**64) a key dependent odd value into the data word.
This key dependent value is called K[0]..K[3] in the literature
- The cipher consists of 4 of these rounds. I will assume that the key
dependent words used in each round is independently chosen.
Now, assume the attacker knows K[3]. Then, he can logically strip out the
last multiplication (by taking any ciphertext he has, and multiplying it by
the inverse). In addition, since my attack will care only about bit
differentials, we can also ignore the xor/mirror steps in the fourth round,
because they do nothing to mask that.
The first test is as follows: encrypt pairs of plaintexts. Each pair has an
xor differential in bit 0, and has common random data in the other bits (and
the randomness assumption is importent). Following through the pair through
the cipher, we see that, after the first round, that pair now has an xor
differential in bit 63 and random data in the other bits. Then, in the
second round, the xor does not affect the differential, and the mirror
changes it so the values has an xor differential of 1, or as it is more
convienent to look at it, an additive differential [1] of 1. This means
that, after the multiplication, the values has an additive differential of
K[1], and since we are at a random point, this means that there is a
differential in bit 63 with probability P = K[1] / 2**63 if K[1] <= 2**63
and P = 2 - K[1] / 2**63 if K[1] >= 2**63. Then, after round 3, bit 0 will
have a differential with probability P. If P is greatly different from 1/2,
that is, if K[1] is far from either 2**62 or 2**62+2**63, then a relatively
few number of pairs will distinguish it, in that bit 0 of round 3 will have
a differential either much more often than expected, or much less often than
expected.
The second test is as follows: encrypt quads of plaintexts, each quad
consisting of all four distinct bit 0/bit 1 values, and common random data
in the upper 62 bits. Then (following the logic above), after the second
multiplication, the quad will be X, X+K[1], X+2K[1], X+3K[1] in some order.
If K[1] is approximately 2**62 or 2**62+2**63, then these values will have
four different values in the upper 2 bits with good probability, and so,
after the third round, each of the quad will have a distinct value in the
lower 2 bits with much higher probability than randomness, and so that
yields a distinguisher when K[1] is in the right range.
By some odd coincidence, the second test yields a distinguisher exactly when
the first test does not. So, no matter what K[1] is, we have a
distinguisher (and, as a side bonus, we gain some information on K[1])
>
> I hope the points above might encourage you to take a look at this
> cipher.
>
> Please download the documentation and source file (19 KB):
> http://www.meubrfree.com.br/~gauss-inf/nimbus/unimbus.cpp
>
> Sorry for my english, my primary language is portuguese.
Hey, your English is better than some supposedly native-speakers here, so I
wouldn't worry (or apologize) for it...
[1] In this case, I refer to an additive differential of K as meaning that
the pair is (X,X+K), without regard to which of the pair is X and which is
X+K.
--
poncho
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Sat, 26 Aug 2000 19:08:11 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Since any PRNG test can tell when a stream of bits is empiracly
> random,
> > > that should suggest that any PRNG test can be turned into a PRNG
> itself.
> >
> > To my humble knowledge such a test tells you (with respect to
> > a certain 'pattern' and at a certain confidence level) whether
> > non-randomness is likely to be there, nothing more. Passing
> > a multitude of different tests of extensive outputs from a
> > source enhances the expectation that the source approximates
> > well a really random one so that the opponent very likely may
> > not be able to know how to exploit any weakness that is not
> > yet detected by you.
> >
> > Your claim that any PRNG test can be turned into a PRNG is
> > not understandable for me, especially when several tests
> > are considered. Take for example the frequency test and
> > the serial test (at lag 1). Could you please elaborate on
> > your idea in some concrete manner with a good example
> > of generation of a number of successive bits? (Even for a
> > single test you have yourself shown the difficulty, if I
> > don't err. You want the resulting output to pass all tests
> > being considered simultaneously, don't you?)
>
> What you have is "state" where you make each possible output in the
> next step. Then you test to see which is "more" random. The one that
> is will be outputted and added to the state.
Try to write a piece of pseudo-code to formally express
your idea, and you'll see, I am convinced, the trouble
of actually generate the bit sequence without conflicting
with the underlying theoretical background of the
statistical tests.
M. K. Shen
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Sat, 26 Aug 2000 18:00:03 +0100
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[25 Aug 2000 01:52:42 +0200]),
Ralf Muschall <[EMAIL PROTECTED]> said :
>Then it should be simple to ask the sender to resend the message,
>encrypted with Jane's successor's (or chief's) public key. In this
>situation, the sender has full power to decides who may read his
>messages, not some third person not authorized by him.
I can see plenty of situations where this might not happen - for
instance, if the reason Jane's successor needs to access the message
is because the sender is disputing having sent it...
>Remember that pgp is not for ecrypting locally stored data, like
>backups etc. (symmetric methods are better for this purpose), but only
>for the safe *transport* of messages.
It's a tool - if it works well as a hammer, it may well be used to
knock in nails, even if that isn't its primary purpose. Unless Jane
is given some alternative (such as PGPdisk) for local file protection,
she is likely to use PGP as it is *there*
--== DaveHowe ( is at) Bigfoot dot com ==--
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Re: Best way!
Date: Sat, 26 Aug 2000 17:09:51 GMT
I am a newbie to encryption. Am I right about PGP being insecure?
<[EMAIL PROTECTED]> wrote in message news:8o8mpl$mib$[EMAIL PROTECTED]...
> In article <8o8j83$it4$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > In article <8o8iji$i97$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > Obviously you have no clue what you are talking about.
> > >
> > > PGP is still secure iff you do not share your keys indirectly. Or
> if
> > > you use PGP 2.6.2.
> > >
> > > You can always try the Entrust package or GnuPG, or write your own.
> > >
> >
> > You are the one who misunderstands the flaw in the PGP key packet
> > specification. Even if you take all the precautions possible against
> > someone attaching an ADK to your public key and use PGP 2.6.2,
> somebody
> > else might not be so careful when they are sending a message to you.
> > They could have have obtained your public key and checked the key
> > fingerprint and signature: doing either would not have detected the
> > presence of an ADK without special effort. BTW, if you have to share
> > keys directly, why are you using a PKCS. The flaw in PGP is real, and
> > presents a potential DoS, if not a practical security risk. Which is
> > not to say that the encryption used in PGP is not neccesarily strong,
> > but the weakest link in a cryptosystem is usually the protocol or
> > implementation.
>
> And how, pretell do you attach an ADK to a key if you don't have
> physical access to it?
>
> And I would be using PKCS or something similar because it would offer
> more key entropy then if I made up a conventional key with a friend.
> If PGP could make up usefull 256 bit keys that I could lug around I
> would use that instead.
>
> >
> > It's not iff, just if. Sharing keys directly is not a sufficient
> > condition for the secure use of PGP. Your advice to the OP to write
> his
> > or her own security package is just wrong.
>
> Why? I have, have you heard of Peekboo?
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
** 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
******************************
