Timeline for What are the differences between a digital signature, a MAC and a hash?
Current License: CC BY-SA 4.0
24 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 13 at 18:45 | comment | added | Les Hazlewood | @David天宇Wong the word 'authentication' in the context of cryptographic integrity/transformation algorithms does not mean that the message came from an authenticated party - it means that the message is verified to maintain its integrity via a known ('authentic') key. Non-repudiation is the attribute/quality used to ensure it did or did not come from a known party. If you wish to avoid the overlapping term associated with user/party authentication, perhaps the word 'authenticity' would be better to be used in the context of message verification. | |
May 20 at 8:23 | history | edited | Y.T. | CC BY-SA 4.0 |
revert a wrong correction
|
Oct 4, 2023 at 13:16 | history | edited | cora | CC BY-SA 4.0 |
If we have both integrity and authenticity, then the attacker cannot forge a message.
|
Jan 25, 2022 at 14:57 | comment | added | LIU YUE | just one correction:quote:"A message authentication code (MAC) (sometimes also known as keyed hash) protects against message forgery by anyone who doesn't know the secret key (shared by sender and receiver).", this is only true to good MAC like HMAC, not bad MAC based on hash functions like md5 sha1 which are prone to Length extension attack | |
Jul 27, 2021 at 11:17 | history | edited | IMSoP | CC BY-SA 4.0 |
re-format table using Markdown
|
Apr 11, 2019 at 8:59 | comment | added | user1156544 |
If the hash is transmitted over a different... --> Usage example: mega.nz
|
|
May 29, 2018 at 16:06 | comment | added | Jesse | @Mindau isn't that the repudiation aspect? ie. the sender can repudiate the message. However.. assuming the shared key is safe and the receiver has only shared it with the sender it follows that the receiver knows the message came from the sender. ( if a MAC is used ) So the sender is "Authenticated" via MAC | |
Jul 3, 2017 at 16:47 | comment | added | Mindau | MAC does not prove Authentication, because Receiver can create identical message and Sender can disagree about sending anything | |
Apr 25, 2017 at 12:18 | comment | added | EralpB | @shuva digital signature does not protect against spoofing.. It's just like plaintext+signature so it doesn't provide confidentiality by itself. | |
Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
Feb 22, 2017 at 22:58 | comment | added | KRoy | I guess MAC does NOT provide anti-spoofing mechanism while the Digital Signature provides that. | |
Feb 15, 2017 at 15:39 | comment | added | Nikolay Suvandzhiev | Very good answer. Can someone extend on that table with regards to the "security goal" or "confidentiality" ? | |
Feb 14, 2017 at 18:54 | comment | added | David 天宇 Wong | @flimm check something like Dan Boneh and Shoup's book on cryptography. i.imgur.com/j0vL8Rw.png | |
Feb 13, 2017 at 18:41 | comment | added | Flimm | @David天宇Wong I don't read that many cryptography textbooks, but as far as I know they have the definitions that are used here. In any case, I'm glad that the answer includes the definitions before the table, which is the clearest solution. | |
Feb 13, 2017 at 17:09 | comment | added | David 天宇 Wong | Note that this diagram is not really correct anymore. Some cryptographers say that a MAC provides "integrity", not authentication anymore, since it's clearer. Whereas a hash does not provide integrity, but rather pre-image, second pre-image, collisions resistance. | |
May 3, 2016 at 13:25 | comment | added | aiao | A hash and MAC can be truncated to an arbitrary size. A signature cannot. | |
Mar 17, 2014 at 3:57 | comment | added | David 天宇 Wong | so basically: MAC is a Hash that uses a "symmetric" key, Signature is a Hash that uses an asymetric key. | |
S Oct 25, 2013 at 16:47 | history | suggested | user2813687 | CC BY-SA 3.0 |
As far as I can tell digital signatures don't prevent replay attacks but the way the answer was written was slightly ambiguous.
|
Oct 25, 2013 at 16:02 | review | Suggested edits | |||
S Oct 25, 2013 at 16:47 | |||||
Dec 13, 2012 at 8:58 | vote | accept | Flimm | ||
Dec 11, 2012 at 12:04 | comment | added | CodesInChaos | One interesting variation is using the result of a DH key exchange as the key for a MAC. That way you can use asymmetric keys, but you avoid non-repudiation. | |
Dec 10, 2012 at 22:04 | history | made wiki | Post Made Community Wiki by Flimm | ||
Dec 10, 2012 at 21:25 | history | edited | Paŭlo Ebermann | CC BY-SA 3.0 |
include the "the answer should include" part from the question, transpose the table to avoid scrolling, and expand a bit.
|
Dec 10, 2012 at 12:39 | history | answered | Flimm | CC BY-SA 3.0 |