Firma digitale
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
La primitiva Firma digitale ti consente di verificare che nessuno abbia manomesso i tuoi dati. Garantisce l'autenticità e l'integrità, ma non la segretezza, dei dati firmati. È asimmetrica, il che significa che utilizza una coppia di chiavi (chiave pubblica e chiave privata).
La primitiva Firma digitale ha le seguenti proprietà:
- Autenticità: è impossibile creare una firma per la quale
PublicKeyVerify.Verify(signature, message) convalida, a meno che tu non abbia la chiave privata.
- Asimmetrica: per creare la firma viene utilizzata una chiave diversa da quella utilizzata per verificarla. In questo modo puoi distribuire la chiave pubblica per la verifica delle firme a terze parti che non possono creare le firme.
Se non hai bisogno di asimmetria, valuta la possibilità di utilizzare la primitiva MAC, più semplice ed efficiente.
La funzionalità delle firme digitali è rappresentata in Tink come una coppia di primitive:
- PublicKeySign per la firma dei dati
- PublicKeyVerify per la verifica della firma
Scegli un tipo di chiave
Consigliamo di utilizzare ECDSA_P256 per la maggior parte dei casi d'uso, ma sono disponibili diverse opzioni. In generale, vale quanto segue:
- ECDSA_P256 è l'opzione più utilizzata e un valore predefinito ragionevole. Tieni tuttavia presente che le firme ECDSA sono malleabili.
- ED25519 crea firme deterministiche e offre prestazioni migliori rispetto a ECDSA_P256.
- RSA_SSA_PKCS1_3072_SHA256_F4 crea firme deterministiche e offre il miglior rendimento di verifica (ma la firma è molto più lenta di ECDSA_P256 o ED25519).
Garanzie di sicurezza minime
- I dati da firmare possono avere una lunghezza arbitraria
- Livello di sicurezza di 128 bit contro gli attacchi adattivi con messaggio scelto per gli schemi basati su curve ellittiche
- Livello di sicurezza di 112 bit contro gli attacchi adattivi con messaggio scelto per i metodi basati su RSA (consente chiavi a 2048 bit)
Duttilità
Uno schema di firma è malleabile se un malintenzionato può creare una firma valida diversa per un messaggio già firmato. Sebbene questo non sia un problema per la maggior parte degli scenari, in alcuni casi i programmatori presumono implicitamente che le firme valide siano univoche e questo può portare a risultati imprevisti.
Esempio di caso d'uso
Voglio firmare digitalmente i dati.
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-07-25 UTC.
[null,null,["Ultimo aggiornamento 2025-07-25 UTC."],[[["\u003cp\u003eDigital signatures ensure data integrity and authenticity by verifying that data hasn't been tampered with.\u003c/p\u003e\n"],["\u003cp\u003eThey use a pair of keys (public and private) for asymmetric signing and verification, allowing for secure distribution of the public key.\u003c/p\u003e\n"],["\u003cp\u003eTink provides two primitives for digital signatures: \u003ccode\u003ePublicKeySign\u003c/code\u003e for signing and \u003ccode\u003ePublicKeyVerify\u003c/code\u003e for verifying.\u003c/p\u003e\n"],["\u003cp\u003eECDSA_P256 is generally recommended, with ED25519 offering better performance and RSA_SSA_PKCS1_3072_SHA256_F4 providing the fastest verification.\u003c/p\u003e\n"],["\u003cp\u003eDigital signatures in Tink guarantee a minimum of 112-bit security and support data of any length.\u003c/p\u003e\n"]]],["Digital signatures ensure data authenticity and integrity using asymmetric key pairs (public and private). `PublicKeySign` signs data, while `PublicKeyVerify` checks signatures. Key options include the widely used ECDSA_P256, faster ED25519, and high-verification-performance RSA_SSA_PKCS1_3072_SHA256_F4. Signatures offer 128-bit security (elliptic curves) or 112-bit security (RSA). ECDSA signatures are malleable, allowing attackers to forge valid signatures. If asymmetry is not needed consider using MAC.\n"],null,["# Digital Signature\n\nThe Digital Signature primitive lets you verify that no one has tampered with\nyour data. It provides authenticity and integrity, but not secrecy, of the\nsigned data. It is asymmetric, meaning it uses a pair of keys (public key and\nprivate key).\n\nThe Digital Signature primitive has the following properties:\n\n- **Authenticity** : It is impossible to create a signature for which `PublicKeyVerify.Verify(signature, message)` validates, unless you have the private key.\n- **Asymmetric**: Creating the signature uses a different key than verifying it. This lets you distribute the public key to verify signatures to parties that can't create signatures themselves.\n\nIf you don't need asymmetry, consider using the simpler and more efficient\n[MAC](/tink/mac) primitive instead.\n\nThe functionality of digital signatures is represented in Tink as a pair of\nprimitives:\n\n- *PublicKeySign* for signing data\n- *PublicKeyVerify* for verifying the signature\n\n### Choose a key type\n\nWe recommend using **ECDSA_P256** for most use cases, but there are a variety of\noptions. In general, the following holds true:\n\n- ECDSA_P256 is the most widely used option and a reasonable default. Note though that ECDSA signatures are [malleable](#malleable).\n- ED25519 creates deterministic signatures and provides better performance than ECDSA_P256.\n- RSA_SSA_PKCS1_3072_SHA256_F4 creates deterministic signatures and provides the best verification performance (but signing is much slower than ECDSA_P256 or ED25519).\n\n### Minimal security guarantees\n\n- Data to be signed can have arbitrary length\n- 128-bit security level against adaptive chosen-message attacks for elliptic curve based schemes\n- 112-bit security level against adaptive chosen-message attacks for RSA based schemes (allows 2048-bit keys)\n\n### Malleability\n\nA signature scheme is malleable if an attacker can create a different valid\nsignature for an already signed message. While this is not a problem for most\nscenarios, in some cases programmers implicitly assume that valid signatures are\nunique, and this can lead to unexpected results.\n\n### Example use case\n\nSee I want to [digitally sign data](/tink/digitally-sign-data)."]]
