با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
رمزگذاری اولیه ترکیبی، کارایی رمزگذاری متقارن را با راحتی رمزنگاری کلید عمومی (نامتقارن) ترکیب می کند. هر کسی می‌تواند داده‌ها را با استفاده از کلید عمومی رمزگذاری کند، اما فقط کاربرانی که دارای کلید خصوصی هستند می‌توانند داده‌ها را رمزگشایی کنند.
برای رمزگذاری ترکیبی، فرستنده یک کلید متقارن جدید برای رمزگذاری متن ساده هر پیام ایجاد می کند تا یک متن رمزی تولید کند. آن کلید متقارن با کلید عمومی گیرنده محصور شده است. برای رمزگشایی ترکیبی، کلید متقارن توسط گیرنده کپسوله می‌شود و سپس برای رمزگشایی متن رمز برای بازیابی متن اصلی استفاده می‌شود. برای جزئیات در مورد نحوه ذخیره یا انتقال متن رمزنگاری شده همراه با کپسوله کردن کلید، به قالب سیم رمزگذاری هیبریدی Tink مراجعه کنید.
رمزگذاری ترکیبی دارای ویژگی های زیر است:
رازداری : هیچ کس نمی تواند اطلاعاتی در مورد متن رمزگذاری شده (به جز طول آن) به دست آورد، مگر اینکه به کلید خصوصی دسترسی داشته باشد.
عدم تقارن : رمزگذاری متن رمز را می توان با کلید عمومی انجام داد، اما برای رمزگشایی، کلید خصوصی مورد نیاز است.
تصادفی سازی : رمزگذاری تصادفی است. دو پیام با متن ساده یکسان، متن رمزی یکسانی را نشان نمی دهند. این امر مانع از این می شود که مهاجمان بدانند کدام متن رمزی با یک متن ساده مطابقت دارد.
رمزگذاری ترکیبی در Tink به عنوان یک جفت اولیه نشان داده می شود:
HybridEncrypt برای رمزگذاری
HybridDecrypt برای رمزگشایی
پارامتر اطلاعات زمینه
علاوه بر متن ساده، رمزگذاری ترکیبی یک پارامتر اضافی به context_info را می پذیرد، که معمولاً داده های عمومی ضمنی از متن است، اما باید به متن رمزی حاصل پیوند داده شود. این بدان معنی است که متن رمز به شما امکان می دهد صحت اطلاعات متن را تأیید کنید، اما هیچ تضمینی برای محرمانه بودن یا اصالت آن وجود ندارد. اطلاعات زمینه واقعی می‌تواند خالی یا پوچ باشد، اما برای اطمینان از رمزگشایی صحیح متن رمزی حاصل، باید همان مقدار اطلاعات زمینه برای رمزگشایی ارائه شود.
یک پیاده سازی مشخص از رمزگذاری ترکیبی می تواند اطلاعات زمینه را به روش های مختلف به متن رمز متصل کند، به عنوان مثال:
از context_info به عنوان ورودی داده مرتبط برای رمزگذاری متقارن AEAD استفاده کنید (ر.ک. RFC 5116 ).
از context_info به عنوان ورودی «CtxInfo» برای HKDF استفاده کنید (اگر پیاده‌سازی از HKDF به عنوان تابع مشتق کلید استفاده می‌کند، RFC 5869 را ببینید).
یک نوع کلید را انتخاب کنید
توصیه می کنیم برای اکثر موارد استفاده از نوع کلید DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM استفاده کنید. این نوع کلید استاندارد رمزگذاری کلید عمومی ترکیبی (HPKE) را همانطور که در RFC 9180 مشخص شده است، پیاده سازی می کند. HPKE از یک مکانیسم کپسوله کردن کلید (KEM)، یک تابع مشتق کلید (KDF) و یک الگوریتم رمزگذاری احراز هویت شده با داده های مرتبط (AEAD) تشکیل شده است.
DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM به طور خاص از:
KEM: Diffie–Hellman روی Curve25519 با HKDF-SHA-256 برای استخراج راز مشترک.
KDF: HKDF-SHA-256 برای استخراج زمینه فرستنده و گیرنده.
AEAD: AES-256-GCM با nonces 12 بایتی بر اساس استاندارد HPKE تولید شده است.
سایر انواع کلیدهای HPKE پشتیبانی شده شامل موارد زیر است، اما به آنها محدود نمی شود:
برای جزئیات بیشتر در مورد انتخاب الگوریتم برای KEM، KDF و AEAD، RFC 9180 را ببینید.
اگرچه دیگر توصیه نمی شود، اما Tink از برخی تغییرات ECIES همانطور که در استاندارد ISO 18033-2 Victor Shoup توضیح داده شده است، پشتیبانی می کند. برخی از انواع کلیدهای ECIES پشتیبانی شده در زیر فهرست شده اند:
تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eHybrid Encryption combines symmetric and asymmetric encryption for efficient and secure data exchange, allowing anyone to encrypt with a public key but only the private key holder to decrypt.\u003c/p\u003e\n"],["\u003cp\u003eIt ensures confidentiality through randomization and requires the same context information used during encryption for successful decryption.\u003c/p\u003e\n"],["\u003cp\u003eTink recommends the \u003ccode\u003eDHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM\u003c/code\u003e key type, implementing the HPKE standard for robust security.\u003c/p\u003e\n"],["\u003cp\u003eWhile providing privacy, Hybrid Encryption does not inherently guarantee authenticity, requiring separate sender authentication mechanisms if needed.\u003c/p\u003e\n"]]],["Hybrid Encryption combines public key cryptography's convenience with symmetric encryption's efficiency. Senders generate a symmetric key to encrypt each message's plaintext and encapsulate it with the recipient's public key. Recipients decapsulate the key and decrypt the ciphertext. It ensures secrecy, asymmetry, and randomization. It includes `context_info`, public data that binds to the ciphertext for integrity checks. `DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM` is recommended, implementing HPKE for key encapsulation, derivation, and authenticated encryption. It only provides privacy, not authenticity.\n"],null,["# Hybrid Encryption\n\nThe Hybrid Encryption primitive combines the efficiency of symmetric encryption\nwith the convenience of public key (asymmetric) cryptography. Anyone can encrypt\ndata using the public key, but only users with the private key can decrypt the\ndata.\n\nFor Hybrid Encryption, the sender generates a fresh symmetric key to encrypt the\nplaintext of each message to produce a ciphertext. That symmetric key is\n*encapsulated* with the recipient's public key. For Hybrid Decryption, the\nsymmetric key is *decapsulated* by the recipient and then used to decrypt the\nciphertext to recover the original plaintext. See [Tink Hybrid Encryption wire\nformat](/tink/wire-format#hybrid_encryption) for details on how to store or\ntransmit the ciphertext along with the key encapsulation.\n\nHybrid Encryption has the following properties:\n\n- **Secrecy**: No one is able to get any information about the encrypted plaintext (except the length), unless they have access to the private key.\n- **Asymmetry**: Encrypting the ciphertext can be done with the public key, but for decryption, the private key is required.\n- **Randomization**: The encryption is randomized. Two messages with the same plaintext will not yield the same ciphertext. This prevents attackers from knowing which ciphertext corresponds to a given plaintext.\n\nHybrid Encryption is represented in Tink as a pair of primitives:\n\n- *HybridEncrypt* for encryption\n- *HybridDecrypt* for decryption\n\n### Context info parameter\n\nIn addition to the plaintext, Hybrid Encryption accepts an extra parameter,\n`context_info`, which is usually public data implicit from the context, but\nshould be bound to the resulting ciphertext. This means that the ciphertext\nallows you to confirm the integrity of the context info but there are no\nguarantees for its secrecy or authenticity. The actual context info can be empty\nor null, but to ensure the correct decryption of the resulting ciphertext, the\nsame context info value must be provided for decryption.\n\nA concrete implementation of Hybrid Encryption can bind context info to the\nciphertext in various ways, for example:\n\n- Use `context_info` as associated data input for AEAD symmetric encryption (cf. [RFC 5116](https://tools.ietf.org/html/rfc5116)).\n- Use `context_info` as \"CtxInfo\" input for HKDF (if the implementation uses HKDF as key derivation function, cf. [RFC\n 5869](https://tools.ietf.org/html/rfc5869)).\n\n### Choose a key type\n\nWe recommend using the **`DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM`**\nkey type for most use cases. This key type implements the Hybrid Public Key\nEncryption (HPKE) standard as specified in [RFC\n9180](https://www.rfc-editor.org/rfc/rfc9180.html). HPKE consists\nof a key encapsulation mechanism (KEM), a key derivation function (KDF), and an\nauthenticated encryption with associated data (AEAD) algorithm.\n\n`DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM` specifically employs:\n\n- KEM: Diffie--Hellman over Curve25519 with HKDF-SHA-256 to derive the shared secret.\n- KDF: HKDF-SHA-256 to derive the sender and receiver context.\n- AEAD: AES-256-GCM with 12-byte nonces generated according to the HPKE standard.\n\nOther supported HPKE key types include, but are not limited to, the following:\n\n- `DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_128_GCM`\n- `DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_CHACHA20_POLY1305`\n- `DHKEM_P256_HKDF_SHA256_HKDF_SHA256_AES_128_GCM`\n- `DHKEM_P521_HKDF_SHA512_HKDF_SHA512_AES_256_GCM`\n\nSee [RFC 9180](https://www.rfc-editor.org/rfc/rfc9180.html) for\nmore details on the algorithm choices for the KEM, KDF, and AEAD.\n\nAlthough no longer recommended, Tink also supports some variations of ECIES as\ndescribed in [Victor Shoup's ISO 18033-2\nstandard](https://www.shoup.net/iso/). Some supported ECIES key\ntypes are listed below:\n\n- `ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM`\n- `ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM`\n- `ECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256`\n- `ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256`\n\n### Minimal properties\n\n| **Caution:** Hybrid Encryption only provides privacy, not authenticity. It is only secure if the recipient can accept anonymous messages or rely on other mechanisms to authenticate the sender.\n\n- Plaintext and context info can have arbitrary length (within the range 0..2^32^ bytes)\n- Secure against adaptive chosen ciphertext attacks\n- 128-bit security for elliptic curve based schemes\n\n### Example use cases\n\nSee I want to [exchange data](/tink/exchange-data)."]]
