Robert,
Thanks a lot for your thorough explanations.
----- Original Message -----
From: "Robert Kern" <[EMAIL PROTECTED]>
To: <python-list@python.org>
Sent: Saturday, May 07, 2005 3:18 PM
Subject: Re: Encryption with Python?
( snip )
> >>You do realize that if I have two ciphertexts encrypted with the same
> >>key, I can subtract them? Then I have a sequence, that while not
> >>immediately readable, is just a straightforward combination of the two
> >>plaintexts without any encryption.
> >
> > How do you know the same key was used?
>
> I don't necessarily, but if the same key *is* used, I'll know. The
> differences of the ciphertexts will have distinctly non-random
> characteristics (well, assuming the plaintexts aren't one-time pads
> themselves).
The non-randomness of the difference is evidence of having guessed the key,
right? Why then do I need two samples? If I hack away at a single sample I
get a probably more conspicuous non-randomness twice as fast.
( snip )
> Additionally, one should not use the Mersenne Twister PRNG, which is
> what Python uses, as the PRNG for the stream cipher. Given a particular
> value or series of values, it is possible to determine one's position in
> the PRNG sequence and can, in essence derive the key. Some techniques
> can be used to hide actual current state of the PRNG like applying a
> cryptographic hash to the value from the PRNG. However, it's easier and
> far better to just use a cryptographically strong PRNG from the start.
I don't doubt that, given a series (long enough), the postion can be
derived. I doubt, though, that a series is knowable, if another, unknown,
series has been added to it.
> > If, however, it is meant to suggest
> > that it is the reversible, direct one-on-one relation between all the
> > characters of a plain text and its encryption that falls short of
> > state-of-the-art technology, I'd have no problem with that. That doesn't
> > mean, however, that an exercise is required to measure up to
> > state-of-the-art standards in order to be taken seriously. I do invent
my
> > own solutions for simple problems.
>
> This is not a simple problem.
I thought the problem was concealing passwords from ones kids or
collaborators.
>
> You haven't proved your claim that your cipher is "unbreakable." Your
> notion of "unbreakable" is also flawed; "indistinguishable from 'random'
> sequences" is only one part of cryptosystem security. For that matter,
> you haven't proven that the ciphertexts produced are "indistinguishable
> from random sequences." Note the plural. It's important.
I believe that a randomly distributed series utterly obliterates any
non-randomness or regularity of a second series, if the two are added. I
don't know how to produce a formal proof. It is just a hunch. It's actually
more than a hunch. It is a conviction. Not a certainty; a conviction. I'd be
delighted to be proved wrong (or right). The fact may be significant that we
module overflow back into the range.
So, if the distribution of my code is indeed random, it will display
no clue about the key and can only be broken with a brute-force attack. This
imposes a second requirement, which is that a brute-force attack outtries
the patience of a teraflop machine. The function I posted, quite obviously,
does not satisfy this second requirement. The function can easily be applied
in a manner, though, that takes care of that.
A third rquirement I cannot think of.
> You have a positive obligation to back your claim. I've pointed you to
> two obvious attacks that can be made against your system and also to
> resources that you can read to improve your knowledge of the issues. I
> *don't* have an obligation to spend more of my time meeting your
> arbitrary challenge. My reluctance to do so is not support for your claim.
I am not aiming at a Nobel prize and certainly don't presume to impose on
your priorities. So the term 'obligation' seems not very useful here.
>
> > I claim that my
> > solution satisfies the requirements of the task at hand and challenge
anyone
> > to prove the contrary. You can meet the challenge by deciphering the
> > following tiny message, knowing now the encryption method, which in
practice
> > would not be known
>
> Bull. And irrelevant.
Irrelevant okay, if the OP agrees.
( snip )
Best regards,
Frederic
--
http://mail.python.org/mailman/listinfo/python-list
