تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
من المهم أن يتصرف تطبيق Tink "بنفس الطريقة" في جميع لغات البرمجة.
هذا المفهوم ليس مباشرًا، ولكنه الأهم:
للحفاظ على الاتّساق، يستخدم تطبيق Tink الاختبارات المتعدّدة اللغات التي يمكن العثور عليها في مستودع GitHub المتعدد اللغات.
تُستخدَم هذه الاختبارات للتحقّق من اتّساق اللغات المختلفة وقابلية توافقها معها.
ومع ذلك، فإن تعريف الاتساق ليس مباشرًا كما يتوقعه المرء.
وبالتالي، تقدّم هذه الصفحة تعريفًا للعمل لدينا. في الأساس، يوفر Tink
نوعين من الاتساق:
اتّساق التقييم: بالنسبة إلى مجموعة مفاتيح معيّنة1، إذا نجح إنشاء المجموعة الأساسية في لغتَين، ستتّسم الإجراءات بالعمل نفسه.
بشكل عام، يوفر Tink واجهات برمجة التطبيقات التالية:
التلاعب بمجموعات المفاتيح: يوفّر تطبيق Tink واجهات برمجة تطبيقات لإضافة مفاتيح جديدة إلى مجموعة مفاتيح وإزالة مفاتيح من مجموعة مفاتيح وتغيير المفتاح الأساسي في مجموعة مفاتيح.
تسلسل مجموعة المفاتيح: يوفّر تطبيق Tink واجهات برمجة التطبيقات لإنشاء تسلسل لمجموعة مفاتيح على تسلسل من وحدات البايت، وتحليل مجموعة مفاتيح عكسيًا من تسلسل وحدات بايت.
إنشاء أولي: يوفر Tink واجهة برمجة تطبيقات لإنشاء واجهة
لمجموعة أساسية من مجموعة مفاتيح. على سبيل المثال، لإنشاء كائن Aead من مجموعة مفاتيح في Java، يستدعي المستخدم keysetHandle.getPrimitive(Aead.class, config).
الاستخدام الأولي: توفر الواجهة التي يتم إنشاؤها في خطوة الإنشاء الأساسية واجهة برمجة تطبيقات لتنفيذ عمليات التشفير.
هناك سؤالان مهمان يجب طرحهما حول واجهات برمجة التطبيقات هذه:
الإنشاء:
بالنسبة إلى مجموعة مفاتيح متسلسلة ولغة وبيانات أساسية،
هل من الممكن إنشاء المجموعة الأساسية من مجموعة المفاتيح هذه باللغة؟
التقييم:
إذا كان من الممكن إنشاء مجموعة أولية بلغة ما من مجموعة مفاتيح معيّنة،
فكيف يعمل الكائن الأساسي؟
من المهم ملاحظة أن Tink لا يوفر الاتساق عند تحليل مجموعة المفاتيح. على سبيل المثال، من الممكن أن يستخدم Tink C++
نجح في تحليل مجموعات المفاتيح التي تحتوي على مفاتيح CHACHA20-POLY1305 على الرغم من
عدم تنفيذ عمليات AEAD في Tink؛
تحليل مجموعات المفاتيح التي تحتوي على مفاتيح يبلغ طولها 1 بايت بنجاح، والتي ستفشل في جميع عمليات التشفير.
قد تتغير هذه السلوكيات في الإصدارات الثانوية.
اتساق التقييم
يعتبر اتّساق التقييم أهم من أي اتساق في عملية الإنشاء: إذا تعذّر على AEAD في لغة Java فك تشفير تشفير AEAD في لغة C++ ، يواجه المستخدمون مشكلة خطيرة.
بشكل عام، يهدف Tink إلى أن يكون متسقًا بالطريقة الواضحة بالنسبة إلى الأساسيات. على سبيل المثال، إذا قام برنامج ثنائي C++ بحساب توقيع باستخدام public_key_sign->Sign(data)، فمن المتوقع نجاح استدعاء التحقق المقابل من لغة Java (publicKeyVerify.verify(signature, data)).
ومع ذلك، حتى هنا هناك بعض المحاذير. على سبيل المثال، نوع الإرجاع aead.Encrypt في Java هو byte[].
وفقًا للفقرة 10.7 من مواصفات لغة Java (JLS)، يكون طول المصفوفة من النوع int والذي يمكن أن يصل إلى 2147483647 كحد أقصى وفقًا لـ §JLS 4.2.1. وبالتالي،
يفشل تشفير صفيف بطول 2147483647 في Java: يحتوي التشفير على بعض النفقات العامة، ما يعني أن الناتج سيكون طويلاً جدًا. ومع ذلك، يسمح التشفير في اللغات الأخرى
بنجاح هذه المدخلات.
وبالتالي، يوفر Tink اتساق التقييم:
بالنسبة لمجموعة مفاتيح معينة، إذا نجح إنشاء المجموعة الأولية بلغتين، فستتصرف
نفسها.
والاستثناء هو أن بعض العمليات قد تفشل في بعض الظروف الاستثنائية.
اتساق عملية الإنشاء
لا ينجح إنشاء المجموعات الأولية دائمًا لجميع مجموعات المفاتيح. على سبيل المثال،
لا يسمح Tink للمستخدمين بإنشاء AesSivKey إذا كان طول المادة الأساسية
128 بت.
ومع ذلك، يوفر Tink الاتساق على النحو التالي: إذا كانت كلتا اللغتين تدعمان نوعًا رئيسيًا، تتزامن مجموعة المفاتيح التي يمكن إنشاء المجموعة الأساسية لها. وبالطبع، إذا كانت اللغة لا تدعم نوعًا رئيسيًا، فلا يمكن إنشاء أي عنصر أولي.
يعد اتساق الإنشاء أقل أهمية من اتساق التقييم،
وهناك استثناءات لهذه القاعدة أكثر من اتساق التقييم.
وقد تمّ توثيق هذه القيود في
قائمة أنواع المفاتيح المتوافقة.
على سبيل المثال، بالنسبة إلى نوع المفتاح ECIES Tink توفر اختيارًا للمنحنى الإهليلجي
الذي سيتم استخدامه للاتفاق على المفتاح، لكن Java لا تدعم X25519. وبالتالي، فشل إنشاء مفتاح باستخدام X25519 في Java.
في هذا المستند، نستخدم المصطلح Keyset للدلالة على الكائن الذي يسمى KeysetHandle في معظم اللغات.↩
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eTink aims for cross-language consistency, ensuring the same behavior for a given keyset if primitive creation succeeds in multiple languages.\u003c/p\u003e\n"],["\u003cp\u003eTink defines two types of consistency: Evaluation Consistency (primitives behave the same across languages) and Creation Consistency (primitive creation success aligns with supported key types).\u003c/p\u003e\n"],["\u003cp\u003eWhile Tink strives for consistency, exceptions exist due to language limitations or specific key type support, which are documented for transparency.\u003c/p\u003e\n"],["\u003cp\u003eTink prioritizes Evaluation Consistency, as mismatched encryption/decryption between languages would pose significant issues.\u003c/p\u003e\n"],["\u003cp\u003eKeyset parsing consistency is not guaranteed, with behaviors subject to change across minor versions.\u003c/p\u003e\n"]]],["Tink ensures consistent cryptographic behavior across languages through evaluation and creation consistency. Evaluation consistency guarantees that if a primitive is created from a keyset in multiple languages, it will function identically. Creation consistency ensures that if two languages support a specific key type, primitive creation will succeed or fail for the same set of keys. Tink uses cross-language tests to maintain these consistencies and documents limitations in supported key types.\n"],null,["# Consistency\n\nIt's important that Tink behaves \"the same\" in all programming languages.\nThis concept is not straightforward, but most crucially:\n| **Key Point:** Tink provides evaluation consistency: For a given keyset, if primitive creation succeeds in two languages, the primitive behaves the same.\n\nTo maintain consistency, Tink uses cross-language tests which\ncan be found in the [cross-language GitHub\nrepository](https://github.com/tink-crypto/tink-cross-lang-tests).\nThese tests verify the consistency and interoperability of different languages.\n\nHowever, defining consistency is not as straightforward as one would expect.\nHence, this page provides our working definition. Basically, Tink provides\ntwo types of consistency:\n\n- **[Evaluation consistency:](#evaluation_consistency)** For a given keyset^[1](#fn1)^, if creation of the primitive succeeds in two languages, they behave the same.\n- **[Creation consistency:](#creation_consistency)** Creation of a primitive succeeds in a language if the language supports all key types in a keyset, as documented in [our list of supported key types](/tink/supported-key-types).\n\nContext\n-------\n\nOn a high level, Tink provides the following APIs:\n\n- **Keyset manipulation:** Tink provides APIs to add new keys to a keyset,\n remove keys from a keyset, and change the primary key in a keyset.\n\n- **Keyset serialization:** Tink provides APIs to serialize a keyset to\n a sequence of bytes, and conversely parse a keyset from a sequence of bytes.\n\n- **Primitive creation:** Tink provides an API to create an interface for\n a primitive from a keyset. For example, to create an `Aead` object from a\n keyset in Java, the user calls `keysetHandle.getPrimitive(Aead.class, config)`.\n\n- **Primitive usage:** The interface produced in the primitive creation step\n provides an API to perform cryptographic operations.\n\nThere are two important questions to ask about these APIs:\n\n- **Creation:**\n For a given serialized keyset, language, and primitive,\n is it possible to create the primitive from this keyset in the language?\n\n- **Evaluation:**\n If a primitive can be created in some language from a given\n keyset, how does the primitive object behave?\n\nIt is important to note that Tink does not provide consistency when parsing a\nkeyset. For example, it is possible that Tink C++\n\n- successfully parses keysets containing CHACHA20-POLY1305 keys, even though CHACHA20-POLY1305 AEAD operations are not implemented in Tink;\n- successfully parses keysets with keys that have a length of 1-byte, which will fail in all cryptographic operations.\n\nThese behaviors may change in minor versions.\n\nEvaluation consistency\n----------------------\n\nConsistency of evaluation is more important than any consistency in the creation\nprocess: if an AEAD in Java cannot decrypt the encryption of the AEAD in C++,\nusers have a serious problem.\n\nIn general, Tink aims to be consistent in the obvious way for primitives. For\nexample, if a C++ binary computes a signature\nwith `public_key_sign-\u003eSign(data)`, the corresponding Java verification\ncall `publicKeyVerify.verify(signature, data)` is expected to succeed.\n\nHowever, even here there are some caveats. For example,\nthe return type of `aead.Encrypt` in Java is a `byte[]`.\nPer Java Language Specification (JLS) §10.7, the length of an array is of\ntype `int` which per §JLS 4.2.1 can be a maximum of 2147483647. Hence,\nencryption of an array with a length of 2147483647 fails in Java: encryption\nhas some overhead, meaning\nthe output would be too long. Nevertheless, in other languages encryption\nis allowed to succeed for such inputs.\n\nHence, Tink provides evaluation consistency:\nFor a given keyset, if creation of the primitive succeeds in\ntwo languages, they behave the same.\n\nThe exception is that some operations may fail in some exceptional\ncircumstances.\n\nCreation consistency\n--------------------\n\nCreation of primitives does not always succeed for all keysets. For example,\nTink does not allow users to create an AesSivKey if the key material has a\nlength of 128 bits.\n\nNevertheless, Tink provides consistency as follows: if two languages both\nsupport a key type, the set of keys for which the primitive can be created\ncoincides. Of course, if a language does not support a key type, then no\nprimitive object can be created.\n\nCreation consistency is less important than evaluation consistency, and\nthere are more exceptions to this rule than for evaluation consistency.\nThese limitations are documented on\n[our list of supported key types](/tink/supported-key-types).\nFor example, for key type ECIES Tink offers a choice of which elliptic curve\nto use for key agreement, but Java does not support X25519. Hence,\ncreation of a key using X25519 in Java fails. \n\n*** ** * ** ***\n\n1. In this document, we use the term `Keyset` to denote the object called\n `KeysetHandle` in most languages. [↩](#fnref1)"]]
