[fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

Jorge Aldo G. de F. Junior jagfj80 at gmail.com
Fri Dec 9 18:55:45 CET 2011


Well, lets go to theory :

One way to build a cypher is to XOR the stream that must be encrypted
against a fixed value.

But, this is easy to break using statistical methods.

So the next logical way to do this is to XOR the stream against
another stream of numbers, kind of one time password.

But, the stream of numbers must be shared by both ends.

How ? Simple, generate the stream on-the-fly using a PRNG.

Now you only need to share the seed of the PRNG and the encrypted stream.

But for this to work the same PRNG must be used on both ends, and the
PRNG must be strong enough with a period much longer than the size of
the data being encrypted.

Whats wrong with calling RANDOMIZE during the loop ? The problem is
that you keep seeding the PRNG with the Now() (current time stamp),
defeating the whole idea. Now, instead of XORing your plain text
against a pseudo-random sequence, you are XORing your plain text
against the current time/date, something quite easily predictable.

Even in your case, seeding a Mersenne Twister in every loop
interaction will put that algorithm exactly in its worst case : the
startup sequence.

The mersenne Twister is slow to start generating good random numbers.

So your program is bug to the guts in this case.

To solve this all you have to do is to guarantee that both
communication ends use the same random number generation algorithm and
seed. This will work. (IE.: the fix will break compatibility with old
binaries). And dont seed against the last result, thats not a good
idea (This will keep the MT restarting).

A good alternative to a simple encryption algorithm is to use
cryptographic hash functions like SHA.

hash your key using SHA.

Split your file in blocks the same size of the SHA key.

XOR the first block against the first key,

output the bytes.

Hash the SHA key itself, generating a second key,

XOR the second block against that second key.

repeat until end of data. PAD the last block to match the Hash size.


2011/12/9 Graeme Geldenhuys <graemeg.lists at gmail.com>:
> On 9 December 2011 12:50, Dimitri Smits  wrote:
>>
>> I actually doubt that that codesnippet does any real encryption.
>
> It isn't. The sample code / test program I posted is just a snippet of
> the actual unit. No point in posting the whole unit here, just to
> point out that a single section of code in one method is the location
> of the slow-running code under FPC. I only supplied the slow-running
> code to demonstrate the problem.
>
>
> --
> Regards,
>   - Graeme -
>
>
> _______________________________________________
> fpGUI - a cross-platform Free Pascal GUI toolkit
> http://fpgui.sourceforge.net
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal



More information about the fpc-pascal mailing list