Editing Digital signature (section)

===Authentication===
A message may have letterhead or a handwritten signature identifying its sender, but letterheads and handwritten signatures can be copied and pasted onto forged messages.
Even legitimate messages may be modified in transit.<ref name="stinson3e2006digsigs">{{cite book
|title=Cryptography: Theory and Practice
|last=Stinson
|first=Douglas
|author-link=Doug Stinson
|edition=3rd
|isbn=978-1-58488-508-5
|publisher=Chapman & Hall/CRC
|date=2006
|chapter=7: Signature Schemes
|page=281
}}</ref>

If a bank's central office receives a letter claiming to be from a branch office with instructions to change the balance of an account, the central bankers need to be sure, before acting on the instructions, that they were actually sent by a branch banker, and not forged—whether a forger fabricated the whole letter, or just modified an existing letter in transit by adding some digits.

With a digital signature scheme, the central office can arrange beforehand to have a public key on file whose private key is known only to the branch office.
The branch office can later sign a message and the central office can use the public key to verify the signed message was not a forgery before acting on it.
A forger who ''doesn't'' know the sender's private key can't sign a different message, or even change a single digit in an existing message without making the recipient's signature verification fail.<ref name="stinson3e2006digsigs"/><ref name="bellare-goldwasser2008digsigs"/><ref name="katz-lindell2007digsigs"/>

[[Encryption]] can hide the content of the message from an eavesdropper, but encryption on its own may not let recipient verify the message's authenticity, or even detect [[Malleability (cryptography)|selective modifications like changing a digit]]—if the bank's offices simply encrypted the messages they exchange, they could still be vulnerable to forgery.
In other applications, such as software updates, the messages are not secret—when a software author publishes a patch for all existing installations of the software to apply, the patch itself is not secret, but computers running the software must verify the authenticity of the patch before applying it, lest they become victims to malware.<ref name="katz-lindell2007digsigs"/>

====Limitations====

'''Replays.'''
A digital signature scheme on its own does not prevent a valid signed message from being recorded and then maliciously reused in a [[replay attack]].
For example, the branch office may legitimately request that bank transfer be issued once in a signed message.
If the bank doesn't use a system of transaction IDs in their messages to detect which transfers have already happened, someone could illegitimately reuse the same signed message many times to drain an account.<ref name="stinson3e2006digsigs"/>

'''Uniqueness and malleability of signatures.'''
A signature itself cannot be used to uniquely identify the message it signs—in some signature schemes, every message has a large number of possible valid signatures from the same signer, and it may be easy, even without knowledge of the private key, to transform one valid signature into another.<ref name="bcjz2020ed25519sectheorypractice">{{cite tech report
|first1=Jacqueline
|last1=Brendel
|first2=Cas
|last2=Cremers
|first3=Dennis
|last3=Jackson
|first4=Meng
|last4=Zhao
|title=The Provable Security of Ed25519: Theory and Practice
|publisher=IACR Cryptology ePrint Archive
|number=2020/823
|date=2020-10-14
|url=https://eprint.iacr.org/2020/823
}}</ref>
If signatures are misused as transaction IDs in an attempt by a bank-like system such as a [[Bitcoin]] exchange to detect replays, this can be exploited to replay transactions.<ref name="decker-wattenhofer2014btcmalleablemtgox">{{cite conference
|first1=Christian
|last1=Decker
|first2=Roger
|last2=Wattenhofer
|title=Bitcoin Transaction Malleability and MtGox
|doi=10.1007/978-3-319-11212-1_18
|pages=313–326
|editor-first1=Mirosław
|editor-last1=Kutyłowski
|editor-first2=Jaideep
|editor-last2=Vaidya
|conference=European Symposium on Research in Computer Security—ESORICS
|year=2014
|series=Lecture Notes in Computer Science
|volume=8713
|publisher=Springer
|isbn=978-3-319-11212-1
|doi-access=free
|arxiv=1403.6676
}}</ref>

'''Authenticating a public key.'''
Prior knowledge of a ''public key'' can be used to verify authenticity of a ''signed message'', but not the other way around—prior knowledge of a ''signed message'' cannot be used to verify authenticity of a ''public key''.
In some signature schemes, given a signed message, it is easy to construct a public key under which the signed message will pass verification, even without knowledge of the private key that was used to make the signed message in the first place.<ref name="ayer2015sigmisuseacme">{{cite mailing list
|first1=Andrew
|last1=Ayer
|title=Signature misuse vulnerability in draft-barnes-acme-04
|date=2015-08-11
|mailing-list=acme@ietf.org
|url=https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc/
|access-date=2023-06-12
}}</ref>