I want know the advantages of using digital signatures over HMAC for message by message authentication.  I know that HMACs are inexpensive to implement compared to DS, but DS provides a very strong security also uses more processing power. Are these two the main differences?
84767
I know the definitions of both but can't specifically tell how they are different and if one is better than the other.  Please help.
31046
It would seem to a naive eye that if you have a MAC, you have a hash function: use a key that all the parties know (such as all-bits-zero).  A potential application would be a resource-constrained platform where code size is at a premium, and which needs to implement AES for confidentiality: instead of also implementing SHA-2 for integrity verifications, it could use e.g. AES-CMAC.  Is there a reason not to do this? Is the existence of hash functions alongside MAC due to security? Performance? History?
7980
When using Encrypt-then-MAC with AES and HMAC by password, and given 128 bits of payload with the ciphertext to store a random salt, which would be more secure:   Using PBKDF2 with then entire 128 bit random salt and generating 512 bits of derived data to split into a 256 bit AES Key and a 256 bit HMAC key.   or   Using PBKDF2 separately for each key using two 64 bits salts to generate a 256 bit AES Key and a 256 bit HMAC key.    or    Better option?
45106
NaCl and libsodium libraries use Curve25519 for authenticated encryption (actually for sharing a key which is used for encryption) and Ed25519 for signatures. What is the purpose of using different primitives for these operations? Why just not to use the same primitive for both key-sharing and signatures?  Are there some security or performance considerations? But both key-sharing  and signing rely on multiplication of curve point by scalar so I guess you can't gain anything here by using different curves. If one of the curves is faster it should be faster in both cases.
112033
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" is just one example for a cipher suite, as far as I'm concerned it means this:  It uses the TLS protocol, exchanges keys with Elliptic Curve Diffie Hellman Ephemeral, whose public keys are signed with RSA and afterwards AES 128 bit is used with the Galois Counter Mode, which provides authenticated encryption. The last function is a hash algorithm which is used for calculating the message authentification code for each packet.  Given that AES-GCM already provides integrity, why is an additional hash algorithm for authentication needed? Or am I mistaken with the interpretation of this?
49880
Diffie–Hellman offers secure key exchange only if sides are authenticated. For authentication, sides are using public/private key. So if side A knows the public key of the side B, then A can simply use that key to encrypt the message (or the new session key).  Why bother to use separate key exchange algorithm?
91405
I am studying about blockchain and have been focusing on encryption protocols that allow authentication. The digital signature of public and private key seems solid, I have focused on the algorithm ED25519.  But in some places, some people say about not exposing the public key because through the public key and signature it would be possible to derive the private key. Some say that quantum computers will easily accomplish this task.  At first, I thought the reason for the bitcoin addresses was to make the public key "human-readable." But I see that there are some security points having a public key hash.  So I have some doubts:   Is it really a risk of exposing the public key without any treatment? If so, what are the alternatives? How does bitcoin, for example, validate the transaction signature with a public key hash and not the public key itself? (After all, it would be "impossible" to reverse a sha256 hash to its origin)
114816
I have an API Integration which expects a HMAC-SHA256 signature. Example:  message = 'testmessage' secret key = '123456789' signature: 9cba4d1d75689509208a97b1ca42f786a630a891e2410bfb11a84feb7a4807ad   How can I generate the same signature in Apex? I tried the generateMac function from the Crypto class but it gives a different value than the one expected. Below is the code:  Blob blobSignature = Crypto.generateMac('HmacSHA256', Blob.valueOf('testmessage'), Blob.valueOf('123456789')); System.debug(EncodingUtil.base64Encode(blobSignature));   Output: nLpNHXVolQkgipexykL3hqYwqJHiQQv7EahP63pIB60=  What I am doing incorrectly here?
51361
I do not know how the Key Length extension attack works. So if we leave that aside for once, and say just about usual brute-force attack on the hash, I don't really know how is PBKDF2 so much better than usual hashing.   Mathematically I know that PBKDF2 is so better against rainbow table attacks and also slow to recreate, but as computing power is moving up in the world, how it's still keeping its integrity?  For an HMAC we use a salt, also we can do the same for an usual hash.  So, SHA256('Hello'), is easily rainbow tabled. So if I prepend a salt, it's a little bit better, like SHA256(salt+msg), but Salts are usually kept in DB as clear text, so if some hacker is able to crack that salt, he can manually append the salt and perform the same operation.   Now in HMAC, -> H(key(opad) + h(salt + key(ipad))) is mathematically secure, but one can easily brute-force all possible password by running it through an HMAC operation (if he knows the salt), and he gets the key. A bit slower, but possible, and in pbkdf2, this whole process is looped maybe a million times even, with that much mathematical complexity, yet, if one gets the salt. He could simply run a big list of passwords with through another pbkdf2 function, and maybe very slow, but still possible, right?    So what's the use of this much complex algorithms by hashing and hashing with previous results of HMAC and so on, if it's still very much prone to a slower bruteforce?
75303
I know that RSA can be used for both, encryption and signature. What about EC? I know about ECDSA/EdDSA, but to my knowledge it can only be used to sign.  I also know about ECDH, but it is a key agreement protocol. Is there some elliptic curve based public key encryption algorithm?
52028
We consider a public hash function $H$, assumed collision-resistant and preimage-resistant (for both first and second preimage), similar in construction to SHA-1 or SHA-256. Alice discloses a value $h$, claiming that she (or/and parties she can communicate with or/and devices they have access to) knows a message $m$ such that $H(m)=h$. Can some protocol convince Bob of this claim without help of a third party/device that Bob trusts, nor allowing Bob to find $m$? At Crypto 98 rump session, Hal Finney made a 7-minutes presentation  which seems to be intended for that. This remarkable result is occasionally stated as fact, including  and . But I do not get how it is supposed to work. Update: This talk mentions using the protocol in the Crypto'98 paper of Ronald Cramer and Ivan B. Damgård:  ( is very similar, or there is ).
28872
It is often said that RSA encryption of a cryptographic hash with a private key is the same as signing (signature generation). And that verification consists of decryption using a public key.  Is RSA encryption with a private key over a cryptographic hash equivalent to  signature generation?
27520
The  below illustrates the process of  a message with RSA:    As diagram shows, the message is first hashed, and the signature is then computed on the hash, rather than on the full message.  Why hash the data before signing it? Why not sign the whole message? Of course, it'll save time if you sign just the hash value, but I've heard there are also security issues with directly signing the full message. If so, what are they?
12314
Total Crypto Noob here.  I was wondering why in ECDSA the Signing Key is so much (half of) shorter than the Verifying key?  Lets look at some python code:  import ecdsa import binascii signing_key = ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1) verifying_key = signing_key.get_verifying_key() print(binascii.hexlify(signing_key.to_string())  print(binascii.hexlify(verifying_key.to_string())  b'662ab496304f2d99aca32d813dbcba3c3ae10ab2b3359fbe43b05ee40b458cec' b'6632feae645469c16cb31d7e1364cae247bd4322040d7089476614399bcf59b2fccf5060686ab09ee64e1b768ba037184e9a87001a4897a745721f99000b44ee'   lets assume I send verifying keys over the network or store them someware, it would be nice if they were not so long. Is there a way to compress them?  I assume it would be really bad to use the keys vice versa, but I don't understand why.
76533
The current top-voted to  states:     Another one that's not so much a security issue, although it is security-related, is complete and abject failure to grok the difference between hashing a password and encrypting it. Most commonly found in code where the programmer is trying to provide unsafe "Remind me of my password" functionality.   What exactly is this difference? I was always under the impression that hashing was a form of encryption. What is the unsafe functionality the poster is referring to?
22445
In (EC)DSA as per , the message to sign is first hashed. Imagine that we skip this hashing stage, instead put the message where the hash was, and constrain the size of message $h$ to the original hash's output width $N$ bits. The resulting scheme is vulnerable to (at least) these existential forgeries ($q$ is the multiplicative group order):   any signature for message $0\le h&lt;2^N-q$ is also valid for message $h+q$; a valid signature for messages $h=0$ and $h=q$ is easy to obtain: in DSA, $(r,s)$ with $r=s=y\bmod q$ does the trick, where $y$ is the public key; there's an analog with , which $r=s=x_A\bmod q$, where $x_A$ is the $x$ coordinate of the public key, and $q=n$.   Are other attacks possible? In particular, does temporary access to a signing oracle allow a total break (key extraction or other mean to sign any message)?    The question is of direct interest when one wants to lower the communication overhead between a signing device and a host using it to (EC)DSA-sign large messages: can we fully offload the hash computation to the host? I believe that holds (and as noted in comments, that seems to be practice), but can we demonstrate that? If not, how can we safely offload most of that computation, without breaking standard conformance?
66883
Is it safe to use the hash of the data as the key to encrypt them?  That is, if I give one some encrypted data and tell them that the key that was used to encrypt them was the hash digest of the data before encrypting, will it be easier for them to decrypt them?  Edit as I can not reply to comments: The recipient will have the keys, that is no problem.