What is the Difference between a Hash and MAC (Message Authentication code)?
By their definitions they seem to serve the same function.
Can someone explain what the difference is?
The main difference is conceptual: while hashes are used to guarantee the integrity of data, a MAC guarantees integrity AND authentication.
This means that a hashcode is blindly generated from the message without any kind of external input: what you obtain is something that can be used to check if the message got any alteration during its travel.
A MAC instead uses a private key as the seed to the hash function it uses when generating the code: this should assure the receiver that, not only the message hasn't been modified, but also who sent it is what we were expecting: otherwise an attacker couldn't know the private key used to generate the code.
According to wikipedia you have that:
While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of computation.
Of course, although their similarities, they are implemented in a different way: usually a MAC generation algorithm is based upon a hash code generation algorithm with the extension that cares about using a private key.
A hash is a function that produces a digest from a message. A cryptographically secure hash is for which it is computationally infeasible to generate a message with a given digest. On its own a hash of a message gives no information about the sender of a given message. If you can securely communicate the hash of a message then it can be used to verify that a large message has been correctly received over an unsecured transport.
A message authentication code is a way of combining a shared secret key with the a message so that the recipient of the message can authenticate that the sender of the message has the shared secret key and the no-one who doesn't know the secret key could have sent or altered the message.
An HMAC is a hash-based message authentication code. Usually this involves applying a hash function one or more times to some sort of combination of the shared secret and the message. HMAC usually refers the the algorithm documented in RFC 2104 or FIPS-198.
A MAC does not encrypt the message so the message is in plain text. It does not reveal the secret key so a MAC can be sent across on open channel with out compromising the key.
Found this to the point answer from another forum.
These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"):
Integrity: Can the recipient be confident that the message has not been accidentally modified?
Authentication: Can the recipient be confident that the message originates from the sender?
Non-repudiation: If the recipient passes the message and the proof to a third party, can the third party be confident that the message originated from the sender? (Please note that I am talking about non-repudiation in the cryptographic sense, not in the legal sense.) Also important is this question:
Keys: Does the primitive require a shared secret key, or public-private keypairs? I think the short answer is best explained with a table:
Cryptographic primitive | Hash | MAC | Digital
Security Goal | | | signature
------------------------+------+-----------+-------------
Integrity | Yes | Yes | Yes
Authentication | No | Yes | Yes
Non-repudiation | No | No | Yes
------------------------+------+-----------+-------------
Kind of keys | none | symmetric | asymmetric
| | keys | keys
Please remember that authentication without confidence in the keys used is useless. For digital signatures, a recipient must be confident that the verification key actually belongs to the sender. For MACs, a recipient must be confident that the shared symmetric key has only been shared with the sender.
Click here for more info
HASH FUNCTION: A function that maps a message of any length into a fixed length hash value, which serves as the authenticator.
MAC: A function of the message and a secret key that produces a fixed length value that serves as the authenticator.
A Hash is a summary or a finger print of a message and provide neither integrity nor authentication itself, as is it is susceptible to man-in-the-middle attack. Suppose A wants to send a message M, combined with hash H of M, to B. Instead C capture the message and generate Message M2 and hash H2 of M2, and sends it to B. Now B, by no mean can verify whether this is the original message from A or not. However, hash can be used in some other ways to achieve integrity and authentication, such as MAC.
A MAC which is also a summary of the message provide Integrity and Authentication. MAC can be computed in many ways. The simplest method is to use a hash function with two inputs, the message and a shared secret key. The use of the shared secret key adds the Authentication ability to the MAC, and thus provide integrity and authentication. However, MAC still does not provide non-repudiation, as any of the party(es) having the shared secret key can produce the message and MAC.
Here comes the Digital Signature and Public Key Cryptography in action.
Basically the main difference is MAC uses a private key and hash does not use any keys. Because of that MAC allows us to achieve authentication.
Hash functions utilize asymmetric cryptography whereas, MAC use symmetric cryptography.
Cryptographic hash functions are not always a MAC, but MAC can be a cryptographic hash functions (keyed hash functions).
Hash functions provide non-repudiation where MAC do no provide non-re
Related
Question: Is there a technical explanation how client side code-signing can be used in enterprise enviroments with open source tools like signtool or openssl?
In my usecase, I want to create a hash of a code file and sent the hash on a seperate server. This server is just used for signing. On this server are also the certificates and private keys stored.
After the hash is signed, I want to transfer the signed hash back to the client and envelope the signed hash with the code file e.g. a .exe file.
In the "Mircosoft Code Signing Best Practices", it's also recommended to first create a hash of the data and then sign the hash value with a private key.
Unfortunately I can't find any further informations how to implement this with seperate steps, described as abow.
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
"In practice, using public-key algorithms to directly sign files is inefficient. Instead, typical code-signing procedures first create a cryptographic hash of the data in a file—also known as a digest—and then sign the hash value with a private key. The signed hash value is then used in the digital signature. The digital signature can be packaged with the data or transmitted separately. A separately transmitted digital signature is known as a detached signature."
I assume that this is possible based on the fact that both utilize RSA for encryption. I should be able to read X.509 and store it as a new OpenPGP key.
The collaborator of my software needs OpenPGP.
Another collaborator provides X.509.
I am looking for a way to convert the keys.
Is that possible, how would one do that?
The short version: you can somewhat, but there is rarely good use in doing so.
You can extract the numbers forming the key and theoretically put together a new X.509 and/or OpenPGP key from them, but those would still remain incompatible, different keys in the respective system. Actually, the monkeysphere project brings tools for both directions (openpgp2pem and pem2openpgp, but make sure to read the rest of the post before heading out and converting keys).
Both X.509 and OpenPGP are more than a file format for keys: they add (incompatible) options for key management and certification, metadata, identifiers, ... Also, both systems use slightly different cryptographic modes of operation, and have very different (and thus incompatible) formats for encrypted and signed messages. They even have enormous differences in how certifications are handled (hierarchical structure in case of X.509 vs. an arbitrary graph in case of OpenPGP).
With other words: anything you do with the X.509 "representation" of an OpenPGP key sharing the same RSA primes cannot be used with the OpenPGP variant, and the other way round. Certificates issued in one system don't work in the other (and cannot be converted!).
As both keys "representations" are incompatible anyway and have to be managed separately, I would strongly recommend to create different sets of keys from beginning. After all, this adds another layer of security in case one of the keys is breached, as the other key stayed undamaged. Apart from performing unusual operations is always error-prone and suspicious to follow-up issues.
There might be good use cases, for example the monkeysphere project requires those conversions for authenticating SSH connection through OpenPGP keys. But I would not consider general usage for signing and encrypting messages and files a good use case for the reasons given above.
i want to know performance wise which is better to provide message authenticity, ECDSA signatures or hash based signatures, although i have read the comparisons of ECDSA with RSA, but not found with hash based signatures. Can ECDSA signatures replaced with Hash based signatures improves the message authenticity or not.
ECDSA is a hash based signature, in that the data gets hashed, then ECDSA is performed on the hash (not the whole data)
When it comes to data verification there are three main approaches:
Straight hash (e.g. SHA-2-256)
The fastest option to verify
If you are only protecting against line corruption this is a valid choice.
Otherwise, requires that the hash/digest value be sent over a secure (from tamper) channel, because the tampered can easily transmit the digest along with the tampered document
Provides no proof of origin
HMAC (e.g. HMACSHA256)
Requires that both the sender and receiver share the secret key
Either the sender or receiver having the key stolen puts both sides at risk
Secret key needs to come from key agreement algorithms (ECDH) or be transmitted in secret (encrypted)
Proves the document came from someone with the shared secret.
Digital Signature (e.g. ECDSA, RSA signature)
The sender is the only entity with the private key, receiver needs public key (non-secret)
Public key can be embedded in an X.509 certificate to provide a notarized association of public key to the signer
Or the public key can be transmitted raw over a secure (from tamper) channel.
Provides strong assurances about the document origin, since they shouldn't share their private key.
All three options use a hash algorithm to reduce the original data, the rest of the algorithms are what do you do with that data. There's not really a standard definition of "secure", you have to say "secure against (something)". ECDSA provides more assurances than HMAC as long as the private key isn't shared. But if HMAC provides enough assurance it is probably faster on average (specialty hardware aside).
I have a database of similar integers by the fact that they all share the same first 3 numbers:
7537463746
7536735325
7538236775
7538273826
...
Each one is associated to a user, and they are all almost exposed to the public, meaning they are sent as a sort of peer discovery, but not directly shared. I don't want the bare integer to be accessible, so I thought about hashing them with a one-way hashing function like MD5.
Since the output is not reversible like encryption or compression algorithm do, it looks great. But there's a problem; Getting the integer database is easy and inevitable, so looping through them, hashing the loop results and comparing all the hashes to the ones sent through peer communication is going to be a trivial job for malicious users.
The schema is something like this:
user1[hash(integer1),hash(integer2)...] -> |server hash database| ->
↓
↓
hash(integer1) = user8
hash(integer2) = user40
A malicious user will get user1 integers data by social engineering or other means and hash all of them to see if they're in the database by adding them to his peers data.
Now, is there any hashing algorithm to avoid this type of situation? I need the peers to communicate without giving out their integers data but still both mutually associate the same integer to a unique hash. In alternative, is key signing the only solution? I would like to avoid it since it will make the whole system slower.
Have you thought about salting your MD5? What that means is that you have some sort of secret key that only your application knows. This is actually always a good practice. So rather than doing this...
md5($userId)
You would append the "salt" inside of the MD5 like this...
md5($userId . 'this is a secret shhh!')
Now they can't get the integer from the MD5.
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.