Randomness for cryptographic purposes, need advise

[stanhebben]

- using 2 passwords and multiplying them would be the same as using 1 password since that will be the result.

Your goal was to make sure that you need two passwords in order to decrypt the file. Just make sure you never send the final password. Then if somebody can obtain one of the passwords, he doesn't know the final password.

2) There are other test that can provide the same info. Generally the "bad guys" will know what sort of file they should end up with - text, exe, whatever - each of these has identifying traits - text should end up with valid ascii characters only (or mostly), exes have the MZ and PE headers with known bytes for checking purposes.

That's why I recommend compressing the file. Then you don't know it's contents, or at least it's much harder to guess.

And 32- bit seeds are indeed too short. You should have a random number generator which accepts seeds of any size.

[white scorpion]

That's why I recommend compressing the file. Then you don't know it's contents, or at least it's much harder to guess.

Compressing might be useful to implement, but nevertheless, an attacker does usually know what kind of file he is searching for.
Think of filename, location etc etc
This of course would not be the case if it would have been an uploaded file abc.abc which would have no reference on what it should contain.
Unfortunately most files used are Office documents (.xls, .doc, .ppt, .pst) ,executables and textfiles.
If you think of it like this it's a pretty good guess to try one of the six for a plaintext attack.

Ok, to make a long story short, this is what i need (at least):
- compress the file
- create a random generator which can use seeds of every length, or at least much longer then 4 bytes since otherwise i would have 4,294,967,296 possible seeds which of course isn't that much when talking in encryption ways.
- use a checksum to check if the file is decrypted successfully. (i'm still not convinced about this).

for the alghoritm:
- use all possible ways of linking every byte in the password so that even if one bit would change the password wouldn't work anymore. (no collisions).
examples could be:
A+B / 2 = ?
A*A+B*B = C*C --> use C (pythagoras)
A-B=?
A+B=?
A%B=?
and a whole lot (more complicated) ones.
every result could be used to pick a byte from the table and encrypt a byte from the plaintext
- take a predefined block size and start rotating and swapping bytes in the plaintext. move up one byte and do it again, etc, etc

[Ossa]

Sorry, you lost me there... what are A, B and C? and how are they used to pick the random byte?

Ossa

[white scorpion]

sorry..
A,B,C are characters from the password, location doesn't really matter much.
How they pick... That's a good one, still thinking about that.
If i would say A*B/2= 0x45 (for example) and use the 0x45'th place in the table, i would only have a select range of numbers to pick from, since people almost always use the standard keyboard characters as a password.
So  i must implement this differently, but how is still the question.

[stanhebben]

Maybe you could also be interested in rsa encryption.

I don't know if you are familiar with it, but you can use it as follows:

- You have a private key, consisting of two numbers
- Multiplying the two numbers gives you the public key. You can transmit that one. The receiver can then encrypt the file.
- The file can be transmitted
- To decrypt the file, you need the private key. (the public key won't work)

Just an idea I wanted to throw in. I can explain how it operates, if you are interested.

[Ossa]

Stan, lets just throw in Diffie-Hellman key exchange and make a full protocol while we're at it... :bg

I think what White Scorpion is after (and correct me if I'm wrong) is to create his own encryption algo (not something that I think is the most sensible way to go, but I have to admire his determination).

Ossa

(RSA is also slow... much better to use a good block cipher for speed).

[stanhebben]

I don't know exactly what White Scorpion wants, but I wanted to throw it in anyway, as it could be useful.

But I'm also glad to help inventing a new algorithm, if that's what white scorpion is after.

[white scorpion]

public key encryption is not meant for files, because of it's speed like Ossa said,  but it should be very safe.

Yeah, i do want to create my own algo, even though i know it will be a painful task.
I've already read several books on encryption methods, and i still have a few to go, but yes, i'm determined to get this to work.
Unfortunately i don't know most of the math symbols used, so that makes it harder for me to understand the formulas used.
I'm better in understanding the formula once it is written in assembly.

IMO not understanding most of the symbols used in the formulas is terrible, so i'm currently upgrading my math knowledge as well.
Like i said, it will take some time, but i'm positive it is worth it when it's finished.

[Mark_Larson]

white_scorpion

  What about mixing two vastly different types of encryption?  Use IDEA, twofish, blowfish or something similar for the first encryption.  For the second one use a book encryption or vignette.  So that the two different encryption schemes are really different.

[white scorpion]

It's a very good idea, i will definitely keep it in mind.
It will then become a combination of my own algo with an already existing one.