با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این مهم است که تینک در همه زبان های برنامه نویسی "یکسان" رفتار کند. این مفهوم ساده نیست، اما مهمتر از همه:
برای حفظ ثبات، Tink از تست های بین زبانی استفاده می کند که در مخزن بین زبانی GitHub یافت می شود. این آزمون‌ها سازگاری و قابلیت همکاری زبان‌های مختلف را تأیید می‌کنند.
با این حال، تعریف سازگاری آنطور که انتظار می رود ساده نیست. از این رو، این صفحه تعریف کاری ما را ارائه می دهد. اساسا، Tink دو نوع سازگاری را ارائه می دهد:
سازگاری ارزیابی: برای یک مجموعه کلیدی 1 ، اگر ایجاد اولیه در دو زبان موفقیت آمیز باشد، رفتار آنها یکسان است.
دستکاری کیست: تینک APIهایی را برای افزودن کلیدهای جدید به مجموعه کلید، حذف کلیدها از مجموعه کلیدها و تغییر کلید اصلی در مجموعه کلیدها فراهم می کند.
سریال‌سازی Keyset: Tink APIهایی را برای سریال‌سازی یک مجموعه کلید به دنباله‌ای از بایت‌ها و بالعکس یک مجموعه کلید از یک دنباله بایت را ارائه می‌دهد.
ایجاد اولیه: Tink یک API برای ایجاد یک رابط برای یک اولیه از یک مجموعه کلید ارائه می دهد. به عنوان مثال، برای ایجاد یک شی Aead از یک مجموعه کلید در جاوا، کاربر keysetHandle.getPrimitive(Aead.class, config) را فراخوانی می کند.
استفاده اولیه: رابط تولید شده در مرحله ایجاد اولیه یک API برای انجام عملیات رمزنگاری فراهم می کند.
دو سوال مهم در مورد این APIها وجود دارد:
ایجاد: برای یک مجموعه کلید سریالی، زبان، و ابتدایی، آیا امکان ایجاد اولیه از این مجموعه کلید در زبان وجود دارد؟
ارزیابی: اگر بتوان در زبانی از یک مجموعه کلیدی یک کلید اولیه ایجاد کرد، شی اولیه چگونه رفتار می کند؟
توجه به این نکته مهم است که Tink هنگام تجزیه یک مجموعه کلید سازگاری ایجاد نمی کند. به عنوان مثال، ممکن است که Tink C++
با موفقیت مجموعه‌های کلیدی حاوی کلیدهای CHACHA20-POLY1305 را تجزیه می‌کند، حتی اگر عملیات CHACHA20-POLY1305 AEAD در Tink پیاده‌سازی نشده باشد.
با موفقیت مجموعه کلیدها را با کلیدهایی با طول 1 بایت تجزیه می کند که در تمام عملیات رمزنگاری با شکست مواجه می شود.
این رفتارها ممکن است در نسخه های کوچک تغییر کند.
سازگاری ارزیابی
سازگاری ارزیابی از هر گونه سازگاری در فرآیند ایجاد مهمتر است: اگر یک AEAD در جاوا نتواند رمزگذاری AEAD را در C++ رمزگشایی کند، کاربران با مشکل جدی مواجه خواهند شد.
به طور کلی، هدف تینک این است که به روشی واضح برای افراد اولیه سازگار باشد. به عنوان مثال، اگر یک باینری ++C امضایی را با public_key_sign->Sign(data) محاسبه کند، انتظار می‌رود که فراخوانی تأیید Java مربوطه publicKeyVerify.verify(signature, data) موفق شود.
با این حال، حتی در اینجا نیز برخی از هشدارها وجود دارد. برای مثال، نوع بازگشتی aead.Encrypt در جاوا یک byte[] . طبق مشخصات زبان جاوا (JLS) §10.7، طول یک آرایه از نوع int است که در §JLS 4.2.1 حداکثر می تواند 2147483647 باشد. بنابراین، رمزگذاری آرایه ای با طول 2147483647 در جاوا ناموفق است: رمزگذاری دارای مقداری سربار، به این معنی که خروجی بیش از حد طولانی خواهد بود. با این وجود، در زبان های دیگر، رمزگذاری برای چنین ورودی هایی مجاز است.
از این رو، Tink ثبات ارزیابی را فراهم می کند: برای یک مجموعه کلیدی معین، اگر ایجاد اولیه در دو زبان موفقیت آمیز باشد، رفتار آنها یکسان است.
استثنا این است که برخی از عملیات ممکن است در برخی شرایط استثنایی شکست بخورند.
ثبات خلقت
ایجاد primitives همیشه برای همه مجموعه کلیدها موفق نیست. به عنوان مثال، Tink به کاربران اجازه ایجاد AesSivKey را نمی دهد اگر طول ماده کلیدی 128 بیت باشد.
با این وجود، Tink یکپارچگی را به شرح زیر ارائه می‌کند: اگر دو زبان هر دو از یک نوع کلید پشتیبانی می‌کنند، مجموعه کلیدهایی که می‌توان برای آنها کلید اولیه ایجاد کرد منطبق است. البته، اگر زبانی از یک نوع کلید پشتیبانی نکند، آنگاه هیچ شی اولیه ای نمی توان ایجاد کرد.
سازگاری ایجاد اهمیت کمتری نسبت به ثبات ارزیابی دارد و استثنائات بیشتری نسبت به ثبات ارزشیابی در این قاعده وجود دارد. این محدودیت‌ها در فهرست انواع کلیدهای پشتیبانی شده ما ثبت شده‌اند. به عنوان مثال، برای نوع کلید ECIES Tink انتخابی را ارائه می دهد که از کدام منحنی بیضوی برای توافق کلید استفاده کند، اما جاوا از X25519 پشتیبانی نمی کند. از این رو، ایجاد یک کلید با استفاده از X25519 در جاوا با شکست مواجه می شود.
در این سند، ما از عبارت 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)"]]
