ثبات

این مهم است که تینک در همه زبان های برنامه نویسی "یکسان" رفتار کند. این مفهوم ساده نیست، اما مهمتر از همه:

برای حفظ ثبات، Tink از تست های بین زبانی استفاده می کند که در مخزن بین زبانی GitHub یافت می شود. این آزمون‌ها سازگاری و قابلیت همکاری زبان‌های مختلف را تأیید می‌کنند.

با این حال، تعریف سازگاری آنطور که انتظار می رود ساده نیست. از این رو، این صفحه تعریف کاری ما را ارائه می دهد. اساسا، Tink دو نوع سازگاری را ارائه می دهد:

متن نوشته

در سطح بالا، Tink API های زیر را ارائه می دهد:

  • دستکاری کیست: تینک 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 در جاوا با شکست مواجه می شود.

  1. در این سند، ما از عبارت Keyset برای نشان دادن شی ای به نام KeysetHandle در بیشتر زبان ها استفاده می کنیم. ↩