I have gotten very curious about how data is secured from hackers and I was wondering about the difference between password protecting an excel file vs encrypting it with AES. I have found that both methods encrypt the files, and also require the user to type in a password to decrypt them. So why is password protecting easier to break?
Thanks
(For simplicity I'll demonstrate with only lowercase english letters)
When using a password you have 26 letters a-z.
With AES-128 the key is 128/8 = 16 letters.
So the possible number of combinations with only lowercase english letters are 26^16 = 43608742899428874059776.
If you on the otherhand use ALL possible values for the key that would be 256^16 = 3.4028236692093846346337460743177e+38 number of combinations. (That is more than 7803076000000000 times more combinations which would result in that much more time to "crack").
As you can see there are a lot more possible keys with a randomly generated AES key than with using a password.
This is a gross simplification, not concidering salt, key expansion, etc, but should get the point through.
Related
I have two files:
one is a raw plain text file which is first compressed using ZStandard and then encoded with Base64
one is basically the same file but it is encrypted after the compression but before the encoding. I know the password used und have a 32 byte long salt.
Assumptions made:
I assume that the algorithm used is aes-128. Why? Because I actually have four files (two pairs) and the biggest common divisor of the two ciphers is 16, so I at least can assume a 128bit blocksize. And AES because it is the most common
The cipher is not generated using ECB since the same plain text results in different ciphers each time I let it generate.
I can provide one pair with its password and salt. I can also provide multiple pairs all with the same plain text if needed.
What is this for:
I am currently implementing a golang library to communicate with TeamSpeak 3 ServerQuery. It provides the possibility to create snapshots of servers and you can encrypt them using a password. I'd like to decrypt them with the password and the salt to parse and manipulate them.
I was not yet able to figure out, which mode is used with what IV.
I've tried many different possibilities including but not limited to:
Hashing the password using MD5 and using it as a key
Hashing the password with the salt using MD5
Hashing the password and then hashing the password hash and salt using MD5
Using the first half of the salt in the Key hash and the second half as a iv and vise versa
I am pretty much all out of ideas at this point. If anyone can just so much as point me in a direction would be appreciated.
MfG
I came across this:
I don't understand how AES128 is stronger than AES256 in a brute force attack, or how AES256 allows for more combinations than AES128.
These are my simplified premises - assuming I have 100 unique characters on my keyboard, and my ideal password length is 10 characters - there would be 100^10 (or 1x10^20) combinations for brute force attack to decry-pt a given cipher text.
In that case, whether or not AES128 or AES256 is applied doesn't make a difference - please correct me.
Yes, you are correct (in that a weak password will negate the difference between AES128 and AES256 and make bruteforcing as complex as the password is). But this applies only to the case when the password is the only source for key generation.
In normal use, AES keys are generated by a "truly" random source and never by a simple pseudorandom generator (like C++ rand());
AES256 is "more secure" than AES128 because it has 256-bit key - that means 2^256 possible keys to bruteforce, as opposed to 2^128 (AES128). The numbers of possible keys are shown in your table as "combinations".
Personally, I use KeePass and passwords of 20 symbols and above.
Using 20-symbol password composed of small+capital letters (26+26), digits (10) and special symbols (around 20) gives (26+26+10+20)^20 = 1.89*10^38 possible combinations - comparable to an AES128 key.
how AES128 is stronger than AES256 in a brute force attack
AES does multiple rounds of transforming each chunk of data, and it uses different portions of the key in these different rounds. The specification for which portions of the key get used when is called the key schedule. The key schedule for 256-bit keys is not as well designed as the key schedule for 128-bit keys. And in recent years there has been substantial progress in turning those design problems into potential attacks on AES 256.This is the basis for advice on key choice.
how AES256 allows for more combinations than AES128
AES256 uses 256 bits, giving you the permissible combination of aroung 2^256, while in case of 128, its 2^128.
These are my simplified premises - assuming I have 100 unique characters on my keyboard, and my ideal password length is 10
characters - there would be 100^10 (or 1x10^20) combinations for brute
force attack to decry-pt a given cipher text.
I am not quite sure what your understanding is, but when you say applying AES128/AES256, you actually encrypt your password into a cipher text.It is encoded information because it contains a form of the original plaintext that is unreadable by a human. It won't just use all the 100unique characters from your keyboard. It uses more than that. So, if you want to get the original password, you must find the key with which it is encrypted. And that gives you the combination figures 2^128 ans 2^256.
Right now, this is what I am doing:
1. SHA-1 a password like "pass123", use the first 32 characters of the hexadecimal decoding for the key
2. Encrypt with AES-256 with just whatever the default parameters are
^Is that secure enough?
I need my application to encrypt data with a password, and securely. There are too many different things that come up when I google this and some things that I don't understand about it too. I am asking this as a general question, not any specific coding language (though I'm planning on using this with Java and with iOS).
So now that I am trying to do this more properly, please follow what I have in mind:
Input is a password such as "pass123" and the data is
what I want to encrypt such as "The bank account is 038414838 and the pin is 5931"
Use PBKDF2 to derive a key from the password. Parameters:
1000 iterations
length of 256bits
Salt - this one confuses me because I am not sure where to get the salt from, do I just make one up? As in, all my encryptions would always use the salt "F" for example (since apparently salts are 8bits which is just one character)
Now I take this key, and do I hash it?? Should I use something like SHA-256? Is that secure? And what is HMAC? Should I use that?
Note: Do I need to perform both steps 2 and 3 or is just one or the other okay?
Okay now I have the 256-bit key to do the encryption with. So I perform the encryption using AES, but here's yet another confusing part (the parameters).
I'm not really sure what are the different "modes" to use, apparently there's like CBC and EBC and a bunch of others
I also am not sure about the "Initialization Vector," do I just make one up and always use that one?
And then what about other options, what is PKCS7Padding?
For your initial points:
Using hexadecimals clearly splits the key size in half. Basically, you are using AES-128 security wise. Not that that is bad, but you might also go for AES-128 and use 16 bytes.
SHA-1 is relatively safe for key derivation, but it shouldn't be used directly because of the existence/creation of rainbow tables. For this you need a function like PBKDF2 which uses an iteration count and salt.
As for the solution:
You should not encrypt PIN's if that can be avoided. Please make sure your passwords are safe enough, allow pass phrases.
Create a random number per password and save the salt (16 bytes) with the output of PBKDF2. The salt does not have to be secret, although you might want to include a system secret to add some extra security. The salt and password are hashed, so they may have any length to be compatible with PBKDF2.
No, you just save the secret generated by the PBKDF2, let the PBKDF2 generate more data when required.
Never use ECB (not EBC). Use CBC as minimum. Note that CBC encryption does not provide integrity checking (somebody might change the cipher text and you might never know it) or authenticity. For that, you might want to add an additional MAC, HMAC or use an encryption mode such as GCM. PKCS7Padding (identical to PKCS5Padding in most occurences) is a simple method of adding bogus data to get N * [blocksize] bytes, required by block wise encryption.
Don't forget to prepend a (random) IV to your cipher text in case you reuse your encryption keys. An IV is similar to a salt, but should be exactly [blocksize] bytes (16 for AES).
I am creating an encryption scheme with AES in cbc mode with a 256-bit key. Before I learned about CBC mode and initial values, I was planning on creating a 32-bit salt for each act of encryption and storing the salt. The password/entered key would then be padded with this salt up to 32 bits.
ie. if the pass/key entered was "tree," instead of padding it with 28 0s, it would be padded with the first 28 chars of this salt.
However, this was before I learned of the iv, also called a salt in some places. The question for me has now arisen as to whether or not this earlier method of salting has become redundant in principle with the IV. This would be to assume that the salt and the iv would be stored with the cipher text and so a theoretical brute force attack would not be deterred any.
Storing this key and using it rather than 0s is a step that involves some effort, so it is worth asking I think whether or not it is a practically useless measure. It is not as though there could be made, with current knowledge, any brute-force decryption tables for AES, and even a 16 bit salt pains the creation of md5 tables.
Thanks,
Elijah
It's good that you know CBC, as it is certainly better than using ECB mode encryption (although even better modes such as the authenticated modes GCM and EAX exist as well).
I think there are several things that you should know about, so I'll explain them here.
Keys and passwords are not the same. Normally you create a key used for symmetric encryption out of a password using a key derivation function. The most common one discussed here is PBKDF2 (password based key derivation function #2), which is used for PBE (password based encryption). This is defined in the latest, open PKCS#5 standard by RSA labs. Before entering the password need to check if the password is correctly translated into bytes (character encoding).
The salt is used as another input of the key derivation function. It is used to prevent brute force attacks using "rainbow tables" where keys are pre-computed for specific passwords. Because of the salt, the attacker cannot use pre-computed values, as he cannot generate one for each salt. The salt should normally be 8 bytes (64 bits) or longer; using a 128 bit salt would give you optimum security. The salt also ensures that identical passwords (of different users) do not derive the same key.
The output of the key derivation function is a secret of dkLen bytes, where dkLen is the length of the key to generate, in bytes. As an AES key does not contain anything other than these bytes, the AES key will be identical to the generated secret. dkLen should be 16, 24 or 32 bytes for the key lengths of AES: 128, 192 or 256 bits.
OK, so now you finally have an AES key to use. However, if you simply encrypt each plain text block with this key, you will get identical result if the plain text blocks are identical. CBC mode gets around this by XOR'ing the next plain text block with the last encrypted block before doing the encryption. That last encrypted block is the "vector". This does not work for the first block, because there is no last encrypted block. This is why you need to specify the first vector: the "initialization vector" or IV.
The block size of AES is 16 bytes independent of the key size. So the vectors, including the initialization vector, need to be 16 bytes as well. Now, if you only use the key to encrypt e.g. a single file, then the IV could simply contain 16 bytes with the value 00h.
This does not work for multiple files, because if the files contain the same text, you will be able to detect that the first part of the encrypted file is identical. This is why you need to specify a different IV for each encryption you perform with the key. It does not matter what it contains, as long as it is unique, 16 bytes and known to the application performing the decryption.
[EDIT 6 years later] The above part is not entirely correct: for CBC the IV needs to be unpredictable to an attacker, it doesn't just need to be unique. So for instance a counter cannot be used.
Now there is one trick that might allow you to use all zero's for the IV all the time: for each plain text you encrypt using AES-CBC, you could calculate a key using the same password but a different salt. In that case, you will only use the resulting key for a single piece of information. This might be a good idea if you cannot provide an IV for a library implementing password based encryption.
[EDIT] Another commonly used trick is to use additional output of PBKDF2 to derive the IV. This way the official recommendation that the IV for CBC should not be predicted by an adversary is fulfilled. You should however make sure that you do not ask for more output of the PBKDF2 function than that the underlying hash function can deliver. PBKDF2 has weaknesses that would enable an adversary to gain an advantage in such a situation. So do not ask for more than 256 bits if SHA-256 is used as hash function for PBKDF2. Note that SHA-1 is the common default for PBKDF2 so that only allows for a single 128 bit AES key.
IV's and salts are completely separate terms, although often confused. In your question, you also confuse bits and bytes, key size and block size and rainbow tables with MD5 tables (nobody said crypto is easy). One thing is certain: in cryptography it pays to be as secure as possible; redundant security is generally not a problem, unless you really (really) cannot afford the extra resources.
When you understand how this all works, I would seriously you to find a library that performs PBE encryption. You might just need to feed this the password, salt, plain data and - if separately configured- the IV.
[Edit] You should probably look for a library that uses Argon2 by now. PBKDF2 is still considered secure, but it does give unfair advantage to an attacker in some cases, letting the attacker perform fewer calculations than the regular user of the function. That's not a good property for a PBKDF / password hash.
If you are talking about AES-CBC then it is an Initialisation Vector (IV), not Salt. It is common practice to send the IV in clear as the first block of the encyphered message. The IV does not need to be kept secret. It should however be changed with every message - a constant IV means that effectively your first block is encrypted in ECB mode, which is not properly secure.
I need to save the password to database.I get confused in encryption,hash using sha-256 ,salt generation method .If any one explains the basic concept behind this then it will be helpful
The follow is a very basic explanation, anyway...
Encryption is a reversible method to crypt the data. So if you have "password" a encryption method convert it into (for example) "ufmehlejw" and then you are able to get again "password".
An hash function (one of them is the sha-256) is a function that once it's used on a string you have no way to recover the original string.
A salt is a string which usually prorammers (and not only, of course) use to mix the given password. It's usually randomly generated. A salt is used to extend the original data before using an hash function. The goal of the salt is to avoid attackers to discover the original password of a user from a stolen hash using rainbow tables.
In short:
Encryption is a process with an inverse. In other words: If I encrypt some text, there is a process which is able to convert the new text back to the original, called decryption.
Hashing is fundamentally different from encryption, because it does not have such a process. What a hash is meant to do is provide you with a result, which is unique for that given input text (well, almost unique, let's keep it at unique). This way, people can verify if two input texts were equal, without knowing what the actual input text was. So, if people get their hands on your hashed password, they still cannot decrypt it. SHA is a family of methods which provide hashing.
Salts and Peppers are merely additional techniques to hashing, which describe the process of adding something before and after the input text before hashing. This improves the difficulty of brute-force cracking of hashes back to text.
Brute force cracking means simply trying all possible inputs (aa, ab, ac, etc...) and see if you can generate a hash which matches the hash you have gotten via hacking some website or whatever. You can find more on that here: https://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough