Cryptography-Digest Digest #686, Volume #10 Sun, 5 Dec 99 16:13:02 EST
Contents:
MMPC - A multi-message encryption algorithm (Jim Shapiro)
Re: NSA should do a cryptoanalysis of AES (Vernon Schryver)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Tom St Denis)
Re: Peekboo Ideas? >> Oops, problem ... (Tom St Denis)
Re: 1 round Defeats Enigma attacks ("Douglas A. Gwyn")
Re: 1 round Defeats Enigma attacks ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
peekboo (Tom St Denis)
Re: NP-hard Problems ([EMAIL PROTECTED])
Johnson Device ("Kurt Flei�ig")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Wanted: One-way hash sourcecode or algorithm (Mattias Wecksten)
DES ECB vs CBC (Terry Powell)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: cookies (Eric Murray)
Re: Why Aren't Virtual Dice Adequate? ([EMAIL PROTECTED])
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim Shapiro)
Subject: MMPC - A multi-message encryption algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sun, 05 Dec 1999 17:13:19 GMT
We have published an unusual encryption algorithm, MMPC, in the
December issue of Doctor Dobb's Journal. MMPC stands for
multi-message package chaffing. This encryption scheme combines the
all-or-nothing transform with Ron Rivest's winnowing-chaffing scheme.
MMPC features,
1. a level of security that can be chosen by the user, as it only
requires any keyed message authentication code (HMAC), and
2, a package tranform which guarantees that the receiver cannot read
_any_ of the message unless she can read _all_ of it, and
3. most importantly, the ability to intertwine any number of unrelated
messages in such a way that a recipient can only read the sub-message
for which she has a key.
By insertion of pseudo-random bytes, no one save for the sender knows
how many sub-messages are contained in a transmission.
If you are interested in code you can download it from the Dobbs site,
www.ddj.com, or from mine, www.jimshapiro.com . You will need the gcc
compiler to build the encryption/decryption programs. Included is a
makefile and a perl script to test the code.
To contact me directly remove CRYPT from my e-mail address.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 5 Dec 1999 09:27:47 -0700
In article <[EMAIL PROTECTED]>, Brian Chase <[EMAIL PROTECTED]> wrote:
>Speaking on matters of paranoia, my particular paranoid tendencies seem to
>note that Microsoft hires up quite a few of the computing history greats.
>I don't really see that they're making use of this talent as is evidenced
>by the really horrible quality products Microsoft puts out. The only
>conclusion I've been able to reach is that Microsoft hires these people to
>keep them off the market, doing otherwise productive work which might
>compete with Microsoft interests.
> ...
I very much doubt Microsoft has any such intentions. I'm sure they hire
big names for the same reasons anyone else would hire them. One trouble
is that big names have generally been in the business for a bunch of years,
and have long since stopped writing any code or doing more than talking
(including sometimes teaching). Big names, like everyone else, tend to
retire on the job, or at least get promoted into management, consulting,
or figure-heading. Anyone who's been in the business for a while has met
plenty of people famous for good work but who have have done nothing but
make wind for 10 years and show no current signs of being able to do
anything but make more wind.
Even if you haven't retired on the job or received the management lobotomy,
you cannot change a corporate culture by merely talking. Even writing
code and leading by example can only affect your immediate colleagues.
Bill Gates has been quoted as saying that Microsoft managers are so smart
that they are as expert on everything that their underlings are doing as
the underlings. That's a complete explanation for Microsoft's schedule
problems, consistently bad designs, its bloated, garbage code, and
incredible provincialism. If everyone you hire is no smarter than you
are, and your organization has N layers, then the people in the trenches
will be about 2**-N as smart as you. Thus, if Gates has an I.Q. of 250
and Microsoft has only 5 layers of management, the people actually doing
the work have single-digit effective I.Q's. Even if they would be smart
elsewhere, they'll function like oysters or barnacles there. Planting a
few big name geniuses in the oyster beds won't change the nature of the
organization, but it can ruin the geniuses, by making them mere windbags.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo >> How to verify that promised
algorithms are included
Date: Sun, 05 Dec 1999 17:52:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dmitriy Morozov) wrote:
> Well, there is a little problem. I downloaded the source code offered
on the
> web site. First of all, the name was kind of strange (pb_backup.zip)
but that's
> Ok. The main question is why does readme file included in the archive
say
> Peekboo V1.3. The only explanation (logical explanation) would be
that the
> source is for version 1.3. But then that means that what you see is
NOT what
> you get. More of that according to the site the encrypted files
produced by the
> version 1.70 and earlier are not compatible with later versions; so
even if you
> are successful in compiling the code (which I wasn't - though I
didn't try very
> hard) what you get won't be the executable you can download, more of
that even
> the encrypted files won't be compatible with the ones produced by
> the executable.
That readme file is seriously out of date, the current source on the
website is 1.73 [ i just checked ].
> And that's where my problem with Peekboo arises. There does not seem
to be a
> concept behind it. No structure... The files that were produced by
versions <=
> 1.70 are not compatible with the ones produced by those > 1.70. The
question
> arises how well are things "thought through", is it possible that in
the future
> another incompatibility will be introduced (to add something else).
If Tom has
> message format and any idea of what might be added and how
compatibility will
> be preserved in future versions (and I'm pretty sure he does, at
least I would
> expect it to be so), then in my opinion it would be logical to
publish it (on
> the web site), and if he doesn't then there is no point in hoping for
a big
> future for this program.
>
> And that's where the main thing that I cannot understand comes. Ok, I
see an
> idea behind it: make your own cryptographic application, make it
small so it
> would be easy to use and transport - and that's fine and actually
kinda
> interesting, but the question is why can't one make it, for example,
OpenPGP
> compatible. Not the whole thing, some of the things required for
peekboo are
> not defined there (though there are plenty of numbers-identifiers
reserved for
> your own "algorithms"), but at least some of the things could be
compatible.
> Most of the things/structures needed for peekboo are defined in
OpenPGP, most
> of those things are checked, and thought through by many people. The
advantages
> seem to be obvious to me, I don't really see disadvantages. Any
comments
> (especially, from Tom himself)?
Well I agree that since I am getting more users I should attempt to be
more backwards compatible. I would appreciate help documenting and
revising the message/file formats. The file format for example changed
in 1.71 because I didn't have the code ready to implement it properly.
I will however ensure that the v2 release is fully backwards compatible
with files and messages made in 1.73.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Peekboo Ideas? >> Oops, problem ...
Date: Sun, 05 Dec 1999 18:03:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Oops, problem ...
>
> Program will allow to copy public key to private key box as the
beginning.
>
> Next user is able to create share pair that will contain public +
public keys.
> Next use can use the faulty share [ public + public keys ] to encrypt
but
> decrypting can not be done.
>
> Prevent mismatch of copy operation.
Okey dokey, diffie-hellman works by using a shared and private key
components. The same is true for my implementation of DH. I use the
two keys to create a shared key. Then for each message/file a random
salt is appened, the glob is hashed downto 160bits which forms the
session key. Thus you can't simply use my public key since you can't
create a shared key.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1 round Defeats Enigma attacks
Date: Sun, 05 Dec 1999 18:20:04 GMT
UBCHI2 wrote:
> Presumably tranposition would really strengthen those.
The transposition would either be static, in which case you have
to assume that eventually the cryptanalyst will know it, or keyed,
which introduces more opportunity for attack on the key distribution
system. The question is whether the additional key is better
utilized in the underlying (rotor) system or in the proposed added
(transposition) layer. Often, the answer is, the former.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1 round Defeats Enigma attacks
Date: Sun, 05 Dec 1999 18:22:34 GMT
JTong1995 wrote:
> Bauer, in his book, Decrypted Secrets, predicts that in the future,
> transpositions will become the dominant method of encryption
> because of it's strength against the brute force attack...
Since brute-force attack is hardly ever used against real systems,
that seems to be a misguided argument.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sun, 05 Dec 1999 18:27:23 GMT
Sander Vesik wrote:
> For starter, consider Pearl Habor.
What about Pearl Harbor?
> You are also forgetting that 'law enforcment' backdoors in banking
> software have been criminally exploited before.
What "law enforcement" backdoors in banking software?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sun, 05 Dec 1999 18:33:04 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Precompression is meant to foil more sophisticated cryptanalytic
> attacks by reducing the statistical clues that might otherwise
> "shine through" the encryption. But the fact is most compression
> schemes leak so much information that they may be opening up
> more weakness than they hid.
Except for the obvious case where a highly predictable "header"
gives one (in effect) known plaintext, that claim seems counter-
intuitive. Compression removes a *lot* of redundancy. Could
you give a specific example of this information "leakage"?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: peekboo
Date: Sun, 05 Dec 1999 18:25:49 GMT
Well I am still offline [at a friends house now] but if you want to
compile your list of flames/praises about peekboo to
[EMAIL PROTECTED] I will reply to this group when I get back on.
Tom
http://www.cell2000.net/security/peekboo/index.html
[btw the readme.txt in the pb_backup.zip is way out of date]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NP-hard Problems
Date: Sun, 05 Dec 1999 18:59:53 GMT
David A Molnar wrote:
[...]
> From what I understand :
>
> When we say that a problem P is "NP-hard", we mean that
>
> a) we have a decision problem P defined with respect to some language
of
> strings L. That is, we have an alphabet $\Sigma$ and a string
> $s \in \Sigma^*$ -- a string $s$ consisting of some concatenation
> of symbols in the alphabet and of unbounded length -- and we are
> asking the question "Is the string s in the language L??"
>
> b) an efficient reduction exists from this problem over L to every
other
> decision problem P' for an NP-language L'. Let's expand on what
> that means :
>
> a "reduction" is a process for rewriting problem questions
> for one problem in terms of those for another problem.
> In this case, we want something which will let me
> take a query for a problem P'
>
> (1) "Is this string s in L' ??"
>
> and `reformat' it such that I can create a new string
> and new query like so
>
> (2) "Is this string f(s) in L ??"
>
> (f being some rewriting process or function)
>
> and knowing the answer to query (2) will give me
> the answer to query (1).
>
> Put another way - say I know how to solve (2). So I figure
> out how to use it to solve (1). What I "do to figure it
> out" can be identified with a "reduction."
I almost entirely agree with David. But...
There is a somewhat subtle distinction between
language reduction and more general problem
reduction. The description above seems to mix
the two. It states a stronger condition than
problem reduction in that it requires each
problem to be that of deciding some language,
but a weaker condition than language reduction.
If the function f is a reduction from language
A to language B, then the answer to "is f(s) in
B" not only gives us the answer to "is s in A",
but _is_ that answer. We are not allowed to
flip the yes/no outcome.
The distinction is significant in many cases,
including defining NP. If we were allowed to
"flip the answer" then we could immediately
reduce any language to its complement. The
distinction between NP and co-NP would be
lost.
References differ as to whether NP-hard is a
set of languages versus a set of more general
computational problems. The /Handbook of
Applied Cryptography/ defines it as a set of
problems, and thus reductions are in the
sense that we can in polynomial time turn the
answer to the NP-hard problem into the answer
to an NP complete problem. /Introduction to
Algorithms/ by Cormen, Leiserson and Rivest
defines NP-hard as a set of languages, and
requires a language reduction from any member
of NP to each NP-hard language.
So the subtle point on which I disagree with
David's understanding is that I don't think
it makes sense to cross the two - to define
NP-hard only in terms of language recognition
but allow the more general form of reduction.
People who find such subtle points interesting
might enjoy the following trivia question:
Name a language that,
1) is known to be in NP, and
2) is known not to be NP-complete.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Kurt Flei�ig" <[EMAIL PROTECTED]>
Subject: Johnson Device
Date: Sun, 5 Dec 1999 15:44:52 +0100
Sorry,
does anybody use an hadrware device to obtain from the thermodynamic
Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
one-time-pad encryption?
Thanks a lot!
K
Scusate,
qualcuno di voi ha mai fatto uso di un certo dispositivo per sfruttare
l'effetto termodinamico Johnson della scheda audio al fine di avere grossi
flussi di bit casuli da utilizzare con un cifrario one-time-pad?
Grazie
K
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sun, 5 Dec 1999 11:23:53 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
: [EMAIL PROTECTED] (r.e.s.) wrote:
: >It would be smart of him not to, but the scenario asked about
: >earlier in the thread, and the only one I've been discussing
: >in this exchange, is one in which he does so (perhaps through
: >some trickery by an agent?).
:
: Great. You found a scenario where an OTP plus a really stupid user
^^^^^^^^^
That's very funny! *You* wrote:
<<< Good info! I have a clueless newbie question about something
<<< that I found
^^^^^^^
<snip description of the scenario I *thought* we were discussing>
: allows a forged message. [...]
: There exists no topic police to force everyone into the
: limited scenario you have chosen as the "official" topic
^^^
(A good laugh!)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Mattias Wecksten <[EMAIL PROTECTED]>
Subject: Wanted: One-way hash sourcecode or algorithm
Date: Sun, 05 Dec 1999 20:53:50 +0100
I am searching for a one way hash source or algorithm.
Any information appreciated.
M WxX
------------------------------
From: Terry Powell <[EMAIL PROTECTED]>
Subject: DES ECB vs CBC
Date: Sun, 05 Dec 1999 15:19:36 -0500
Reply-To: [EMAIL PROTECTED]
I was wondering if anyone could help me with this problem.
I've working on adding DES encryption to a wireless system. Messages
transmitted on this system are generally short, 1 to 256 blocks. A lot
of the messages are state-of-heath messages from the system thus there
will be a lot of repitition in the plaintext data. My approach has been
to use DES in CBC mode and transmit a 64 bit IV ahead of the encrypted
message. There has been some debate over using CBC mode in this system.
The main objection is the addition of the IV.
The alternative design presented to me is DES using EBC mode an placing
a varying sequence number in the plaintext. The proponents of this mode
state that it is just as secure as CBC with a plaintext IV (some claim
it to be "equivelent").
I'm having trouble buying their argument. I can understand that adding
the sequence to the plaintext in EBC mode enhances that mode's security,
but it seems to me that every block in a message would need to treated
in this manner to keep it secure. I just don't see how this can be a
"better" approach.
I'm I wrong about this?
Thanks in advance for any advice.
Terry Powell
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Dec 1999 20:20:46 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Whereas your position appears to be based on faith in the existence of
:> genuine randomness in subatomic behaviour, and in our ability to
:> magnify this up to a macroscopic scale, without distorting it at all.
: Do you know about SQUIDs? Photomultipliers? Etc.?
: Why are you wasting bandwidth arguing about quantum effects
: when you don't understand the subject? Go learn it first!
It seems to be necessary - since some people seem to have the idea that
a one-time pad is a realisable system.
Without a source of genuinely random numbers a one-time pad falls short of
theoretical perfection - and unfortunately, no source of demonstrably
genuinely random numbers is - or IMO is ever likely to be - known to
mankind.
Even if you believe that SQUIDs or photomultipliers are capable of
magnifying quantum events to a macroscopic scale without possibly
introducing any interference from other sources, I would love to
hear an explanation of how they could conceivably do this.
Alternatively, should you have a demonstration that quantum events are
themselves genuinely random, I would be delighted to hear that as well.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
*If* /you/ copy this "tagline virus" *please* mutate it!
------------------------------
Subject: Re: cookies
From: [EMAIL PROTECTED] (Eric Murray)
Date: 5 Dec 1999 12:33:41 -0800
In article <Pine.LNX.4.04.9912031304560.17276-100000@shell>,
E-mail <[EMAIL PROTECTED]> wrote:
>
>
>Many web sites are pretty insistent about taking cookies. Why?
>
>I am suspicious about it because I see it as violation of privacy
>and possibly a means of breaking into data not mentioned in the
>reasons they give.
Cookies are bits of data that the web server can put onto the browser's
host. The server placing the cookie can set restrictions on which
servers can access the cookie. They usually limit access to servers
in the same domain. Go look at the cookies file on your host.
The problem with cookies is that they can be used to track your
web page views. Many web pages have links to services such
as Doubleclick, who use the cookie that they place on your machine
as an ID and the Referrer field to track what sites you have gone to
in order to target advertising at you. Cookies can also hold
encrypted info (i.e. ordering info), and if the server which did the
encryption picked a poor key or made one of a hundred other
implementation errors which readers of this newsgroup are
familiar, the encrypted data could be read by someone other
than the intended recipient.
Cookies are an annoyance rather than a security risk... mostly
because there are much worse security holes in browsers and operating
systems and business procedures.
Eric Schmidt's assertion of his credit card info being stolen using
cookies is interesting, but I think that it's unlikely to have happened
that way and would want to see an analysis from someone technical(:-)
before I beleive that cookies really did the deed.
I have written a proxy which filters cookies, controls the HTTP
headers which your browser sends, and can be configured
to block advertising. http://www.lne.com/ericm/cookie_jar/
--
Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sun, 05 Dec 1999 20:30:05 GMT
[EMAIL PROTECTED] wrote:
> This is a well known and much discussed "weakness" of a one-time-pad.
>
> A properly used OTP "absolutely" prevents the enemy from determining
> the cleartext from the cyphertext by cryptographic means. It doesn't
> "absolutely" prevent him from sending a false message that looks
> real.
[...]
> I wonder if there's something analagous to an OTP that will provide
> the same degree of "absolute" protection from "spoofing" as OTP
> does from "breaking".
Yes, if you mean "absolute" in the sense that
authentication is provable, even against a
computationally unbounded attacker. Cryptographic
Authentication is always probabilistic: the
attacker might guess a correct signature. The
mechanism allows us to make the probability of
successful forgery arbitrarily close to zero.
To achieve what we might call "perfect
authentication" we use a one-time, uniformly
distributed key - just as we use for secrecy, and a
"universal hash function", which is actually a kind
of MAC because its inputs are a message and a key.
Let's call our message space M, our key space K,
and our signature space S. A universal hash
function is a function s=f(m,k) where m is in M, k
in K and s in S, such that for any two messages m1
and m2 in M, the number of keys k in K such that
f(m1,k) = f(m2,k) is exactly |K|/|S|.
Given such a function and assuming k is chosen
independently for each message in such a way that
each element of K is equally likely, the
probability of one attempted forgery containing the
correct signature is at most 1/|S|.
There are, as always, possible implementation
errors that could violate the assumptions upon
which security rests. For example, we would not
want to use the same shared keystream for privacy
and authentication. An attacker might intercept
and block a message containing known plaintext,
compute the privacy key and use it to properly
encrypt and sign a shorter message of his choosing.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 05 Dec 1999 15:59:56 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
r.e.s. wrote:
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
> [...]
> : The sender is using up his pad as he enciphers the message to
> : each recipient. To authenticate each message he appends a signature
> : to each plaintext. The signature can be any shared secret. The S
> : (signature size) bits of pad following the portion just consumed will
> : suffice. The sender enciphers the signature as part of the plaintext.
> : On receipt of the message the receiver deciphers the plaintext normally,
> : and compares the last S bits of the message to the next S bits of pad.
> : If they match the message is authentic.
> :
> : Pad usage is identical at both ends: P bits for the plaintext and 2*S
> : bits for the signature.
>
> Under discussion is a scenario in which *identical* plaintext is sent
> to two different recipients (perhaps through trickery by an agent).
> What you describe adds a unique signature to the plaintext, so it is
> not of this kind.
>
> Also, incorporating additional ingredients such as a "shared secret",
> is a nice example of what I was calling the "strengtheneing" of a
> "pure OTP alone".
You may understand the terminology you are using, but I, and apparently
others, do not. The phrase "strengthening and OTP" rings false on the ears
because the strength of an OTP is maximal for systems where PT size == CT
size. It cannot be made stronger. Of course this describes the strength of
the protection of the plaintext. If you add in authentication as a strength
parameter, you confuse two distinct issues.
Now in another recent thread I was contradicted for using terminology in a
non-standard way. In that case I was trying to use the terminology of the
person to/at whom I was aiming my replies. In this case, I believe the
terminology issue needs to be handled carefully or similar arguments will
arise.
------------------------------
Date: Sun, 05 Dec 1999 16:06:23 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Vernon Schryver wrote:
> In article <[EMAIL PROTECTED]>, Brian Chase <[EMAIL PROTECTED]> wrote:
>
> >Speaking on matters of paranoia, my particular paranoid tendencies seem to
> >note that Microsoft hires up quite a few of the computing history greats.
> >I don't really see that they're making use of this talent as is evidenced
> >by the really horrible quality products Microsoft puts out. The only
> >conclusion I've been able to reach is that Microsoft hires these people to
> >keep them off the market, doing otherwise productive work which might
> >compete with Microsoft interests.
> > ...
>
> I very much doubt Microsoft has any such intentions. I'm sure they hire
> big names for the same reasons anyone else would hire them. One trouble
> is that big names have generally been in the business for a bunch of years,
> and have long since stopped writing any code or doing more than talking
> (including sometimes teaching). Big names, like everyone else, tend to
> retire on the job, or at least get promoted into management, consulting,
> or figure-heading. Anyone who's been in the business for a while has met
> plenty of people famous for good work but who have have done nothing but
> make wind for 10 years and show no current signs of being able to do
> anything but make more wind.
>
> Even if you haven't retired on the job or received the management lobotomy,
> you cannot change a corporate culture by merely talking. Even writing
> code and leading by example can only affect your immediate colleagues.
>
> Bill Gates has been quoted as saying that Microsoft managers are so smart
> that they are as expert on everything that their underlings are doing as
> the underlings. That's a complete explanation for Microsoft's schedule
> problems, consistently bad designs, its bloated, garbage code, and
> incredible provincialism. If everyone you hire is no smarter than you
> are, and your organization has N layers, then the people in the trenches
> will be about 2**-N as smart as you. Thus, if Gates has an I.Q. of 250
> and Microsoft has only 5 layers of management, the people actually doing
> the work have single-digit effective I.Q's. Even if they would be smart
> elsewhere, they'll function like oysters or barnacles there. Planting a
> few big name geniuses in the oyster beds won't change the nature of the
> organization, but it can ruin the geniuses, by making them mere windbags.
Your formula does not match my experience. The relative effective IQ of
supervisor:supervisee is not 2:1, but W:1 where W is the width of the local
organization measured by direct reports. So your estimate is extremely generous
in comparison.
------------------------------
** 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
******************************
