unbreakable encryption by means of simple subtraction

[djf]

have i missed something?
i take it the algorithm is to be public domain, and the decrypt relys on the possesion of a password. This is called password protection. even Winzip does this.
it doesnt matter if your algorithm generates a key of aleph3 bits based on more random seeds than could be stored on every quark in the universe (assuming that physists discover that they are actually rather large sticky notes) - the encyphered text is only protected by a password.
Worse you have suggested that your algorithm allows for your more convenient, shorter kind of password.
what key would your algorithm output if the password was "dictionaryAttack"?

[lordshinmei]

djf: Of course you could use a dictionary attack against a stupid user. However, you don't have to use a normal password. The algorithm supports full ASCII and passwords could be a large number or something. While it is possible to encrypt with just a password, it is at least as weak as you said. I am certainly not suggesting that the algorithm be used solely for password protection: the examples of using a password as a key that I showed are just proof-of-principle examples. I would suggest that if one were to seriously use this algorithm that he or she should use a very large hash seed and possibly encrypt with multiple rounds. To get up a large hash seed, you could easily gather system entropy, as described in previous posts, and send it to the person who will receive your message by means of the Diffie-Hellman key exchange system. This way, you have a truly unpredictable hash seed.
I only used passwords as hash seeds in the examples in previous posts because it is a lot simpler to use "dog" than "fd5g465gdfd132k1jgh5145" or something like that. Obviously if anyone who knows about cryptographic attacks were to use this algorithm, that person would not do so. The difference between this and most algorithms is that keys can be arbitrarily long, and thus it is impossible to check each one. In an application like WinZip, each key is a limited number of bits. So if, in something like WinZip, I were to use a random key "11060799421205080995", all a cryptanalyst would have to do is check every key until he or she gets the right one. In an algorithm like mine, there is no way to do this, so a piece of ciphertext encrypted with a key like "110801202038804105001505005566838687114929556840035223224005316192826214404016504627426260" is virtually unbreakable, and larger and more complex keys can easily be used.