only those that take their jobs seriously and read help/manuals iso assuming? :-)

I actually doubt that that codesnippet does any real encryption. From what I understand from it (with the provided code and assuming types), the source-message is bitstreamed. In the resulting message, the LSB of every octet/byte/8-bitvalue is the one you need to focus on, the rest is random data. Also, as a result, the result-message is 8 times as large. And that LSB is also easily decrypted => parse the LSB from every byte in your data and reconstruct using OR the (index mod 8)-th bit on the (index div 8) octet.

hardly encrypted ;-)

kind regards,
Dimitri Smits

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.

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 :

Jorge Aldo G. de F. Junior wrote

Well, lets go to theory :

In case you didn't notice the unit name this code comes from.... tiEncryptSimple.pas
The name should be a good enough hint that it wasn't meant for real-world apps. ;-) For real-world apps, tiOPF has other encryption units based on DES and Blowfish.

But thanks for the theory. I'll keep it for a rainy day.