I have a requirement to encrypt the keys in a redis cache. Redis is a key - value store.
I can encrypt the keys using a standard encryption algorithm while inserting into the cache fine. But how do I do a lookup afterwards?
So say, I want to lookup a key "234" .i encrypt "234" using the same algorithm but the encrypted value will be different every time. So it won't match the encrypted value that's in the cache.
How do I solve this problem?
Don't confuse Encryption keys with the key used to look up in your "Key / value store". Encryption keys are used for encrypting stuff, whereas the "Key" in your "Key / value store" is just a name to index your values by.
In your case you Encryption key would be encrypted and then goes into the Value part. Your index would still work, as this is not encrypted.
Encryption result would not be different. Encryption is a two-way mapping between plaintext and ciphertext, given the cryptographic key.
The result of encryption may differ if you’re using a block cipher with random padding, but it’s unlikely. Even if that’s the case, you can just change the padding mode or the encryption algorithm.
So if you want to lookup key "hello" - just encrypt it and look up encrypted string in redis.
Related
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.
Firstly I'm new to cryptography.
Suppose I encrypt a plain test using AES 128 bit Encryption and passed to the receiver. The key is also passed to the receiver. At the receiver side how can I check the KEY is correct or not without fully decrypting the message.
What I mean is can we check like this
IF(KEY==something)
DECRYPT
ELSE
NOT a correct key.
Is there anything to do with IV?
I really Don't understand what the IV is.
Firstly, passing the ciphertext and key through an insecure channel is, as you can probably determine, insecure. Keeping the ciphertext and key together in the same place is the same as keeping the plaintext, so don't do that.
Rather than determine if a given key is correct for the ciphertext, cryptographic systems instead determine if the ciphertext is legitimate before they even decrypt. The most common way to do this is using a MAC, or Message Authentication Code. HMACs are a common way to do this, as are Authenticated block modes like GCM.
Lastly, an IV is used to ensure that duplicated blocks of plaintext don't result in repeated blocks of ciphertext. E.g. in ECB mode, which doesn't use an IV, each identical block of plaintext will encrypt to the same ciphertext under a given key. Applying an IV (in modes like CBC), will ensure that identical plaintext blocks look different due to a chained XOR operation that starts with the IV.
To solve your problem, either use GCM mode or use a KDF to derive a symmetric key and a key for an HMAC.
Can we assume that same encryption key is used to encrypt data if encrypted data are same?
For example, plain text is 'This is sample'.
First time we use 3DES algorithm and encryption key to encrypt it. Encrypted data became 'MNBVCXZ'.
Second time again, we use 3DES algorithm and encryption key to encrypt it. Encrypted data became 'MNBVCXZ'.
My questions are:
Can I assume static encryption key is used in this encryption process?
How many keys can be used to encrypt data using 3DES algorithm?
Can I assume static encryption key is used in this encryption process?
Yes, if you perform the encryption yourself (with a very high probability), no if an adversary can perform the encryption and the plaintext/ciphertext is relatively small.
As 3DES does indeed have 2^168 possible keys and 2^64 possible blocks, it should be obvious that some keys will encrypt a single plaintext to the same ciphertext. Finding such a pair of keys requires about 2^32 calculations on average (because of the birthday paradox).
If the plaintext is larger (requires more than one block encrypt) then the chance of finding a different key that produces the same ciphertext quickly will go to zero.
If one of the keys is preset it will take about 2^64 calculations to find another key. And - for the same reason - there is only a chance of 1 / 2^64 to use two keys that unfortunately produce the same ciphertext for a specific plaintext.
If you want to make the calculations yourself, more information here on the crypto site.
How many keys can be used to encrypt data using 3DES algorithm?
2^168 if you consider the full set of possible keys, i.e. you allow DES-ABC keys. These keys are encoded as 192 bits including parity. This would include DES-ABA and DES-AAA keys (the latter is equivalent to single DES).
2^112 if you consider only DES-ABA keys. These keys are encoded as 128 bits including parity. This would include single DES.
is it possible to retrieve AES key using AES initalization vector and encrypted data?
I have AES initalization vector and encrypted data. I have seen a online tool for decrypting AES encrypt data using AES key and AES initalization vector.
online tool: http://aes.online-domain-tools.com
When i entered any key in AES key field, it is showing AES initalization vector in initialization field.
So, I have question that if i have AES initalization vector then is it possible to retrieve AES key?
No, the AES key cannot be retrieved from the initialization if AES was applied correctly. In that case the IV and AES key should be independent of each other.
Sometimes the AES key and IV are however generated by hashing over some common value. This is not a secure method of creating an IV. In that case the IV can possibly be used as distinguisher to validate if a particular key is correct (but in general such a test can also be performed over the ciphertext. Deriving the IV from the key makes the use of an IV moot in the first place, IV's should be used to make a cipher secure when a key is reused!
Sometimes the AES key is not generated correctly, for instance by using MD5 over weak password, or by directly applying a password as a key (after padding it to the required size). In that case you may use a dictionary (and related) attacks, basically brute forcing the password to get the key. It is easier to test the correctness of the result if the IV is directly derived from the key .
Both above techniques seem to be used by the above online tool. It clearly shows you how not to apply AES.. Don't trust shit websites that are popular because they just choose an interesting name.
When passing symetrically encrypted data in a URL or possibly storing encrypted data in a cookie, is it resonable and/or nessassary and/or possible to also pass the Symetric Encryption IV (Salt) in the same URL? Is the idea of using Salt even valid in a stateless environment such as the web?
(I understand how salt works in a database given a list of names or accounts etc. but we can't save the salt given that we are passing data in a stateless environment.
Assuming a server side password that is used to encrypt data and then decrypt data, how can Salt be used? I guess a separate IV could be passed in the query string but is publicly exposing the salt ok?
Or can one generate a key and IV from the hash of a "password". Assuming the IV and Key come from non-overlapping areas of the hash, is this ok? (I realize that the salt / key will always be the same for a given password.)
EDIT: Typically using AES.
It is encouraged to generate random IVs for each encryption routine, and they can be passed along safely with the cipher text.
Edit:
I should probably ask what type of information you're storing and why you're using a salt with AES encryption, since salts are typically used for hashing, not symmetric encryption. If the salt is publicly available, it defeats the purpose of having it.
What you really need to do is ensure the strength of your key, because if an attacker has the salt, IV, and cipher text, a brute-force attack can easily be done on weaker keys.
You should not generate an initialization vector from the secret key. The initialization vector should be unpredictable for a given message; if you generated it from the key (or a password used to generate a key), the IV will always be the same, which defeats its purpose.
The IV doesn't need to be secret, however. It's quite common to send it with the ciphertext, unprotected. Incorporating the IV in the URL is a lot easier than trying to keep track of the IV for a given link in some server-side state.
Salt and IVs have distinct applications, but they do act in similar ways.
Cryptographic "salt" is used in password-based key derivation algorithms; storing a hashed password for authentication is a special case of this function. Salt causes the same password to yield different hashes, and thwarts "dictionary attacks", where a hacker has pre-computed hash values for common passwords, and built a "reverse-lookup" index so that they can quickly discover a password for a given hash. Like an IV, the salt used is not a secret.
An initialization vector is used with block ciphers like DES and AES in a feedback mode like CBC. Each block is combined with the next block when it is encrypted. For example, under CBC, the previous block cipher text is XOR-ed with the plain text of the current block before encryption. The IV is randomly generated to serve as a dummy initial block to bootstrap the process.
Because a different IV is (or should be, at least) chosen for each message, when the same message is encrypted with the same key, the resulting cipher text is different. In that sense, an IV is very similar to a salt. A cryptographic random generator is usually the easiest and most secure source for a salt or an IV, so they have that similarity too.
Cryptography is very easy to mess up. If you are not confident about what you are doing, you should consider the value of the information you are protecting, and budget accordingly to get the training or consultation you need.