Re: I'm still amused.



On Apr 14, 10:34 pm, WTShaw <lure...@xxxxxxxxx> wrote:
On Apr 14, 3:12 am, adacrypt <austin.oby...@xxxxxxxxxxx> wrote:





On Apr 14, 8:18 am, WTShaw <lure...@xxxxxxxxx> wrote:

I've implemented many varied means for generating permutations to be
keys with certain algorithms.  These utilities can be set to have a
custom default that generates a more or less a peculiar domain of
permutations.  If your correspondent uses the same default key, any
other keys produced by it could be simply exchanged, even perhaps
hidden in plain sight.

The laughable objection was that specific keys might be easier to
remember via a protocol to generate than some standardized series of
all possible keys for a definite set of elements.  So it goes, make it
friendly, useful, and easily made obscure to produce such keys. I see
nothing wrong with that plus great advantage of using such a plan.

The functional code allows more exclusive protocols if desired but as
always, memory busters are self-defeating.  While testing keys, I use
many, some favorites but most too random to recall, even unknown
combinations of key presses. Note that such entries are usually not
true permutations but the function will use any entry in a way to
scramble the current base permutation to produce a specific useable
permutation.

Without an example is this sufficiently descriptive? Something similar
might be made to generate keys of any length of any set where the key
need not even be in a permuted form but a sequence of any elements
allowed.

<I've implemented many varied means for generating permutations to be
<keys with certain algorithms.

These "varied means" can be the basis of a design algorithm (that is
simply the algorithm you speak of) in mutual database technology - it
becomes simply a matter of collecting the keys - storing them ,
providing a scrambling utility that enables new permutations to be
created from the same base set and  the rest is management.

I'm curious to know if you are using the mutual database concept?.

It could be argued that this is the essence of cipher design.

- adacrypt

Key generation can be like a cipher but the idea is to produce merely
an adequate key for another algorithm. Therefore, the end encryption
routine could be keyed by something quite removed from it being rather
obscure but only the key generation part.  Key space should be large
so it could be sliced and diced by many means with the produced keys
all workable with the final encryption algorithm.  (See if I am
getting closer so continue until we are clear with it all.) The keys
woild be indexed by common expressions used in the key generation
routine rather than created separately and awkwardly stored.  It would
be difficult for someone to work otherwise and like trying to cook in
a strange kitchen.- Hide quoted text -

- Show quoted text -

Key generation can be like a cipher but the idea is to produce merely
an adequate key for another algorithm. Therefore, the end encryption
routine could be keyed by something quite removed from it being rather
obscure but only the key generation part.

When the same algorithm does both jobs then the end result is a
theoretically unbreakable cipher - no doubt about this. The keys are
then called sequentially for use by the same algorithm that is now
going to use them. Finding that algorithm can be a bit enigmatic but
you are closer to it than ever before. It is a question of finding a
suitable model that throws up an algorithm - I contend that the search
for models should be concentrated in science and applied mathematics
only and that the use of number models from number theory per se is
futile. Very simply put, it carries too much residual structure in the
ciphertext that is traceable back to the plaintext albeit by difficult
mathematical means but means none the less that the computer does'nt
even feel as a strain. This is real proper crypto research.

What you are saying here is just as profound as any of Kerchoff's
desiderata - it could be stated as an axiom in fact. I have several
ciphers in the locker that were developed on that basis although I
only realise this now long after the event, it was not as clear to me
then as it now is to others. What you are saying here is a very sound
generalisation of a good universal basis for proceeding in research.

Since you talk of slicing and dicing (of arrays of collected keys
presumably) then you must be working on mutual database lines - that
is sine qua non for all future cryptography in my humble view.

- adacrypt
.



Relevant Pages

  • Re: Im still amused.
    ... keys with certain algorithms. ... true permutations but the function will use any entry in a way to ... independent operation to the encryption algorithm that will use it. ...
    (sci.crypt)
  • Re: Im still amused.
    ... keys with certain algorithms. ... true permutations but the function will use any entry in a way to ... an adequate key for another algorithm. ... theoretically unbreakable cipher - no doubt about this. ...
    (sci.crypt)
  • Re: Im still amused.
    ... keys with certain algorithms. ... true permutations but the function will use any entry in a way to ... an adequate key for another algorithm. ... theoretically unbreakable cipher - no doubt about this. ...
    (sci.crypt)
  • Re: commutative property of algorithms
    ... different keys to be the same length to be communicative and others ... one algorithm could build on the other. ... best and worst and exceptions to and reasons for ... The ciphertext groups are merely ...
    (sci.crypt)
  • Re: Im still amused.
    ... keys with certain algorithms. ... true permutations but the function will use any entry in a way to ... an adequate key for another algorithm. ... Wikipedia points out that in The Codebreakers, David Kahn writes: "Few false ideas have more firmly gripped the minds of so many intelligent men than the one that, if they just tried, they could invent a cipher that no one could break." ...
    (sci.crypt)