Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen <mokkong.shen@xxxxxxxxxxx>
 Date: Fri, 20 Aug 2010 17:11:35 +0200
Tran Ngoc Duong wrote:
It is our view (yours and mine) that a PRNG is either secure or not. But
in Mok Kong Shen's view there are semisecure (or 25%secure,
20%secure, 10%secure etc) PRNGs that if 2N (or 4N, 5N, 10N etc) key
stream blocks is used to encrypt N plaintext blocks, it could be 100%
secure.
Thank you for pointing out the direction that I am thinking. It could be
said that that's a thought akin to that underlying the fact that (at
least in Germany) most outgoing doors of houses/appartments have two
locks. (Why 2, if 1 is o.k.)? Now I suppose it is true that perfect
security (in the absolute sense) is not obtainable in practice.
Radioactive decay may give rise to an extremely good approximation of
the theoretical OTP, but it is albeit an approximation. In real life,
it is also never required to have perfect security. If a message
couldn't be decrpyted within a certain corresponding sufficiently long
time by the corresponding circle of attackers, that's o.k., isn't it?
So for reasons of economy etc. we have to try to trade cost/effort
against security and need not in all cases apply the "best" crypto.
(And is there an upper limit for the "best"?) The common block
algorithms are complicated for implementation in my view. The way (or
the one I could see) to obtain simple algorithms is to introduce
dynamics instead of employing fixed/static ones like AES. (Even using
dynamically generated keys for the static block encryption algorithms,
as I argued in other threads, would so to say knock the bottom out of
the wellknown analysis techniques such as differential analysis,
algebraic analysis, etc.) Now a simple means to get dynamics is to use
PRNGs and the simplest type IMHO is the congruential PRNG. But a
congruential PRNG is easily broken with knownplaintext. So I tried to
use 2 of them for xoring and also exploit mutual rotations to get a
compound PRNG, that should be better from common sense. But the
security of this is presumably yet rather questionable. Thus I would
need to do something more. Now to achieve the avalanche effect to some
extent, though certainly not as fine as the established block
algorithms, I found that matrix multiplication (as in Hill cipher but
with dynamically generated matrices) is the simplest and cheapest way
to go. In that case I was very happy to find that I can
"simultaneously" manage to introduce a factor of indeterminancy of 4
(in the modified version of the scheme) which is a very nice companion
to the factor of indeterminancy of 2 in the compound PRNG. In short,
with these two (in my humble view sufficiently ample) factors of
interminancy, I am feeling a 'practical' sense of security of the
scheme. Certainly this all is heuristic thinking or feeling of the
gut and nothing of the nature of rigorous math proofs. I firmly
believe however that in a sufficiently large part of "practical"
applications it is highly likely that rigorous proofs are not
necessary (if such are possible at all).
I like also to take this opportunity to refer to the issue over which
we argued in a neighbouring branch of the tree of this thread. A long
time I misunderstood you, because I was only thinking in the context
of knownplaintext attack and not chosen plain/ciphertext attacks.
One reason of nonapplication of the latter attacks is that PEARL1 is
meant to serve only some rather primitive needs and hence isn't
designed to deal with very sophisticated kinds of attacks. (It seems to
resist however knownplaintext attack. The forthcoming PEARL2 hopefully
would be more capable). The other and more "essential" reason of
nonapplication of the latter attacks is, if I don't err, that these
attacks principally don't apply, if the key management that I recommend
in the comments of the coding of the software is observed by the user.
For a chosen message of the attacker is then processed by a key that is
different from all keys that are used to process the messages of the
user. So any key that she manages to recover from her chosen messages
is useless to her except as matter of fun. Am I right in this?
Thanks.
M. K. Shen
.
 FollowUps:
 References:
 [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tom St Denis
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tom St Denis
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 Prev by Date: Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 Next by Date: Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 Previous by thread: Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 Next by thread: Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 Index(es):
Relevant Pages
