Prev: Mark-Up Cryptography or Encapsulation Cryptography.
Next: A Randomness Hypothesis.
From: Mok-Kong Shen on 1 May 2010 10:24

I like to solicit (via expressing my own humble opinions) some
discussion on the general benefits, as well as optimal ways, of
introducing dynamics into encryption processing. For, in my personal
conviction, plenty of issues hitherto or potentially encumbering the
security of encryption processing in general could be "fundamentally"
avoided, if, instead of the conventional commonly employed static
schemes of encryption, one employs ones that appropriately (more or
less) varies as the processing proceeds.

Previously in the thread "Introducing dynamics into block encryptions"
(02.03.2010) I argued that the general menaces faced by block encryption
algorithms stemming from eventual future significant progresses in
researches on differential analysis, algebraic analysis, etc. etc.
could be "trivially" avoided (though generally with some concomitant
additional computational cost) via dynamically modifying some details
of encryption processing from block to block. One modification that is
clearly safe (i.e. evidently without adverse effects on security) is
simply to use a different key for each different block being processed.
This can be done e.g. by using a block algorithm in CTR mode to
generate from a given message key the (different) keys needed for the
proper encryption of the individual blocks of plaintext. IMHO the
computational overhead thus ensued should be tolerable in most
practical applications, particularly in view of the constant
advancement of hardware technology with the consequent trend of ever
cheaper processing power.

Analogously, dynamics could be introduced into stream encryptions. One
can namely generate from a PRNG that is based on a given message key a
large number of PRNGs to be pseudo-randomly activated in sequence (see
the thread "Update of my old idea on random number generation" of
20.03.2010) or even continuously generate new PRNGs on the fly for the
actual encryption processing need (e.g. processing each computer word).

Note that in the above all the dynamics is stated to be stemming from
a given message key (rather than from a fixed key that is
conventionally often used for processing a sizably large number of
different messages or even quasi permanently used). I consider this
dynamics of using different message keys to process different
messages to be a very critical and essential ingredient of the entire
idea of introducing dynamics into encryption processing. In my humble
view, use of unique message keys essentially diminishes, among others,
the menaces stemming from chosen-plaintext attacks (one of the three
basic classes of attacks). For, in the (worst) scenario where the
opponent could submit plaintexts of his own choice to get processed,
his plaintexts will in our dynamic schemes be encrypted by message keys
that are all different from those used for processing the genuine
plaintexts of the communication partners. Consequently, the ciphertexts
he obtains from the chosen-plaintexts would be barely useful for the
analysis of the genuine ciphertexts (this the more so in the context of
dynamics "during" the processing of any single message as depicted
above). The different message keys required could be generated from a
master-key (which may remain constant for a longer period) together
with some time-varying information that is unique for each message,
e.g. time and message number. In particular, one can use the master-key
to encrypt the time-varying information with a block algorithm to
result in the message key. Alternatively, the master-key and the
time-varying information can be combined in an appropriate way for
building a PRNG which generates the message key.

For an objective vivid discussion on the topic as well as some comments
and critiques on my humble points I should be very grateful.

