قالب سیم تینک

این صفحه فرمت سیم تینک را برای کلیدها و خروجی های اولیه توضیح می دهد. هدف این اسناد رمزنگارانی است که می‌خواهند زبان‌های دیگری را به Tink اضافه کنند و نگهبانان دیگر کتابخانه‌های رمزنگاری سطح بالا که خواهان حالت سازگار با سیم هستند. برای مخاطبان عام در نظر گرفته نشده است.

سریال سازی کیست

تینک از پروتوباف گوگل برای سریال سازی مجموعه کلیدهای خود استفاده می کند.

• مجموعه کلیدهای سریالی باینری یک مجموعه اولیه کلیدهای سریالی است که در tink.proto تعریف شده است. ویژگی مقدار KeyData یک کلید یک پروتو سریالی از نوع کلید مربوطه است.
• مجموعه کلیدهای سریالی JSON یک مجموعه کلیدی است که در قالب JSON سریال شده است. توجه داشته باشید که مقدار KeyData هنوز یک پروتوی سریالی باینری است.
• مجموعه کلیدهای رمزگذاری شده یک پروتو رمزگذاری شده سریالی است که در tink.proto تعریف شده است. این شامل یک مجموعه کلید سریالی باینری رمزگذاری شده و به صورت اختیاری برخی فراداده KeysetInfo رمزگذاری نشده است.

پیشوند خروجی Tink

بیشتر Tink های اولیه از یک پیشوند خروجی 5 بایتی پشتیبانی می کنند که شامل موارد زیر است:

• نسخه 1 بایتی: 0x01
• راهنمایی کلید 4 بایت: این شناسه کلید کلید استفاده شده است.

برخی از کلیدهای قدیمی ممکن است از نسخه بایت 0x00 نیز پشتیبانی کنند.

توجه داشته باشید که این پیشوند احراز هویت نیست و نمی توان برای اهداف امنیتی به آن اعتماد کرد. Tink از آن به عنوان یک اشاره برای سرعت بخشیدن به رمزگشایی یا تأیید استفاده می کند.

AEAD

به طور کلی، Tink متن های رمزی AEAD را به صورت زیر قالب بندی می کند:

prefix || IV || ciphertext || tag

مگر اینکه در RFC مربوطه مشخص شده باشد. prefix یا خالی است یا پیشوند خروجی Tink 5 بایتی است.

AES-CTR-HMAC

برای AES-CTR-HMAC، Tink MAC را با داده های مرتبط (AD) به صورت زیر محاسبه می کند:

AD || IV || ciphertext || bitlen(AD)

که در آن bitlen(AD) طول AD در بیت است که به صورت عدد صحیح بدون علامت 64 بیتی بزرگ-اندیان نمایش داده می شود. این طرح HMAC از پیش‌نویس AES-CBC-HMAC از مک‌گرو پیروی می‌کند.

AEAD قطعی

تینک RFC 5297 را برای AES-SIV پیاده سازی می کند و بردار اولیه سازی مصنوعی (SIV) را در ابتدای متن رمزگذاری می کند. اولیه ممکن است یک پیشوند خروجی Tink 5 بایتی اضافه کند.

در حالی که RFC 5297 لیستی از داده‌های مرتبط را پشتیبانی می‌کند، Tink فقط از یک داده مرتبط پشتیبانی می‌کند، که مربوط به فهرستی با یک عنصر در RFC 5297 است. داده‌های مرتبط خالی، فهرستی با یک عنصر خالی است و نه یک لیست خالی.

پخش جریانی AEAD

به AES-CTR HMAC و AES-GCM-HKDF مراجعه کنید.

رمزگذاری پاکت نامه

رمزگذاری پاکت، داده ها را با یک کلید رمزگذاری داده DEK با استفاده از اصول اولیه AEAD Tink رمزگذاری می کند. رمزگذاری به صورت زیر عمل می کند:

• یک DEK جدید با استفاده از یک الگوی کلیدی داده شده (یا پارامترهای کلیدی) تولید می شود.
• DEK به یک رشته بایت سریال تبدیل می شود. فرمت سریال سازی پروتکل سریال سازی بافر پروتکل از نوع پروتو. برای مثال، این یک پیام بافر پروتکل AesGcmKey سریالی است که در aes_gcm.proto برای DEK از نوع کلید AES GCM تعریف شده است. برای نحوه سریال سازی بافر پروتکل سریال سازی بافر پروتکل را ببینید.
• DEK سریال شده توسط یک ارائه دهنده خارجی (مثلاً GCP) به یک encrypted DEK رمزگذاری می شود.
• DEK برای رمزگذاری متن ساده با داده های مرتبط در ciphertext استفاده می شود. بنابراین ciphertext دقیقاً همان قالب اولیه AEAD مربوط به DEK را دارد.

فرمت خروجی رمزگذاری پاکت به شرح زیر است:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length 4 بایت است، طول encrypted DEK را به عنوان یک عدد صحیح بزرگ-اندیان 32 بیتی ذخیره می کند.

