John,
Why would you suggest that I may have a disregard for math and the
scientific method? Nothing could be further from the truth. Unfortunately I
could not express my profound regard for both without making it too wordy
or personal.
I've never suggested that the call for public disclosure of encryption
algorithms was "just marketing". I pointed out that the primary motivation
was financial gain and the gain of market share. And that the ridicule of
the notion of "security by obscurity" was an example of "marketing".
You appear to be re-framing what I said in a way that would discredit me.
There wouldn't be a "repository of encryption keys".
The call for public disclosure of encryption algorithms is based on the
premise of having "lengthy" keys. Of course they are stored - they are too
long to remember. And it's common to store them in a repository such as a
certificate store.
The cryptosystems under discussion would use randomized keys.
Randomized keys reinforces my point about the need to store them in a
repository because random keys are hard to remember.
The keys and randomizer are *supposed* to be the weakest links in the
chain. The algorithm itself should
ideally be unassailable without the key.)
Are you suggesting that publicly disclosed algorithms are unassailable?
That would be an oxymoron - no need to "assail" an algorithm that is
already publicly known. Wouldn't the point of "assailing" an algorithm be
to discover it?
And you appear to misunderstand the role of the key - which is to modify
values computed by the algorithm to make them "appear" more random.
Mathematically speaking, the algorithm's sole purpose is to prevent
*anyone* without
the key from accessing the data it's protecting.
That statement isn't very clear. I'd suggest that the purpose of the
algorithm is to obscure data, and to do it in a way that appears random
(indecipherable). Both algorithm and key play a role in making the process
and results "appear" to be random.
If I don't have the key, then I don't have the data. That's the algorithm
doing its
job. That's the whole definition of "secure algorithm".
Again, my definition of a "secure algorithm", would be one which makes both
the algorithm and the results of passing "clear data" through the process
to "appear" random.
An example of an insecure algorithm would be, say one which increments each
byte to the next in the character set - so that say "A" would be changed to
"B". That would be insecure, because the pattern becomes clear as you test
and analyze it.
A lot of folks are more comfortable with *open source*
implementations.
I haven't done a lot of research on open-source algorithms. My gut-feel is
that most implementation of "published" algorithms are closed-source. So
even with a publicly disclose algorithm, the actual implementations do not
include source.
"The desire of some people to have and rely on public algorithms isn't
logical fallacy.
I never suggested it was. Logical fallacies are tricks people use to gain
advantage in a debate. I shared a reference to examples.
"The call for public algorithms is a manifestation of rational
people's natural desire for verification and proof."
Again, my suggestion for verification and proof would be for analysts (i.e.
hackers) to use tools which test the strength of algorithms, by feeding
various keys, and data to them, to see if the tools reveal patterns which
would enable them to discover the algorithm. If the algorithms are
impossible to discover, then pronounce them "strong".
One valid concern with publicly disclosed algorithms is that they all rely
on "lengthy" keys to make data to appear randomly generated - the
"strength" is said to be in the length and randomness of the key.
The problem is that you have to store the keys somewhere, which is a
violation of Kerckhoff's third tenet. That shifts the attack surface from
trying to break the algorithm, and trying to break the key, to trying to
discover the password to where they keys are stored, which is much easier
to break.
midrange.com
