The default params used for AES encryption with CryptoJS are:
Cypher: AES-256
Mode: cbc
Key Derivation: evpkdf (OpenSSL custom, MD5, 1 iteration)
Are these safe to use?
Related: What are the AES parameters used and steps performed internally by crypto-js while encrypting a message with a password?
Answering my own question; NO! ABSOLUTELY NOT!
CryptoJS by default does only a single iteration of MD5 hashing over the password, which is extremely weak unless the password is extremely strong!
Correct key derivation of arbitrary passwords should do key derivation with something along the 30k iterations!
Related
Let's say I have a ciphertext encrypted with CTR.
And I know the nonce used to be encrypted as well as the AES key. Is it possible to decrypt the given ciphertext using ECB mode?
sorry if this is already asked, i looked around couldn't find anything
I am new in cryptography. I need to encrypt a text using AES with some configuration
Encryption mode: GCM
Key size: 256 bits
Nonce size: 96 bits
MAC size: 128 bits
As AES is a symmetric algo. so i have a secrete key. I googled and found
nonce is a random number used to make sure a message is unique
But i have a doubt, how i can perform decryption, if nonce is a random number. do i need to store nonce along with each encryption. or any other way i need to split nonce, cipher and mac using key.
how can i use the provided configuration for encryption.
But i have a doubt, how i can perform decryption, if nonce is a random number. do i need to store nonce along with each encryption.
Yes, result of the encryption stored/sent is nonce, ciphertext, mac.
how i can perform decryption, if nonce is a random number
Nonce is randomly generated when encrypting the input and the nonce is then passed along the ciphertext (very often the nonce is prepended as the first block). Indeed you need THE SAME nonce value when decrypting, then the nonce is part of the input for decrpytion, not random
or any other way i need to split nonce, cipher and mac using key. how can i use the provided configuration for encryption.
There is a standardized message format for encrypted document or encrypted XML messages, but these are pretty pretty complex.
In reality - for simpler applications very often we see the encryption output composed as IV || ciphertext || MAC (as concatenation). IV and MAC are having fixed length, so you can cut them out and use the parameters for decryption.
decryption is happening on different machine and language. they have shared only a key for encryption. same key they are using for decryption. if i will add any random value as nonce then how hey will know what logic i have used for nonc
It doesn't matter until you provide the same input. As already mentioned - you may pass the IV (nonce) as part of the message and before decryption separate the nonce and original ciphertext.
BTW: I have a few encryption examples linked
Precisely, the nonce must be stored with the cipher text.
Remember, the nonce being part of the cipher text doesn't give the attacker any advantage.
From Wikipedia:
An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.
The purpose of initialization vector is to insert some randomness the encryption process so that an attacker cannot know when two identical plaintext messages have been encrypted with the same key.
IV is required for decryption, you can simply send it concatenated with the ciphertext.
IV || ciphertext
The most common way to transmit an initialization vector is, indeed, to prepend it immediately before the ciphertext.
If I am using Rijndael CBC mode, I have no idea why we would need salt.
My understanding is even if people know the password, but he cannot get the data without IV.
So from my perspective, password + IV seem to be sufficent secure.
Do I get anything wrong?
Yes, you need all of these things.
Salt (and an "iteration count") is used to derive a key from the password. Refer to PKCS #5 for more information. The salt and iteration count used for key derivation do not have to be secret. The salt should be unpredictable, however, and is best chosen randomly.
CBC mode requires an initialization vector. This is a block of random data produced for each message by a cryptographic random number generator. It serves as the dummy initial block of ciphertext. Like the key-derivation salt, it doesn't have to be kept secret, and is usually transmitted along with the cipher text.
The password, and keys derived from it, must be kept secret. Even if an attacker has the parameters for key derivation and encryption, and the ciphertext, he can do nothing without the key.
Update:
Passwords aren't selected randomly; some passwords are much more likely than others. Therefore, rather than generating all possible passwords of a given length (exhaustive brute-force search), attackers maintain a list of passwords, ordered by decreasing probability.
Deriving an encryption key from a password is relatively slow (due to the iteration of the key derivation algorithm). Deriving keys for a few million passwords could take months. This would motivate an attacker to derive the keys from his most-likely-password list once, and store the results. With such a list, he can quickly try to decrypt with each key in his list, rather than spending months of compute time to derive keys again.
However, each bit of salt doubles the space required to store the derived key, and the time it takes to derive keys for each of his likely passwords. A few bytes of salt, and it quickly becomes infeasible to create and store such a list.
Salt is necessary to prevent pre-computation attacks.
An IV (or nonce with counter modes) makes the same plain text produce different cipher texts. The prevents an attacker from exploiting patterns in the plain text to garner information from a set of encrypted messages.
An initialization vector is necessary to hide patterns in messages.
One serves to enhance the security of the key, the other enhances the security of each message encrypted with that key. Both are necessary together.
First things first: Rijndael does not have a "password" in CBC mode. Rijndael in CBC mode takes a buffer to encrypt or decrypt, a key, and an IV.
A "salt" is typically used for encrypting passwords. The salt is added to the password that is encrypted and stored with the encrypted value. This prevents someone from building a dictionary of how all passwords encrypt---you need to build a dictionary of how all passwords encrypt for all salts. That was actually possible with the old Unix password encryption algorithm, which only used a 12-bit salt. (It increased the work factor by 4096). With a 128-bit salt it is not possible.
Someone can still do a brute-force attack on a specific password, of course, provided that they can retrieve the encrypted password.
However, you have an IV, which does pretty much the same thing that a Salt does. You don't need both. Or, rather, the IV is your salt.
BTW, these days we call "Rijndael" AES.
A salt is generally used when using a hash algorithm. Rijndael is not a hash, but a two-way encryption algorithm. Ergo, a salt is not necessarily needed for encrypting the data. That being said, a salted hash of a password may be used as the Key for encrypting data. For what you're looking for, you might wish to look at hybrid cryptosystems.
The Key should be considered private and not transmitted with your encrypted data while the IV may be transmitted with the encrypted data.
Normally a password would be arbitrary strings, such as "abc", "1234". But the encryption algorithm like DES requires a fixed length secret key. I'd like to know how to transform variable-length password to fixed length secret key with an acknowledged way.
Derive encryption keys from passwords with a Password Based Key Derivation Function: PBKDF2 (aka Rfc2898DeriveBytes). Use a random salt and an iteration count such that the derivation takes about 100ms of computation time.
The same salt and iteration count must be used for deriving the key for decryption, they can be prepended to the encrypted data since they do not need to be secret.
Just using a hash function is not sufficient and just adding a salt does little to improve the security.
The point is to make the attacker spend a lot of time finding passwords by brute force.
You need to use a salt value (in order to prevent dictionary attacks) and good key deviation function like scrypt, bcrypt or PBKDF2.
if you only use a hash function for generating the key, then there are a lot of chances that the generated keys are SHA256("abcd") or SHA256("password"). That is, this method is very vulnerable to brute-force attacks.
I'm some newbie of data encryption. I goggling data encryption and mostly found md5 and SHA algorithms.Which technology do you consider to be the best for data storage/security and why?
MD5 and SHA are hash functions, they create fingerprint - fixed-length representation - from the bunch of data. For example, they are extensively used as a way to check consistency of your iso image downloads for many open-source products, but this means you can use them to create fingerprints from any selection of bytes. So they do not encrypt.
If you want to encrypt, you should check for encryption algorithms. The most feasible now I believe is AES (Advanced encryption Standard) if you look for symmetric encryption algorithms (eg. where key for encryption and decryption is the same or easily computed one from another) or RSA if you look for asymmetric (where you have 2 keys - public and private, and compute private key from public is hard task).
If you are about to create digital signatures, you may want to check things like DSA (digital signature algorithm) and ECDSA (DSA over elliptic curves.). Note that asymmetric algorithms work over numbers with extended precision - like 512, 1024, 2048 bits and so on. You need special libraries that can handle such numbers. If you use C++ I can recommend you trying Crypto++. Find something similar for other languages.
I hope this was useful for you.
If your data is password and you want to store it some where then Use MD5 or SHA Hash.
There are two advantages of these.
A hash can not be decrypted to recover old value so your password will never ever will be cracked even if you provide MD5/SHA hash of password to some one :)
A hash of particular string will be always same so you can compare passwords based on Hash.
AES :
Symmetric algorithm so faster
Use with PKCS5Padding and CBC mode
Always store IV
Symmetric so you need same key while you are decrypting encrypted text so you can not at all share keys.
RSA
PKI Infrastructure to exchange Keys
Slow
There are other algorithms also Like DES(Not So Secure), 3DES(Often called Tripple DES- Not enough secure compared to DES)