Will aes256 be broken if the sha512 hash of the aes256 password is known?
if the SHA-512 hash of the AES-256 password is known
If an SHA-256 value of an encryption key is known, the encryption key is still hard (=impossible) to recover. Assuming the key is random enough and has no trivial values from the rainbow tables.
Edit:
Does AES Incorporate SHA-512 into its Algorithm?
No, there are completely different things.
SHA-256 is used in PBKDF2 - it's a KDF (key derivate funtion) to generate an encryption key from a human password. The hash is used in form of HMAC-SHA2, so even the sha2 of the original password is known, it cannot be used to recover or compute the encryption key.
Related
I'm looking for a way to encrypt main password using short key/pin and decrypt it by this pin every time.
I tried to generate hash (sha256) from short key given by user and cut off the hash to desired length, decode it to bytecode and use as Fernet
Piece of code:
pin = self.pin_ent.get()
key: str = hashlib.sha256(pin.encode()).hexdigest()[10:-10]
f = Fernet(key.decode())
but python rise the error
ValueError: Fernet key must be 32 url-safe base64-encoded bytes.
It is unclear what you mean with "desired length". SHA-256 creates a 32 byte hash value (without the hex encoding that you added). You just need to base64url encode it, as the error description suggests.
A PIN is not suitable for encryption purposes as it is too easy to try all possible PIN values, and try to decrypt the stored password. If you'd use a normal-strength password to encrypt the other password (which seems counter-productive, but hey) then SHA-256 is not secure either, you'd have to use a PBKDF such as PBKDF2 to strengthen the password.
I have a file that has been encrypted using openssl using the following command:
openssl enc -in data -out encrypted -e -aes256 -k myverystrongpassword
Where data is the original file and encrypted is the encrypted file.
I tried various ways using crypto library but nothing seems to work. I understand that the password needs to be converted into a key so maybe I am doing something wrong there. Looked all over for a solution but nothing seems to work.
The posted OpenSSL statement uses a key derivation function EVP_BytesToKey() to derive a 32 bytes key and a 16 bytes IV from the password in combination with a random 8 bytes salt.
The ciphertext corresponds to the concatenation of the ASCII encoding of Salted__, followed by the salt and finally by the actual ciphertext.
As you already know according to your comment, EVP_BytesToKey() uses a digest for which OpenSSL applied MD5 by default in earlier versions and SHA-256 as of version v1.1.0 (the default value can be overridden in the OpenSSL statement with the -md option).
Decryption is possible e.g. with CryptoJS: Due to its OpenSSL compatibility (s. sec. Interoperability) CryptoJS has a built-in implementation of an accessible EVP_BytesToKey() function and additionally allows to explicitly set the digest in the internal EVP_BytesToKey() call during key derivation. This makes it possible to decrypt encryptions that used SHA-256 or MD5 in key derivation.
The following data is the Base64 encoding of a ciphertext generated with the posted OpenSSL statement. The plaintext used was The quick brown fox jumps over the lazy dog. The OpenSSL version applied is v1.1.1i (i.e. SHA-256 is implicitly used in the key derivation):
U2FsdGVkX19W4wmC9dD35X4J66cSvaRaIQpvjDKHrLF9+qYg5VTo5urvExHLXhwf/bE8FXJTQZmKN8ITMJVdqQ==
This ciphertext can be successfully decrypted using the following CryptoJS implementation:
const password = 'myverystrongpassword';
const saltCiphertextB64 = 'U2FsdGVkX19W4wmC9dD35X4J66cSvaRaIQpvjDKHrLF9+qYg5VTo5urvExHLXhwf/bE8FXJTQZmKN8ITMJVdqQ==';
CryptoJS.algo.EvpKDF.cfg.hasher = CryptoJS.algo.SHA256.create(); // default: MD5
const decryptedData = CryptoJS.AES.decrypt(saltCiphertextB64, password);
console.log(decryptedData.toString(CryptoJS.enc.Utf8)); // The quick brown fox jumps over the lazy dog
<script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.1.1/crypto-js.min.js"></script>
Note that the digest in the code must be explicitly specified as SHA-256 since OpenSSL v1.1.1i was used for encryption.
If the encryption was done with an OpenSSL version that uses MD5, the digest in the code must be modified accordingly.
Edit: As noted in the comment, the crypto functions createCipher()/createDecipher() also use EVP_BytesToKey() as key derivation.
However, the following should be noted:
Unlike CryptoJS, it is not possible to specify the digest, i.e. MD5 is used unchangeably. Thus, encryptions that applied SHA-256 for key derivation cannot be decrypted (what applies to the encryptions here).
In contrast to CryptoJS, no salt is used by default. Therefore, salt creation and concatenation (Salted__|<salt>|<cipherext>) during encryption and separation during decryption would have to be implemented additionally. createCipher()/createDecipher() then has to be passed the concatenation of passphrase and salt.
Both functions are deprecated since version 10.0.0 and should actually not be used.
A more robust approach to decrypt encryptions (with arbitrary digests in key derivation) using the crypto module is to apply createCipheriv()/createDecipheriv() and a port of the required functionality of EVP_BytesToKey() to derive key and IV (various implementations can be found on the net).
Security: EVP_BytesToKey() is deemed to be a vulnerability these days. This is worsened by a low iteration count (like 1, which is used by OpenSSL), a broken digest (like MD5) or a missing salt (as is the default for crypto). Ultimately, this is why createCipher()/createDecipher() are deprecated. Instead of EVP_BytesToKey(), a more reliable key derivation function such as PBKDF2 or the more modern scrypt or Argon2 should be used.
MAC provides data integrity, authenticity by using hash function and encryption
But why don't we just hash a message and then encrypt it to achieve the same purpose?
E(H(m),m)
We first hash plaintext m and then we encrypt m along with the digest.
Does E(H(m),m) has the same functionality as MAC?Thanks.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the optimal length for user password salt?
I have a database like below:
create table user (id int primary key auto increment,
username varchar(64),
password varchar(128), # sha512 hash of password
password_salt varchar(128) # sha512 hash of a random number used as salt
)
Is this a good idea for ensuring password security with a salt? How long should a salt be? I assume that it can't hurt to have a 128bit (SHA-512) salt, but I've been wrong before.
I have several comments:
Salts should be random and unique per user, but they don't have to be a hash digest. The idea of a salt is just to make the hash digest unique per user to resist dictionary attacks and rainbow table attacks. The salt doesn't add to the strength of the hash digest algorithm, regardless of the salt's length.
DES uses 12 bits for the salt. Updated UNIX password systems use more, up to 128 bits.
If you want stronger passwords, consider using bcrypt or PBKDF2.
FWIW, a SHA-512 hash digest (encoded as hex digits) is always exactly 128 characters, regardless of the length of the input. So I'd use CHAR(128) instead of VARCHAR(128). Use BINARY(2) or BINARY(3) for the salt.
I need to transmit some data over the wire and I don't want that data being plain text.
The text I'm sending needs to be reversed so I can't md5/sha256/etc...
What's a good way to encode a salted string?
You're looking for encryption.
What language are you using? You probably have a built-in encryption algorithm you can use.
The idea with hashing is that you can only go one-way.
[plain text]--->(HASH ALGORITHM)--->[hash]
Whereas the idea with encryption is that you can use a key together with some plaintext to create a ciphertext. Then you can use the key on the ciphertext to retrieve the plaintext at any time:
[plain text] + [key] --->(ENCRYPTION ALGORITHM)-->[ciphertext]
[ciphertext] + [key] --->(DECRYPTION ALGORITHM)-->[plain text]
The decryption algorithm for a given encryption algorithm is usually very similar to the encryption algorithm, and it allows for the retrieval of a plaintext message given a ciphertext and the correct key (ie password).
You want to use an encryption function, not a hash - which by definition is one-way.
The AES encryption algorithm would be a good start, as the is probably the most widely used one at present.
You don't want a hash, you want encryption. You should look at Blowfish.