Editing Digital signature (section)

==Applications==

As organizations move away from paper documents with ink signatures or authenticity stamps, digital signatures can provide added assurances of the evidence to provenance, identity, and status of an [[electronic document]] as well as acknowledging informed consent and approval by a signatory.  The United States Government Printing Office (GPO) publishes electronic versions of the budget, public and private laws, and congressional bills with digital signatures.  Universities including Penn State, [[University of Chicago]], and Stanford are publishing electronic student transcripts with digital signatures.

Below are some common reasons for applying a digital signature to communications:

===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>

===Non-repudiation===
[[Non-repudiation]],<ref name="Cryptomathic_MajorStandardsDigSig" /> or more specifically non-repudiation of origin, is an important aspect of digital signatures. By this property, an entity that has signed some information cannot at a later time deny having signed it. Similarly, access to the public key only does not enable a fraudulent party to fake a valid signature.

Note that these authentication, non-repudiation etc. properties rely on the secret key {{em|not having been revoked}} prior to its usage. Public [[certificate revocation|revocation]] of a key-pair is a required ability, else leaked secret keys would continue to implicate the claimed owner of the key-pair. Checking revocation status requires an "online" check; e.g., checking a [[certificate revocation list]] or via the [[Online Certificate Status Protocol]].<ref name="CryptomathicDigSigServicesAshiqJA" />  Very roughly this is analogous to a vendor who receives credit-cards first checking online with the credit-card issuer to find if a given card has been reported lost or stolen. Of course, with stolen key pairs, the theft is often discovered only after the secret key's use, e.g., to sign a bogus certificate for espionage purpose.