Re: How strong would randomizing data be ?

From: Joseph Ashwood (ashwood_at_msn.com)
Date: 05/09/05 

Date: Mon, 09 May 2005 11:21:53 GMT

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:d5mj69$c96$1@news4.zwoll1.ov.home.nl...
>
> "Joseph Ashwood" <ashwood@msn.com> wrote in message
> Skybuck:
>> > History has shown that many times people "fucked up" by applieing the
>> > encryption technique wrongly ;)
>>
>> Usually by attempting to create their own and failing miserably.
>
> The created of the twister number generator advices to use a secure hash
> to
> hash the generated numbers etc.

Which of course then becomes an examination of the security of the secure
hash function, and the method of use. In this case the entire pRNG can be
simply thrown out to improve performance.

> I wonder if it's possible to detect patterns in the output of the twister
> generator even if the seed is constantly different.
>
> Suppose it's not possible to detect patterns when the seed is constantly
> change then the hash won't be needed otherwise it's needed.

Actually it is surprisingly easy to detect pattern, a few years ago that was
one of the most popular ways of creating a horrible system.

>
>>
>> > So with a standard library and AES in CTR mode it's easy for somebody
>> > to
>> > completely mess up and use the same key, the same IV and the same
> counters
>> > for both senders.
>>
>> And your solution changes this how? It doesn't, if they use the same key
> and
>> IV repeatedly you will have exactly the same problem. The problem of
>> human
>> misuse is unsolvable.
>
> By feeding the first random number generator seed with data from the high
> performance timer and other things like
> free ammount of memory and ofcourse the password.
>
> It's highly unlikely that both senders will have the same seed.

You keep pretending that failure modes do not apply to your idea, failures
always apply.

>> > For me AES is like a blackbox and that's bad.
>>
>> Then study it, the original paper is online a search for Rijndael should
>> turn up a few hundred pages of examination of it.
>
> That's too much to ask for me :)

To be entirely blunt, if that is the case you should even be considering
developing your own system.

>
> I am not an expert in statical stuff so can't analyze if it shows patterns
> or not ;)

I didn't say you have to perform cryptanalytic attacks on it. In order to
eliminate the blackbox effect simply look at the design.

> This is the big drawback of using AES... many eyes are looking at it and
> someday it might be cracked and then everything that uses
> AES is cracked as well.

That line of thinking has been shown to be incorrect time after time, think
Vigenere, Enigma, monoalphabetic substitution, etc. More eyes do not destroy
the security. To show this let us consider a physical device structure
because it is more easily understood.

Consider a bank vault, a well bulit one of course. Now if you were to
consider breaking into the vault what is the first thing you would do?
Personally I would research the vault, find it's weak points and exploit
them. Having eyes on the design earlier means that these failure points are
found by the good guys BEFORE the bad guys have them, thus allowing the
vault to be replaced before someone like me takes a hammer to the correct
point on the face.

More eyes = More security, any other assumption is an immediate example of
bad design.

>
> At least with an own encryption technique extra effort is required to
> crack
> it ;) :D

That should read "At least with an own encryption technique I'll save them
large amounts of effort"

>
>>
>> > AES is probably nothing else than a fricking random number generator
> lol.
>>
>> Actually it's a pseduo-random permutation generator, look it up.
>
> Does AES hash it's output from the number generator as well ?

As I said, AES is a pseudo random permutation generator. AES doesn't have a
random number generator involved in any way. Look at the design you'll
understand why your assumptions about the design are false.

>
>>
>> > That's something I can understand. Cipher is just to fricking abstract
> ;)
>>
>> Cipher is actually more specific than a pRNG, a cipher must have a wide
>> range of characteristics beyond the requirements for random number
>> generation, in particular a cipher is exposed to analysis from the
>> outside
>> (ciphertext is available) where a pRNG is often used for Monte Carlo
>> simulations where the characteristics are not under such extreme
>> stresses.
>
> Well what techniques are applied which are different than say the twister
> number generator.

They bare no resemblance to each other. AES takes a 128-bit input and
generates a 128-bit output, pRNGs generate an output of some size, Mersenne
Twister I believe is 32-bit output.

>
> You mentioned permutation ?

All block ciphers are pseudo random permutation generators, this is
different in very important ways from a general pRNG, specifically there is
an input, and it forms a bijective function.

> What else does AES do which twister does not ? =D

That's like asking what does a CD do that a Banana does not, there is no
point of reference for comparison the closest you get is that you can throw
both of them.

The changes between a pRNG like twister and a block cipher are extensive
(I've dropped the key variables for simplicity). A block cipher X() has the
necessary property that there exists a function Y() such that m = Y(X(m)) a
pRNG does not have this requirement, in fact a pRNG does not have an m. A
pRNG function P() in fact does not have an input (although it is possible to
create one that uses an index as a parameter). This difference is critical
to understand. A second critical difference is that a pRNG generally has an
internal state that is iterated in some fashion during the number
generation, a block cipher is stateless, that is to say that two pulls from
P() are unlikely to have the same value, but X(m) will always have the same
value no matter how many times it is computed. In order to use X() as a pRNG
an additional state value is added to the system, in CTR mode m is a
counter. This fixed bijective function is critical for a block cipher, but
deadly for a pRNG.
                    Joe
                    Joe

Relevant Pages