Hello, i know i can use openssl to encrypt file by single command:


Encrypt:

Decrypt:

I DO NOT want to use encryption key because i dont know where to store it, it appears too much time to handle it and protect it.

How can i encrypt some file via more difficult encryption like 2048bit in one command please? I wish the best protection algorithm because i listen 256bit is not enough

You're mistaken about the key length. 256 bit keys for symmetric encryption is more than enough.

The 2048 and 4096 bit keys you've probably heard about, relates to asymmetric encryption algorithms used in SSL certificates. These algorithms are slow and CPU intensive, need much longer keys, and are only used to encrypt very small pieces of data such as, well, 256 bit AES session keys.

By the way, if you don't want to use encryption keys, what on earth do you want to use? Without a key, nothing can be encrypted (or decrypted for that matter). The only alternative to a symmetric encryption key is an asymmetric encryption key, which is still very much an encryption key that needs to be stored somewhere.

1 members found this post helpful.

It is very simplistic to say "more bits is better". It really depends on the quality of the encryption algorithm and the known attacks against it.

Just as an example:
2048-bit RC4 versus 128-bit AES ... which one wins ?

Read up on RC4 for the answer:
http://en.wikipedia.org/wiki/Rc4#Security

You'd have to modify RC4 to make it accept the huge key, but barring an implementation error (such as ignoring the known weak keys issue), a modified RC4 could very well come out on top. Of course, with keys that large we'd probably have trouble seeing if the encryption was actually broken, what with the sun having burnt out and all that.

A better example would be 1024-bit RSA vs. 128-bit AES. AES would win hands down, as the algorithms are fundamentally different.

Yeah, that also works. It's just to illustrate a point, that key size does not equal security because you have to take into account what you do with the key -- the algorithm. BTW, on the wiki it says that 2048 is a possible key size for RC4, even tho it is not typical. RC4 has some severe vulnerabilities, and its use is discouraged because of them.

If I were to recommend an encryption algorithm I would say that you should thoroughly investigate each algorithm, the weaknesses, and who designed it (NSA ?). The algorithm should not be too old, because with the advance of computing power and cryptography, older algorithms tend to be weaker. However, newer ones are not necessarily better, because they haven't had as much testing from the crypto community. I would pick one that is not very old, not very new, and has no or few known weaknesses. I would also make sure to factor in the complexity of the algorithm, an example of which would be AES. Although simplicity does not equal simple to crack, it has to be well tested. ATM, my pick would be twofish. That's just my opinion according to my research. Also note that this only applies to symmetric key algorithms. There are also asymmetric ones like some used by gpg.
See:
http://en.wikipedia.org/wiki/Public-key_cryptography
Note that this too has its own set of possible vulnerabilities. In the end you must understand and choose.

I probalbly dont understand function of the .key because i think one have 2 options. key or password, but still key must be somehow password protected or else its easy to to find the key on computer. What i hate on key that when you loose it you cant recover data, thats why i think password is better (agaian im absolute amateur).

Also its strange to me that in age of quantum computers, there is only one 256bit encryption which people says is possible to be decypted by special super computers or such. Why the * is not there encryption which canot be hacked even by million times faster computer than all computers of this world... all these encryptions like AES depends on password length, so if i add like 6x100 chars password, im millions times more secure than 6 chars password?

Here's a guide on how to choose strong passwords:
http://www.thegeekstuff.com/2008/06/...ong-passwords/
Also make sure that it is difficult for an attacker to deduce a password using information about you, i.e. don't use personal information in your password.

During the encryption process the key is generated by hashing your password plus a salt (random data). The password needs to be strong and the salt random.
http://en.wikipedia.org/wiki/Key_%28cryptography%29
http://en.wikipedia.org/wiki/Key_derivation_function
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Nobody has yet definitively proven the existence of quantum computers:
http://tech.slashdot.org/story/14/02...ntum-after-all

1 members found this post helpful.

I submit for your consideration that "no password is 'strong.'" Why not? Because it's a password.

The strongest form of protection is: the most human-practical arrangement that you can come up with. Nothing that requires you to keystroke-in a long string, let alone a "tough to crack" long-string, etcetera etcetera. This is not going to work, and the reason why it's not going to work is human factors, not technical ones.

Use digital certificates, properly handled and protected. Physically secure the data store. But make the protection system easy, and as transparent as possible to the authorized users.

And ... don't even try to protect against "the NSA."