Ahh another question, sorry. With this cipher a "salt" would make almost no sense since I already need a key?
or it make sense to put a "salt" together with the string to ecnrypt?
That is up to you. That is what I was trying to explain to you. You always need a key/secret to encrypt. A salt is just a little more of information that diverses that outcoming value of a hash. A hash is a one way calculation from an input string to an output string in a uniform way. Meaning the same input with same algorithm is always the same output. One way to test a cryptographic string is using rainbow tables. These are big tables consisting of the outcome of hash calculations (fast compare vs. slow calculate). By adding a salt you make it harder to have these tables because you still need to calculate or need to expand the tables of results. But as a salt is an input to the hashing function it only works if the salt is included in the input _and_ the output. Meaning you need to add the salt to the output. In the unix passwd file for instance the first two character of the password hash is the salt. You take it from encrypted string and encrypt the password with the salt to get the output you can compare with the encrypted string (the string with salt stripped off). So in any algorithm you can add a salt and prefix the output with the same salt. The difference between algorithms is how expensive they are to calculate. The best algorithm takes an awful time to compute. In this case if you send the right password it takes an acceptable amount of time to verify (one calculation) but if someone tries to brute force your password it will take way too long to make it feasible to try.
To encrypt something between two parties some information needs to be shared. If the algorithm use is shared you need to tranfer the password in cleartext to the second instance and the second instance can encrypt it the same way and compare. Sharing a secret between the parties you can transfer the encrypted string because the other part can decrypt the string and can compare the password (but you have to transfer the secret somehow).
In an asymmetric environment where there is a key pair where everything one key encrypts the other key can decrypt you just can share the other key to the second instance and you are able to transfer an encrypted string.
So whatever you do you need to decide what approach to use and what information is best to share. If you look on SSL you have everything in combination. First there is an asymmetric key exchange (expensive) that is used to exchange a shared secret. After the negotiation the network will be encrypted using the shared secret which is much less expensive saving CPU cycles.
Norbert