Dynamic change of encryption keys
Mok-Kong Shen
Hi,
It seems intuitively clear that it may be beneficial to limit the
volume of materials encrpyted with the same key in encryptions. For,
even if the encryption algorithm is entirely safe, there could be
loss or chance revelation of the key (by Murphy's Law), if the same
key is repeated employed over a very long time period. When the amount
processed by a particular key is limited, the eventual disaster would
be correspondingly limited.
I suppose one could envisage two types of change of keys. The one
is to have a hierachy of keys, say, with a master key that generates
the key to be used for a year, which generates a key to be used for
a month etc. etc. (through encrypting the time involved together with
eventually some clear/secret information) till one gets a key for a
given message. The other is to have dynamic change of the key during
the time a message is being processed. For a block encryption one may
use the message key to encrypt (using the same or a different encryption
algorithm) the block number to obtain a key to do the proper encryption
of the block. One need not change the key for every block but can also
let the key be changed every n blocks or else depending on some runtime
information (e.g. when the last few bits of the previous plaintext block
has a certain value). Of course, such dynamic change of keys entails
an additional computing cost as well as processing time. However, since
hardware becomes ever faster and cheaper, I believe that, with the
exception of the case where an extremely high volume of materials
is to be processed, the potential benefit of dynamic change of keys
could be justified in a large number of current practical applications
where encryption is really essential.
Thanks,
M. K. Shen
Joseph Ashwood
news:hdmm87$iq9$02$1...@news.t-online.com...
> It seems intuitively clear that it may be beneficial to limit the
> volume of materials encrpyted with the same key in encryptions.
Yes it does, in fact this has been standard for many years. So much so that
the latest problem in SSL/TLS is in the change over.
Joe
Mok-Kong Shen
> "Mok-Kong Shen" wrote:
>
>> It seems intuitively clear that it may be beneficial to limit the
>> volume of materials encrpyted with the same key in encryptions.
>
> Yes it does, in fact this has been standard for many years. So much so
> that the latest problem in SSL/TLS is in the change over.
Thank you for the very valuable information.
If my layman's understanding is not wrong, attacks of the genre of the
recent attempt on AES (see the link I gave on the paper of A. Biryukov
et al.) could be 'practically' well defended through appropriate dynamic
change of encryption keys. Such attacks are all scientifically genious
and very sophisticated, but it seems interesting to note that counter
measures could on the other hand be rather simple and primitive, though
at some -- in many practical cases tolerable in my view -- cost (there
is no free lunch, of course).
M. K. Shen
Joseph Ashwood
"Mok-Kong Shen" <mok-ko...@t-online.de> wrote in message
news:hdop0m$hi2$02$1...@news.t-online.com...
> Joseph Ashwood wrote:
>> "Mok-Kong Shen" wrote:
>>> It seems intuitively clear that it may be beneficial to limit the
>>> volume of materials encrpyted with the same key in encryptions.
>>
>> Yes it does, in fact this has been standard for many years. So much so
>> that the latest problem in SSL/TLS is in the change over.
> If my layman's understanding is not wrong, attacks of the genre of the
> recent attempt on AES ... could be 'practically' well defended through
> appropriate dynamic
> change of encryption keys. Such attacks are all scientifically genious
> and very sophisticated, but it seems interesting to note that counter
> measures could on the other hand be rather simple and primitive, though
> at some -- in many practical cases tolerable in my view -- cost (there
> is no free lunch, of course).
In some ways, yes. You seem to have missed the more important part of the
statement. While key rollover certainly limits the text available to mount
an attack, instead the weak point can very easily become rollover phase.
That is why I specifically brought up the SSL/TLS attack, the weakness has
nothing to do with exceeding the acceptable limits of security for the
cipher, but the rollover itself had weaknesses. So while properly used
rollovers do prevent some types of attack, they also open up additional
vectors for attack and as such "simple and primitive" methods of performing
the rollover will themselves form weaknesses.
Joe
Mok-Kong Shen
I must admit my poor knowledge (I am a layman) in having apparently
not correctly understood what you meant. Did you mean that, if one
uses a sequence of keys K_i (i=0,1,....), there may be correlations
between these that could be exploited, since they are generated by
a PRNG? But firstly, the analyst has to first of all recover a number
of these keys, before he could exploit that (which means that his work
is multiplied by that factor). Secondly, to recover each one key he
has only one single pair of plaintext and ciphertext to work on
(assuming he is in this favourable situation) instead of the fairly
large number of pairs commonly assumed by the various attacks (which
means that his chance of success is almost negligible). Thirdly, the
PRNG used could be one that is rather hard to predict (cf. my recent
thread "Rendering prediction of congruential random number generators
hard"). But, as said, I might have gravely misunderstood you, in which
case please be kind enough to explain your points in terms easier for
me to capture.
Thanks,
M. K. Shen