قالب سیم تینک

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

سریال‌سازی مجموعه کلید

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

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

پیشوند خروجی تینک

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

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

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

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

AEAD

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

prefix || IV || ciphertext || tag

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

AES-CTR-HMAC

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

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

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

AEAD قطعی

تینک RFC 5297 را برای AES-SIV پیاده‌سازی می‌کند و بردار اولیه مصنوعی (SIV) را در ابتدای متن رمز قرار می‌دهد. ممکن است یک پیشوند خروجی تینک ۵ بایتی به آن اضافه شود.

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

پخش آنلاین AEAD

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

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

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

• یک DEK جدید با استفاده از یک الگوی کلید (یا پارامترهای کلیدی) داده شده تولید می‌شود.
• DEK به صورت یک رشته بایتی سریالی می‌شود. فرمت سریالی‌سازی، سریالی‌سازی بافر پروتکل از نوع کلید proto است. برای مثال، این یک پیام سریالی‌سازی شده بافر پروتکل 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 ۴ بایت است که طول encrypted DEK را به عنوان یک عدد صحیح ۳۲ بیتی big-endian ذخیره می‌کند.

مک

تینک از RFC های مربوطه پیروی می‌کند. اولیه‌ها ممکن است یک پیشوند خروجی تینک ۵ بایتی به تگ اضافه کنند.

مجموعه PRF

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

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

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

prefix || encapsulated_key || encrypted_data

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

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

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

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

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

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

KEM مبتنی بر دیفی-هلمن X25519

برای X25519 DHKEMs، مقدار enc کلید عمومی ۳۲ بایتی دیفی-هلمن فرستنده است.

ECIES-AEAD-HKDF

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

کِم

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

مدل‌سازی سه‌بعدی (DEM)

برای encrypted_data ، تینک از همان قالب 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 به صورت بایت است.

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

تینک از RFC های مربوطه پیروی می‌کند. اولیه‌ها ممکن است یک پیشوند خروجی تینک ۵ بایتی به برچسب تولید شده اضافه کنند.

ECDSA

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

قالب امضای IEEE P1363 به صورت 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

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

این امر به جلوگیری از حملات انعطاف‌پذیری امضا، که اغلب بر سیستم‌های ارز دیجیتال تأثیر می‌گذارند ، کمک می‌کند.

مقادیر پیش هش Mu ML-DSA خارجی

تابع اولیه‌ی Prehash یک پیام را به یک مقدار prehash تبدیل می‌کند که تابع اولیه‌ی SignPrehash سپس آن را امضا می‌کند. برای ML-DSA در حالت External Mu ، همانطور که در RFC 9881 توضیح داده شده است، مقدار prehash برابر با ۶۹ ​​بایت با طرح‌بندی زیر است:

0xff || key_id (4 bytes, big-endian) || mu (64 bytes)

• mu نماینده پیام ML-DSA است که به صورت SHAKE256(tr || 0x00 || 0x00 || message, 64) محاسبه می‌شود، که در آن tr هش ۶۴ بایتی کلید عمومی، 0x00 اول جداکننده دامنه FIPS 204 برای ML-DSA خالص و 0x00 دوم طول رشته زمینه (خالی) است. از آنجا که tr از کلید عمومی مشتق شده است، mu به صورت رمزنگاری به آن کلید متصل است -- اگرچه بررسی اتصال نیاز به پیام اصلی دارد.
• پیشوند ۵ بایتی، فریم‌بندی Tink است و بخشی از mu نیست. این پیشوند مقدار prehash را با یک کلید خاص مرتبط می‌کند، به طوری که SignPrehash می‌داند با کدام کلید امضا کند و می‌تواند مقدار prehash را که کلیدی برای آن ندارد، رد کند. این پیشوند یک فراداده ساده است و هیچ چیز را از نظر رمزنگاری به هم متصل نمی‌کند: هر کسی می‌تواند آن را بازنویسی کند.

امضا، هر ورودی که دقیقاً ۶۹ بایت نباشد، با 0xff شروع نشود، یا شناسه کلید آن با یک کلید فعال در مجموعه کلیدهایش مطابقت نداشته باشد را رد می‌کند.