Re: Pseudorandom keystream ciphers

On Wed, 5 Aug 2009 21:58:42 -0700 (PDT), xxein <xxein@xxxxxxxxxxx>

On Aug 3, 9:23 am, rossum <rossu...@xxxxxxxxxxxx> wrote:
On Mon, 03 Aug 2009 15:58:58 GMT, Unruh <unruh-s...@xxxxxxxxxxxxxx>

George Orwell <nob...@xxxxxxxxxxxx> writes:

It would seem to me that the security of a pseudorandom keystream
cipher (PKS) such as RC4 is wholly dependent on the pseudorandom
function used. The more the psuedorandom function mimics random data
the harder it is to break. In its ultimate form the PKS would  converge
towards an OTP / Vernam Cipher, which has been proven to be
unbreakable. What's more, such encryption has the advantage that it
can't be broken in the future by Quantum computers either.

False. any pseudorandom generator starts from a small finite number of
initial states. And exhaustive search on those will break the cypher,
where as an OTP  cannot be broken that way.

Are there any implementations of a PKS which have a stronger
pseudorandom number generator? What about a cryptographic CSPRNG like  
Blum Blum Shub being keyed by a key and its output XOR'ed with the
datastream resulting in a pseudorandom ciphertext output.

Just try all keys and find the message.

Provided that the message is longer than the Unicity distance.

rossum- Hide quoted text -

- Show quoted text -

xxein: You seem to be a veteran of cryptology and I am not.
A semi-veteran amateur. There are professionals who post here who
know a lot more than I do.

But I
have geek-like ideas. I hope you will indulge me. This might be
rather long.

Some 10 to 20 yrs-ago, I wrote a 12 kb exe that is hand computable.
It is a self-generating sequence text of say mod 94. There are
several security considerations that I am learning about. But I am
confused by some issues.

My code is symmetrical but a truly hidden algorithm .
The general advice is to avoid hidden algorithms. Especially hidden
algorithms developed by amateurs. Fine for your own use, but not for
anything else, and not for anything important.

It is hidden
within the fact that my correspondence is limited to a single trusted
respondent. Iow, the program is the key and acts like any
sophisticated private key.
Given enough text the algorithm (or just the keystream) could be
recovered. Reusing the same key in a mod 94 cipher is not a good

To expand it to other users, with a
singular security, I would have to overlay it with a real private key
for all different correspondents. No problem except that I am getting
too old and lazy to do that.

So my questions will be the following. Given mod 94, would a private
key be secure if its length is 256?
Not unless you changed the every 256 characters. If your algorithm is
good then the number of characters between key changes might be
larger. Any good algorithm design will come with a statement of how
much data can be transferred with a given key before the key needs to
be changed.

I am figuring that is a no.

But my algorithm (although symmetrical) has hidden properties in that I
can pass it numerous times to encryption and/or decryption without
loss. Add intermittent fluff to the original letter count and it is
still readable as plain text. No big deal, I guess.
Modern algorithms use all 256 possible byte values in their cyphertext
output. If you need ASCII only then just convert to Base-64 before

So now I am wondering if the original (private key -256) overlay
combined with a response overlay will maintain a security with that
individual. Iow, that the overlays will continually increase a
discreteness. I can create such a method but wonder if it really
would work. I think yes. Take that as ambiguous as you want to.
These are just methods.
Use AES in CBC or CTR mode. Use Base-64 to make the cyphertext ASCII
only. This wheel has already been invented.

If you want to try some simple (and insecure) cyphers for yourself
then look at Vigenere or Playfair for ASCII only and RC4 for full 8
bit output.


I'm smart enough to realise that any scientific method is reliant only
upon what we construct to understand it. Therefor, there are numerous
possibilities of thought not explored nor used in the general arsenal
which we can have at hand (so to speak). But who decides this

It is innovative. Right? In this respect, a code can be entropic to
all but the individual correspondents who can maintain the
correspondence. But even a single code can morph into several forms

cr1'/ ^w#:*
W=* b{+

how about

vN c/=t
(o ^9*7nt
[ b17gQX


NNPVlJnFdJ@:6<^ZV$\(4zBVpT.4HVTB* BZ<$Xl\.P FPPNH2T0X:T^dhb@D-E)Hz/
tvC=/8>{4zO#-<D/j>3iinz'(tF".2T\p8Op{P\Pjbm0Y|\xdp_R;jDHh8fW,ddM@7Q !
DJ#LWc`mzH%p/WJU8@-`W6A^(5zKXrj@RqnI`&(f$MT).8z<>UVE&,,**0 D5>

They all give the exact plain script uopn extraction in a symmetrical
system. Want me to extract it in real time?


The modulus ends up being greater than the original 94 somehow. It is
infinite in this symmetrical system. How? I don't exactly know. But
it appears that it is. The letter count is the same but it doesn't
seem to make any difference to its crackability. All that is required
is the exe program that can be modified to extract the same number of
passes in the right direction to solve the code. This info can be
sent in a prior message overlaid with a private key. Even a plain
text can pass this on provided this info is unnoticed.

Even with big brother monitoring all communications, it is easy to
slip this initial setup under the rug to prevent decypher. The
drugstore hand-off of the exe. But, of course, bb will investigate
why you email in code they can't crack and read. They can stop this
flow also. But that's only a limit until they stop you from
communicating entirely. They might be unsatisfied if they cannot know

The perils are out there for any uncrackable code being found. Even
with the extraction of a private key it is circumvented by the overlay
of the last communication (if thought to be an important key).

So, I guess my last question is how do you think you would treat
this? Or did I say too much?

In the end, though, and even if it is symmetric, my code (if modified
in such manners) would require the complete history of communications
from the start to decode. But I'm too lazy to modify the code. Not
too lazy to tell you about it though.