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.
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.
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.
As it stands, I have written a python3 project to encrypt a file (using AES) and a public/private key system (RSA) to encrypt the AES key.
My current predicament is as follows, what is the best approach to get the encrypted AES key to the recipient ? My program does NOT depend on the medium for sending of the files, rather just the files are securely encrypted. In other words, once a user chooses a public key of the recipient, there is no peer-to-peer communication.
Is naming the file the RSA encrypted AES key a bad idea ?
I dont have extensive knowledge of cryptography as such, so any suggestions are welcome
If you know the recipient public RSA key you can use RSA-KEM (KEM : Key Encapsulation Mechanism). RSA-KEM for a single recipient with AES-GCM simply as follows;
The Sender;
First generate a x in [2..n-1] uniformly randomly, n is the RSA modulus.
Use a Key Derivation Function (KDF) on x,
key= KDF(x)
for AES 128,192, or 256-bit depending on your need. Prefer 256.
Encrypt the x,
c = x^c mod n
Encrypt the message with AES-GCM generate an IV and
(IV,ciphertext,tag) = AES-GCM-Enc(IV,message, key)
Send (c,(IV,ciphertext,tag))
The receiver;
To get x, They are using their private exponent d,
x = c^d mod n
Uses the same (KDF) on x to derive same AES key,
key= KDF(x)
Decrypts the message with AES-GCM
message = AES-GCM-Dec(IV,ciphertext,tag, key)
Note 1: This is actually a composition of a KEM and a DEM (data encapsulation mechanism; an authenticated cipher serves as a DEM). This provides the standard of IND-CCA2/NM-CCA2—ciphertext indistinguishability and nonmalleability under adaptive chosen-ciphertext attack. That is the minimum requirement for modern Cryptography.
Note 2: If you want to send the key itself as you described, to prevent the attacks on textbook RSA, you will need a padding scheme like OAEP or PKCS#v1.5. RSA-KEM eliminates this by using the full modulus as a message.
Note 3: The above described RSA-KEM work for a single-user case. RSA-KEM for multiple users will fall into Håstad's broadcast attack. Instead use RSAES-OAEP, this makes it safe for multiple recipients with the same x encrypted for different recipients. This will make it very useful to send the message multiple recipients instead of creating a new x for every recipient and encrypting the message for each derived key (as PGP/GPG does).
Today I was doing some leisurely reading and stumbled upon Section 5.8 (on page 45) of Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) (NIST Special Publication 800-56A). I was very confused by this:
An Approved key derivation function
(KDF) shall be used to derive secret
keying material from a shared secret.
The output from a KDF shall only be
used for secret keying material, such
as a symmetric key used for data
encryption or message integrity, a
secret initialization vector, or a
master key that will be used to
generate other keys (possibly using a
different process). Nonsecret keying
material (such as a non-secret
initialization vector) shall not be
generated using the shared secret.
Now I'm no Alan Turing, but I thought that initialization vectors need not be kept secret. Under what circumstances would one want a "secret initialization vector?"
Thomas Pornin says that IVs are public and he seems well-versed in cryptography. Likewise with caf.
An initialization vector needs not be secret (it is not a key) but it needs not be public either (sender and receiver must know it, but it is not necessary that the Queen of England also knows it).
A typical key establishment protocol will result in both involve parties computing a piece of data which they, but only they, both know. With Diffie-Hellman (or any Elliptic Curve variant thereof), the said shared piece of data has a fixed length and they have no control over its value (they just both get the same seemingly random sequence of bits). In order to use that shared secret for symmetric encryption, they must derive that shared data into a sequence of bits of the appropriate length for whatever symmetric encryption algorithm they are about to use.
In a protocol in which you use a key establishment algorithm to obtain a shared secret between the sender and the receiver, and will use that secret to symmetrically encrypt a message (possibly a very long streamed message), it is possible to use the KDF to produce the key and the IV in one go. This is how it goes in, for instance, SSL: from the shared secret (called "pre-master secret" in the SSL spec) is computed a big block of derived secret data, which is then split into symmetric keys and initialization vectors for both directions of encryption. You could do otherwise, and, for instance, generate random IV and send them along with the encrypted data, instead of using an IV obtained through the KDF (that's how it goes in recent versions of TLS, the successor to SSL). Both strategies are equally valid (TLS uses external random IV because they want a fresh random IV for each "record" -- a packet of data within a TLS connection -- which is why using the KDF was not deemed appropriate anymore).
Well, consider that if two parties have the same cryptographic function, but don't have the same IV, they won't get the same results. So then, it seems like the proposal there is that the two parties get the same shared secret, and each generate, deterministically, an IV (that will be the same) and then they can communicate. That's just how I read it; but I've not actually read the document, and I'm not completely sure that my description is accurate; but it's how I'd start investigating.
IV is public or private, it doesn't matter
let's consider IV is known to attacker, now by looking at encrypted packet/data,
and knowledge of IV and no knowledge on encryption key, can he/she can guess about input data ? (think for a while)
let's go slightly backwards, let's say there is no IV in used in encryption
AES (input, K)= E1
Same input will always produce the same encrypted text.
Attacker can guess Key "K" by looking at encrypted text and some prior knowledge of input data(i.e. initial exchange of some protocols)
So, here is what IV helps. its added with input value , your encrypted text changes even for same input data.
i.e. AES (input, IV, K)= E1
Hence, attacker sees encrypted packets are different (even with same input data) and can't guess easily. (even having IV knowledge)
The starting value of the counter in CTR mode encryption can be thought of as an IV. If you make it secret, you end up with some amount of added security over the security granted by the key length of the cipher you're using. How much extra is hard to say, but not knowing it does increase the work required to figure out how to decrypt a given message.
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.