I should use encryption DES-EDE3-CBC. Does this mean it is Triple DES in cipher-block-chaining mode?
Yes. The EDE part tells you to use the specific variant of 3DES (everyone uses by default anyway) where you encrypt with key 1, decrypt with key 2, and then encrypt again with key 3 (which is usually the same as key 1).
The (minor) advantage of that mode is interoperability with DES: Set all three keys the same and you just spend a lot of time doing single DES. Not that anyone would, these days. Even 3DES is only interesting for compatibility with existing systems. Newer ciphers are faster and more secure, as far as anyone publicly admits to knowing.
Also see crypto.SE for such questions.
Related
I was asked to implement the AES algorithm for a security class. While implementing i couldn't find answer on how i can accept a key like a password, with arbitrary length, from the user and convert it to 128, 192 or 256-bit key. What should i do?
As mentioned in the comments, this is typically done with a key derivation function (KDF). There are two main types of key derivation functions that are used.
The first kind is used when you have some type of cryptographic material already, oftentimes some variant of a key exchange (usually, Diffie-Hellman). In this case, the key material is assumed to be strong and you just want to distill it and generate potentially multiple keys from it. HKDF, which is used in TLS 1.3, and the TLS 1.2 PRF are good examples of this. They are generally wrappers around HMAC, and they're pretty fast.
The second kind is used when you have a password. Because, in general, people are bad at coming up with and remembering passwords with sufficient entropy, we use a KDF that is specifically iterated so as to be slow, such as the older PBKDF2 or the newer scrypt and Argon2. These options are designed to use a unique salt and be iterated many times so that users who pick poor passwords are afforded at least some level of protection against compromise, and the newer options are designed to be expensive in memory to prevent efficient attacks on GPUs.
I have a tcl/tk based tool, which uses network password for authentication. Issue is that, it is saving password in the logs/history. So objective is to encrypt the password.
I tried to use aes package. But at the very beginning aes::init asks for keydata and initialization vector (16 byte). So how to generate IV and keydata. Is is some Random number? I am a novice in encryption algorithms.
If you have the password in the logs/history, why not fix the bug of logging/storing it in the first place?
Otherwise there are distinct things you might want:
A password hashing scheme like PBKDF2, bcrypt, argon2 etc. to store a password in a safe way and compare some user input to it. This is typically the case when you need to implement some kind of authentication with passwords on the server side.
A password encryption and protection scheme like AES. You need a password to authenticate to some service automatically, and it requires some form of cleartext password.
You have some secret data and need to securly store it to in non cleartext form.
If you have case 1, don't use the aespackage, it is the wrong tool for the job. If you have case 2, the aes package might help you, but you just exchanged the problem of keeping the password secret with the other problem of keeping the key secret (not a huge win). So the only viable case where aes is an option might be 3.
Lets assume you need to store some secret data in a reversible way, e.g. case 3 from above.
AES has a few possible modes of operation, common ones you might see are ECB, CBC, OFB, GCM, CTR. The Tcllib package just supports ECB and CBC, and only CBC (which is the default) is really an option to use.
Visit Wikipedia for an example why you should never use ECB mode.
Now back to your actual question:
Initialization Vector (IV)
This is a random value you pick for each encryption, it is not secret, you can just publish it together with the encrypted data. Picking a random IV helps to make two encrypted blocks differ, even if you use the same key and cleartext.
Secret Key
This is also a random value, but you must keep it secret, as it can be used for encryption and decryption. You often have the same key for multiple encryptions.
Where to get good randomness?
If you are on Linux, BSD or other unixoid systems just read bytes from /dev/urandom or use a wrapper for getrandom(). Do NOT use Tcls expr {rand()} or similar pseudorandom number generators (PRNG). On Windows TWAPI and the CryptGenRandom function would be the best idea, but sadly there is no Tcl high level wrapper included.
Is that enough?
Depends. If you just want to hide a bit of plaintext from cursory looks, maybe. If you have attackers manipulating your data or actively trying to hack your system, less so. Plain AES-CBC has a lot of things you can do wrong, and even experts did wrong (read about SSL/TLS 1.0 problems with AES-CBC).
Final words: If you are a novice in encryption algorithms, be sure you understand what you want and need to protect, there are a lot of pitfalls.
If I read the Tcler's Wiki page on aes, I see that I encrypt by doing this:
package require aes
set plaintext "Some super-secret bytes!"
set key "abcd1234dcba4321"; # 16 bytes
set encrypted [aes::aes -dir encrypt -key $key $plaintext]
and I decrypt by doing:
# Assuming the code above was run...
set decrypted [aes::aes -dir decrypt -key $key $encrypted]
Note that the decrypted text has NUL (zero) bytes added on the end (8 of them in this example) because the encryption algorithm always works on blocks of 16 bytes, and if you're working with non-ASCII text then encoding convertto and encoding convertfrom might be necessary.
You don't need to use aes::init directly unless you are doing large-scale streaming encryption. Your use case doesn't sound like it needs that sort of thing. (The key data is your “secret”, and the initialisation vector is something standardised that usually you don't need to set.)
I have an AES256 key that I use for encrypting SSNs in my application. Now I need to encrypt the security answer.
Is it advisable to use different keys to encrypt each field or can I use the same key to encrypt multiple fields?
We have one key for most encrypted fields and another for a few extra sensitive fields. The thought behind it is if someone gets the common key, they still would not have access to the most sensitive information.
I have no idea how this fits in "best practices", but it has worked well for us so far.
Regardless of what you do, someone determined to hack it will find a way. You just need to find the balance and level required for the type of information you are storing. When it comes to SSN and other personal information like that, it is hard to be "overly secure".
As long as you keep to best practices it is possible to use the same key for encrypting multiple fields. With best practices I mean that you need to use a random IV if you are using AES CBC encryption.
Note that the key size of AES is not that important. Having a good key infrastructure, good server security and a cryptographically secure protocol is much more important. AES-128 or even triple DES is almost infinitely safer than AES-256 if the latter is deployed improperly.
I am looking for a way of obtaining the key from this set of information, I know for a fact that we are using 16 byte blocks with CBC and I have the first 16 byte plaintext and cyphered, along with the used IV.
At the moment I can test if a key is correct by comparing the output, but I cannot bruteforce 16 character keys for obvious reasons, reading other posts it was my understanding that having the data I have it might be possible to get the key.
Any hint?
What you are trying to do is called a "known plaintext atack", you have both the cyphertext and the plaintext, all that you lack is the key used. Unfortunately, all modern cyphers are designed to resist such attacks. Unless you have extremely sophisticated mathematical skills, you will not be able to find the key this way. AES is resistant to a known plaintext attack.
You will have to try some other method of determining the key. Has the key owner left it written on a piece of paper somewhere?
Note that if AES has been applied as it should be then you cannot find the key. However, judging on the amount of incorrect implementations on stackoverflow, the key may as well be a password, or a simple SHA-256 of a string. If you can obtain information about how the key was generated/applied or stored you may be able to get around even AES-256.
Otherwise your only attack vector is breaking AES or brute forcing the key. In that case I wish you good luck, because brute forcing a 256 bit key is completely out of the question, even with a quantum computer. Unless vulnerabilities are found, of course, AES is not provably secure after all. There may be a vulnerability.
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).