M. K. Shen
From: adacrypt on 1 May 2010 14:14
On May 1, 3:24 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> I like to solicit (via expressing my own humble opinions) some
> discussion on the general benefits, as well as optimal ways, of
> introducing dynamics into encryption processing. For, in my personal
> conviction, plenty of issues hitherto or potentially encumbering the
> security of encryption processing in general could be "fundamentally"
> avoided, if, instead of the conventional commonly employed static
> schemes of encryption, one employs ones that appropriately (more or
> less) varies as the processing proceeds.
>
> Previously in the thread "Introducing dynamics into block encryptions"
> (02.03.2010) I argued that the general menaces faced by block encryption
> algorithms stemming from eventual future significant progresses in
> researches on differential analysis, algebraic analysis, etc. etc.
> could be "trivially" avoided (though generally with some concomitant
> additional computational cost) via dynamically modifying some details
> of encryption processing from block to block. One modification that is
> clearly safe (i.e. evidently without adverse effects on security) is
> simply to use a different key for each different block being processed.
> This can be done e.g. by using a block algorithm in CTR mode to
> generate from a given message key the (different) keys needed for the
> proper encryption of the individual blocks of plaintext. IMHO the
> computational overhead thus ensued should be tolerable in most
> practical applications, particularly in view of the constant
> advancement of hardware technology with the consequent trend of ever
> cheaper processing power.
>
> Analogously, dynamics could be introduced into stream encryptions. One
> can namely generate from a PRNG that is based on a given message key a
> large number of PRNGs to be pseudo-randomly activated in sequence (see
> the thread "Update of my old idea on random number generation" of
> 20.03.2010) or even continuously generate new PRNGs on the fly for the
> actual encryption processing need (e.g. processing each computer word).
>
> Note that in the above all the dynamics is stated to be stemming from
> a given message key (rather than from a fixed key that is
> conventionally often used for processing a sizably large number of
> different messages or even quasi permanently used). I consider this
> dynamics of using different message keys to process different
> messages to be a very critical and essential ingredient of the entire
> idea of introducing dynamics into encryption processing. In my humble
> view, use of unique message keys essentially diminishes, among others,
> the menaces stemming from chosen-plaintext attacks (one of the three
> basic classes of attacks). For, in the (worst) scenario where the
> opponent could submit plaintexts of his own choice to get processed,
> his plaintexts will in our dynamic schemes be encrypted by message keys
> that are all different from those used for processing the genuine
> plaintexts of the communication partners. Consequently, the ciphertexts
> he obtains from the chosen-plaintexts would be barely useful for the
> analysis of the genuine ciphertexts (this the more so in the context of
> dynamics "during" the processing of any single message as depicted
> above). The different message keys required could be generated from a
> master-key (which may remain constant for a longer period) together
> with some time-varying information that is unique for each message,
> e.g. time and message number. In particular, one can use the master-key
> to encrypt the time-varying information with a block algorithm to
> result in the message key. Alternatively, the master-key and the
> time-varying information can be combined in an appropriate way for
> building a PRNG which generates the message key.
>
> For an objective vivid discussion on the topic as well as some comments
> and critiques on my humble points I should be very grateful.
>
> M. K. Shen

Hi,

> instead of the conventional commonly employed static
>schemes of encryption, one employs ones that appropriately (more or
>less) varies as the processing proceeds.

This is good thinking in my view - I applaud it since I am doing it
myself also but I think you should forget about PRNG's in any form.
May I suugest something !
Use the equation of motion of a point as your encryption model (this
borrowing scientific dynamics per se from mechanics).
Take the decimal value of the character being instantaneously
enciphered as time 't'.(e.g. P = 80 in ASCII => t = 80 seconds of
elapsed time in motion)

Lets say the equation of motion is x = t*2 i + tj - 2tk.
Substituting in the current value of 't' for whatever character is
being encrypted gives the displacement from (0,0,0) at time 't' after
t=0.

This is a vector obviously. Give this a change of origin ( shared
information between Alice and Bob) and it becomes the ciphertext
( markup - note you well - also, the change of origin is trapdoor
information).

Arrange everything for all items of your message in mutual databases
(that you understand - demonstarted in earlier discussion) and you
have an unbreakable trapdoor (or markup) cipher. That is the
algorithm.

Note several things:
The path of the motion is a skew curve (in passing - not important)
Thia is vector cryptography. It is also markup cryptography. You
could also say it is trapdoor cryptography. It is clearly unbreakable
- underpinned by the change-of-origin.

I hope this is what you mean by intoroducing dynamics into
cryptography - I suspect it is more so literally (i.e from a mechanics
point of view than you intended - maybe you meant dynamics in a
figurative (management) sense ? either way it is sound cryptography.

This suggestion is not meant to be patronising.

Any good?

Good luck - adacrypt
From: Bryan on 1 May 2010 18:11
adacrypt wrote:
Mok-Kong Shen wrote:
> > For, in my personal
> > conviction, plenty of issues hitherto or potentially encumbering the
[...]
> This is good thinking in my view - I applaud it since I am doing it
> myself also but I think

Have you two considered including some base translation?

Imagine the trifecta of the result of Adacrypt, Shen, and Shaw.


--
--Bryan
 | 
Pages: 1
Prev: Mark-Up Cryptography or Encapsulation Cryptography.
Next: A Randomness Hypothesis.