التوقيع الرقمي
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتيح لك الأداة الأساسية "التوقيع الرقمي" التحقّق من أنّه لم يتم التلاعب
ببياناتك. ويضمن ذلك صحة وسلامة
البيانات الموقَّعة، ولكن ليس سريتها. وهو غير متماثل، أي أنّه يستخدم مفتاحَين (المفتاح العام
والمفتاح الخاص).
تتضمّن العنصر الأساسي "التوقيع الرقمي" السمات التالية:
- الأصالة: من المستحيل إنشاء توقيع يُجري
PublicKeyVerify.Verify(signature, message) عملية التحقّق منه، ما لم يكن لديك المفتاح الخاص.
- غير المتماثل: يستخدم إنشاء التوقيع مفتاحًا مختلفًا عن مفتاح التحقّق
منه. يتيح لك ذلك توزيع المفتاح العام لإثبات صحة التوقيعات على الأطراف
التي لا يمكنها إنشاء التوقيعات بنفسها.
إذا لم تكن بحاجة إلى عدم التناظر، ننصحك باستخدام العنصر الأساسي
MAC الأسهل والأكثر فعالية بدلاً من ذلك.
يتم تمثيل وظيفة التوقيعات الرقمية في Tink كزوج من
العناصر الأساسية:
- PublicKeySign لتوقيع البيانات
- PublicKeyVerify للتحقّق من التوقيع
اختيار نوع المفتاح
ننصحك باستخدام ECDSA_P256 لمعظم حالات الاستخدام، ولكن هناك مجموعة متنوعة من options. بشكل عام، تنطبق القواعد التالية:
- ECDSA_P256 هو الخيار الأكثر استخدامًا والإعداد التلقائي المقبول. يُرجى العلم
أنّ توقيعات ECDSA قابلة للتلاعب.
- ينشئ ED25519 توقيعات حتمية ويقدّم أداءً أفضل مقارنةً بـ ECDSA_P256.
- ينشئ RSA_SSA_PKCS1_3072_SHA256_F4 توقيعات محدّدة ويقدّم
أفضل أداء للتحقّق (ولكنّ التوقيع أبطأ بكثير من
ECDSA_P256 أو ED25519).
الحد الأدنى من ضمانات الأمان
- يمكن أن تكون البيانات التي سيتم التوقيع عليها بأي طول عشوائي.
- مستوى أمان 128 بت ضد هجمات الرسائل المختارة التكيُّفية للأنظمة المستندة إلى منحنى
الإقليدي
- مستوى أمان 112 بت ضد هجمات الرسائل المُختارة التكيُّفية للخطط المستندة إلى RSA (يسمح بمفاتيح 2048 بت)
قابلية التغيير
يكون مخطّط التوقيع قابلاً للتلاعب إذا كان بإمكان المهاجم إنشاء توقيع مختلف صالح
لرسالة تم توقيعها من قبل. على الرغم من أنّ هذا ليس مشكلة في معظم
السيناريوهات، يفترض المبرمجون في بعض الحالات ضمنيًا أنّ التوقيعات الصالحة
فريدة، ويمكن أن يؤدي ذلك إلى نتائج غير متوقّعة.
مثال على حالة استخدام
أريد التوقيع الرقمي على البيانات.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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)."]]