MAC

Tink از RFCهای مربوطه پیروی می کند. Primitives ممکن است یک پیشوند خروجی 5 بایتی Tink به تگ اضافه کند.

مجموعه PRF

Tink از RFCهای مربوطه پیروی می کند. توجه داشته باشید که برای PRF Set نوع کلید با نوع کلید MAC همان الگوریتم با در نظر نگرفتن طول خروجی متفاوت است. کلیدهای PRF Set هرگز پیشوند خروجی Tink اضافه نمی کنند. این تضمین می کند که خروجی در واقع یک PRF است.

رمزگذاری ترکیبی

قالب کلی سیم برای رمزگذاری هیبریدی Tink به شرح زیر است:

prefix || encapsulated_key || encrypted_data

prefix یا خالی است یا پیشوند خروجی Tink 5 بایتی است. هر نوع کلید حاوی اطلاعاتی درباره تعداد بایت برای تجزیه و نحوه تجزیه آن بایت ها از encapsulated_key است.

HPKE (رمزگذاری کلید عمومی ترکیبی)

Tink از استاندارد HPKE تعریف شده در RFC 9180 پیروی می کند. یک مجموعه رمز HPKE شامل سه نمونه اولیه زیر است.

• مکانیسم کپسولاسیون کلید (KEM)
• تابع مشتق کلید (KDF)
• رمزگذاری تأیید شده با داده های مرتبط (AEAD)

استاندارد HPKE فرمت سیم عمومی را در RFC 9180، بخش 10 تعریف نمی کند. پیاده سازی HPKE Tink از مقادیر encapsulated_key و encrypted_data زیر استفاده می کند.

• encapsulated_key
  • کلید عمومی سریال فرستنده
  • به عنوان enc در RFC 9180، بخش 4.1 تعریف شده است
  • قالب توسط HPKE KEM خاص مورد استفاده تعیین می شود
• encrypted_data
  • متن رمزی و برچسب (یعنی، ciphertext || tag بدون IV)
  • به عنوان ct در RFC 9180، بخش 4 تعریف شده است
  • قالب تعیین شده توسط HPKE AEAD خاص مورد استفاده

X25519 KEM مبتنی بر Diffie-Hellman

برای X25519 DHKEM، مقدار enc کلید عمومی 32 بایتی Diffie-Hellman فرستنده است.

ECIES-AEAD-HKDF

برای اجرای ECIES-AEAD-HKDF Tink، encapsulated_key خروجی مکانیسم کپسوله سازی کلید (KEM) و encrypted_data خروجی مکانیسم کپسوله سازی داده ها (DEM) است.

KEM

بسته به نوع کلید، Tink از نقاط منحنی بیضوی فشرده و غیرفشرده استفاده می‌کند که از استانداردهای رمزگذاری RFC 8422 / ANSI.X9-62.2005 پیروی می‌کند. برای نقاط فشرده نشده، بایت 0x04 با مختصات x و y به عنوان اعداد صحیح با اندازه ثابت دنبال می شود. برای مختصات فشرده، بایت 0x02 یا 0x03 و مختصات x به عنوان یک عدد صحیح با اندازه ثابت استفاده می شود. برای X25519 ، از تعریف RFC 7748 استفاده شده است ( مختصات x به عنوان عدد صحیح اندازه ثابت).

DEM

برای encrypted_data ، Tink از همان قالب AEAD استفاده می‌کند. این شامل مشخص کردن یک IV است.

مشتق کلید

ابتدا مختصات x x_ss نقطه مشترک محاسبه می شود. سپس کلید AEAD به صورت زیر تنظیم می شود:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

که در آن encapsulated_key خروجی کامل KEM به صورت بایت است.

امضای دیجیتال

Tink از RFCهای مربوطه پیروی می کند. Primitives ممکن است یک پیشوند خروجی 5 بایتی Tink را به تگ ایجاد شده اضافه کند.

ECDSA

بسته به فیلد EcdsaSignatureEncoding در کلید، فرمت یک امضای ECDSA یا IEEE P1363 یا ASN.1 DER است.

فرمت امضای IEEE P1363 r || s است r || s ، که در آن r و s دارای لایه صفر هستند و اندازه آن در بایت ها به ترتیب منحنی است. به عنوان مثال، برای منحنی NIST P-256 ، r و s صفر تا 32 بایت هستند.

امضای DER با استفاده از ASN.1 کدگذاری می شود:

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

به طور خاص، رمزگذاری این است:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink از بهترین شیوه‌ها برای تأیید امضا پیروی می‌کند، تنها با پذیرش امضاهای ECDSA کدگذاری‌شده DER (امضای کدگذاری‌شده BER جایگزین نامعتبر هستند).

این به جلوگیری از حملات چکش‌خواری امضا، که اغلب بر سیستم‌های ارزهای دیجیتال تأثیر می‌گذارد، کمک می‌کند.