Is The Private Key Known For The Sender And Receiver With Mac

Of cryptographic hash functions and message authentication codes (MAC). And k1, k2 are secret keys which are only known to the sender and the receiver. Where k is a shared secret key, and kpr is a private key of the sender (not shared.

Encryption with a secret symmetric key does not prove authenticity unless you use such as. Authenticated encryption algorithms generate a in addition to encrypting the message, and if the shared key is properly secured this can be used to prove the authenticity and integrity of the message but not non-repudiation (this is a big 'if' - more later). Regular symmetric key encryption with a shared key does not prove the integrity nor authenticity of the message because nothing prevents an attacker from generating a random message which the receiver will then decrypt and accept.

Though the attacker doesn't know what the decrypted message will look like there are many situations in which having the receiver accept a randomly generated message may be advantageous to an attacker. Only someone with access to the symmetric key can generate a MAC of a message, so using authenticated encryption with a properly secured symmetric key is enough to authenticate the message. MACs do not provide non-repudiation because in symmetric cryptography the receiver also has the same secret key, so there's no way for the receiver to prove that the sender and not the receiver signed the message. As emphasized previously, using a shared key for authentication requires the shared key to be properly secured.

Specifically, if the receiver generates the symmetric key and sends it to the sender asymmetrically encrypted with the receiver's public key (which is the ordinary way to send encryption keys using PKI) then this symmetric key cannot be used to prove the authenticity of messages sent by the sender since nothing in the process proves the identity of the sender. Anyone with access to the receiver's public key (which is after all public) can generate a random symmetric key and encrypt it with the receiver's public key. A symmetric key can be used to authenticate a message only if the scheme for generating the shared symmetric key includes two way authentication. Schemes which include two way authentication to generate shared keys for signing and encrypting messages are commonly known as a Secure Authenticated Channel or SAC.

Encryption does not protect against malicious alterations. If you encrypt some data with a stream cipher like RC4 or AES-CTR, then an attacker can decide to flip any bit he wants on the ciphertext, and, upon decryption, this flips the corresponding bit in the plaintext. This allows surgical modifications.

With block ciphers in CBC mode, things are a bit less surgical, but still contained enough to allow the attacker to do a lot of nifty things (with CBC and a block cipher with 16-byte blocks, if the attacker flips one bit, then this scrambles the corresponding block and flips the corresponding bit in the next block). So you need checked integrity as well as encryption. Some modes of encryption for block ciphers, such as, combine encryption and an integrity check.

Otherwise, a stand-alone can do the trick (but combining encryption and a MAC properly so you are encouraged to use modes where all the hard specification work has been done, i.e. Some people use the term 'signature' for a MAC; it is an improper but widespread usage. A MAC, and a fortiori mere unprotected encryption, do not provide non-repudiation. Non-repudiation is about having a proof which can be used against the signer; conceivably, something which could convince a third party like a judge. A computation which uses a shared secret between sender and receiver cannot be a convincing proof, because, by definition, both sender and receiver know it (and the dispute is between the sender and the receiver). Non-repudiation is a complex notion with legal ramifications, but, at the very least, the computer part must use true computed over the data which is not to be repudiated (and not only over a shared key).