which of these modes : cbc,cfb,ctr,ecb,ncfb,nofb,ofb,stream are secure and which are absolute no-no

By security I mean that encoded string is indistinguishable from random noise and is different on every encryption of the same text so it is impossible to make a guess on encryption algorithm used or do any dictionary attack on the encoded text.

Second: output string length does not correspond to the input string length in easy way, so it is not possible of make guessing on that account.

Third: it is possible to verify that the provided password is incorrect so the decoding function could return false instead of supposedly decoded random string.

--- edit: this is how fast given pair of algorithm and mode is encoding:

0.554 : cast-128 : ctr : 8
0.556 : gost : ncfb : 8
0.5562 : cast-128 : ecb : 8
0.5566 : cast-128 : ncfb : 8
0.5579 : gost : cbc : 8
0.5596 : gost : cfb : 8
0.5596 : gost : ofb : 8
0.5601 : gost : ctr : 8
0.5613 : cast-256 : cfb : 16
0.5621 : twofish : cbc : 16
0.5622 : rijndael-128 : ctr : 16
0.5632 : twofish : cfb : 16
0.5646 : rijndael-128 : cfb : 16
0.5656 : rijndael-128 : ofb : 16
0.5657 : rijndael-128 : ncfb : 16
0.5658 : loki97 : cbc : 16
0.5663 : gost : ecb : 8
0.5667 : cast-128 : cfb : 8
0.5674 : cast-128 : ofb : 8
0.5675 : rijndael-128 : ecb : 16
0.5684 : loki97 : ctr : 16
0.5684 : rijndael-128 : nofb : 16
0.5686 : loki97 : ecb : 16
0.5688 : loki97 : cfb : 16
0.5692 : gost : nofb : 8
0.57 : saferplus : ecb : 16
0.5701 : cast-256 : nofb : 16
0.5704 : loki97 : ncfb : 16
0.571 : twofish : ncfb : 16
0.5719 : cast-256 : ecb : 16
0.5728 : cast-256 : cbc : 16
0.573 : twofish : ofb : 16
0.5731 : cast-256 : ofb : 16
0.5737 : loki97 : nofb : 16
0.5741 : saferplus : ctr : 16
0.5748 : twofish : ecb : 16
0.575 : rijndael-192 : cfb : 24
0.5759 : cast-256 : ctr : 16
0.5769 : cast-128 : nofb : 8
0.5776 : saferplus : ofb : 16
0.5778 : saferplus : ncfb : 16
0.5778 : twofish : nofb : 16
0.5783 : rijndael-128 : cbc : 16
0.5795 : rijndael-192 : ecb : 24
0.5801 : rijndael-192 : cbc : 24
0.5808 : rijndael-192 : nofb : 24
0.5809 : saferplus : cbc : 16
0.581 : saferplus : nofb : 16
0.5829 : rijndael-192 : ctr : 24
0.5837 : serpent : ctr : 16
0.5845 : cast-256 : ncfb : 16
0.5856 : xtea : ecb : 8
0.5857 : serpent : cbc : 16
0.5859 : xtea : ctr : 8
0.5863 : saferplus : cfb : 16
0.5877 : twofish : ctr : 16
0.5881 : xtea : nofb : 8
0.5887 : xtea : ofb : 8
0.5891 : cast-128 : cbc : 8
0.5892 : xtea : ncfb : 8
0.5895 : rijndael-192 : ncfb : 24
0.5913 : serpent : cfb : 16
0.5918 : serpent : ofb : 16
0.5934 : rijndael-256 : ecb : 32
0.5935 : rijndael-256 : cbc : 32
0.5936 : serpent : nofb : 16
0.5943 : loki97 : ofb : 16
0.595 : rijndael-192 : ofb : 24
0.5958 : rijndael-256 : ctr : 32
0.596 : blowfish-compat : cbc : 8
0.5962 : serpent : ecb : 16
0.5972 : rijndael-256 : cfb : 32
0.5976 : rijndael-256 : ncfb : 32
0.5977 : xtea : cbc : 8
0.5982 : rc2 : ctr : 8
0.5989 : blowfish-compat : cfb : 8
0.599 : rc2 : cfb : 8
0.6 : des : cfb : 8
0.6002 : rc2 : no开发者_StackOverflow中文版fb : 8
0.6009 : blowfish-compat : ctr : 8
0.6013 : rc2 : cbc : 8
0.6021 : rc2 : ncfb : 8
0.604 : rijndael-256 : nofb : 32
0.6043 : blowfish-compat : ncfb : 8
0.6043 : des : nofb : 8
0.6055 : des : ecb : 8
0.607 : blowfish : cbc : 8
0.6078 : rc2 : ecb : 8
0.6081 : blowfish-compat : nofb : 8
0.6081 : des : cbc : 8
0.6093 : blowfish : ecb : 8
0.6098 : des : ofb : 8
0.6105 : blowfish : cfb : 8
0.6113 : blowfish-compat : ofb : 8
0.6137 : rc2 : ofb : 8
0.6139 : xtea : cfb : 8
0.6141 : serpent : ncfb : 16
0.6144 : des : ctr : 8
0.6174 : blowfish : ofb : 8
0.6184 : blowfish : ncfb : 8
0.6218 : des : ncfb : 8
0.6228 : blowfish-compat : ecb : 8
0.6228 : rijndael-256 : ofb : 32
0.6253 : blowfish : nofb : 8
0.628 : blowfish : ctr : 8
0.6343 : tripledes : ctr : 8
0.6356 : tripledes : cfb : 8
0.6365 : tripledes : cbc : 8
0.6367 : tripledes : ncfb : 8
0.6368 : tripledes : ecb : 8
0.647 : tripledes : ofb : 8
0.6582 : tripledes : nofb : 8

Going from top to bottom which will be safest ?

Second: this makes no sense. You realize that result of encrypting 4 bytes will be different from result of encrypting 4 Megabytes, don't you? In general to mask the real length (when encrypting password and alike) padding is used -- the data to be encrypted is appended with certain number of bytes, and then the whole thing is encrypted. But then again there's a difference between encrypting 4-byte-long password and 48-byte-long passphrase (unless you use padding to 64 bytes, but you got the idea).

Third: hashes are used for this. I.e. you include a hash of your original data (or of some additional data) with your encrypted data. After decryption the hash is re-calculated and compared with stored hash. Note, that timing attack is possible on comparison, so comparison must be implemented properly.

In general - you are trying to reinvent the wheel. If you need to just encrypt the data using a secure key (or even a password), take OpenPGP. It solves all questions you've asked and would ask while reinventing strong encryption. OpenPGP lets you use plain passphrases for encryption.

Have a look here: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio for some background.

It all depends really. Some have well known disadvantages, you have to really look at the combination cipher/concatenation and the specifics of how you use it.

For "casual use" you can argue that the block cipher mode is not the most sensitive part of the crypographic system.

Some are useful only if you wanna turn a block cipher into a stream cipher, e.g.:

• CTR
• CFB
• OFB

So unless you need a to do that, those are not useful for you.

ECB is the simplest one, main disadvantage is that equal plaintext blocks will result into identical ciphertext. There is little reason to use that these days.

Adressing your points:

1. Does not really depend on the block cipher mode. You might wanna use salt or encrypt the password N times to avoid pre-computed table attacks.

2. It doesn't happen. input is padded prior to encryption

3. Not sure what you mean...

Edit: I agree with Eugene, don't reinvent the wheel if you don't need to!