Halaman ini menjelaskan format kabel Tink untuk kunci dan output primitif. Dokumentasi ini ditujukan bagi kriptografer yang ingin menambahkan bahasa lain ke Tink dan pengelola library kripto tingkat tinggi lainnya yang menginginkan mode yang kompatibel dengan kabel. Konten ini tidak ditujukan untuk audiens umum.
Serialisasi keyset
Tink menggunakan protobuf Google untuk membuat serialisasi keyset.
- Keyset serial biner adalah proto Keyset serial yang ditentukan di tink.proto. Properti nilai KeyData dari sebuah kunci adalah proto serial dari jenis kunci yang sesuai.
- Keyset serial JSON adalah proto Keyset yang diserialisasi dalam format JSON. Perhatikan bahwa nilai KeyData masih merupakan proto serial biner.
- Keyset terenkripsi adalah proto EncryptedKeyst serial yang ditentukan di tink.proto. File ini berisi keyset serial biner terenkripsi dan secara opsional beberapa metadata KeysetInfo yang tidak dienkripsi.
Awalan Output Tink
Sebagian besar primitif Tink mendukung awalan output 5 byte yang terdiri dari:
- Versi 1 byte:
0x01
- Petunjuk utama 4 byte: Ini adalah ID kunci dari kunci yang digunakan.
Beberapa kunci lama mungkin juga mendukung byte versi 0x00
.
Perlu diperhatikan bahwa awalan ini tidak diautentikasi dan tidak dapat diandalkan untuk tujuan keamanan. Tink menggunakannya sebagai petunjuk untuk mempercepat dekripsi atau verifikasi.
AEA
Secara umum, Tink memformat teks tersandi AEAD sebagai:
prefix || IV || ciphertext || tag
kecuali dinyatakan lain dalam RFC yang sesuai. prefix
kosong
atau awalan output Tink 5 byte.
AES-CTR-HMAC
Untuk AES-CTR-HMAC, Tink menghitung MAC dengan data terkait (AD) sebagai berikut:
AD || IV || ciphertext || bitlen(AD)
dengan bitlen(AD)
adalah panjang AD dalam bit yang direpresentasikan sebagai bilangan bulat big-endian
tanpa tanda tangan 64-bit. Skema HMAC ini mengikuti draf untuk AES-CBC-HMAC dari Mcgrew.
AEAD deterministik
Tink menerapkan RFC 5297 untuk AES-SIV, dengan menempatkan vektor inisialisasi sintetis (SIV) di awal ciphertext. Primitif dapat menambahkan awalan output Tink 5 byte.
Meskipun RFC 5297 mendukung daftar data terkait, Tink hanya mendukung satu data terkait, yang sesuai dengan daftar dengan satu elemen di RFC 5297. Data kosong terkait adalah daftar dengan satu elemen kosong, bukan daftar kosong.
Streaming AEAD
Lihat AES-CTR HMAC dan AES-GCM-HKDF.
Enkripsi alamat pengiriman
Enkripsi amplop mengenkripsi data dengan kunci enkripsi data DEK
menggunakan
primitif AEAD Tink. Enkripsi berfungsi sebagai berikut:
DEK
baru akan dibuat menggunakan template kunci (atau parameter kunci) tertentu.DEK
diserialisasi ke dalam string byte. Serialisasi memformat serialisasi buffering protokol dari proto jenis kunci. Misalnya, ini adalah pesan buffering protokolAesGcmKey
serial yang ditentukan dalam aes_gcm.proto untuk DEK jenis kunci AES GCM. Lihat serialisasi buffering protokol untuk cara melakukan serialisasi buffer protokol.DEK
yang diserialisasi dienkripsi oleh penyedia eksternal (misalnya, GCP), ke dalamencrypted DEK
.DEK
digunakan untuk mengenkripsi teks biasa dengan data terkait ke dalamciphertext
. Jadi,ciphertext
memiliki format yang sama persis dengan primitif AEAD yang sesuai denganDEK
.
Format output enkripsi amplop adalah sebagai berikut:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length
adalah 4 byte, yang menyimpan panjang encrypted DEK
sebagai integer big-endian 32-bit.
MAC
Tink mengikuti RFC yang sesuai. Primitif dapat menambahkan awalan output Tink 5 byte ke tag.
Set PRF
Tink mengikuti RFC yang sesuai. Perhatikan bahwa untuk PRF Set, jenis kunci berbeda dengan jenis kunci MAC pada algoritma yang sama karena tidak menyertakan panjang output. Kunci PRF Set tidak pernah menambahkan awalan output Tink. Hal ini untuk memastikan bahwa {i>output-<i}nya adalah PRF.
Enkripsi hybrid
Format kabel umum untuk enkripsi hybrid Tink adalah sebagai berikut:
prefix || encapsulated_key || encrypted_data
prefix
kosong atau awalan output Tink 5 byte. Setiap jenis kunci berisi
informasi tentang jumlah byte yang akan diurai, dan cara mengurai byte tersebut dari
encapsulated_key
.
HPKE (Enkripsi Kunci Publik Hybrid)
Tink mengikuti standar HPKE yang didefinisikan dalam RFC 9180. Ciphersuite HPKE mencakup tiga primitif berikut.
- Mekanisme enkapsulasi kunci (KEM)
- Fungsi turunan kunci (KDF)
- Enkripsi yang diautentikasi dengan data terkait (AEAD)
Standar HPKE tidak menentukan format kabel umum dalam RFC 9180, Bagian
10. Implementasi HPKE Tink menggunakan nilai
encapsulated_key
dan encrypted_data
berikut.
encapsulated_key
- Kunci publik yang diserialisasi pengirim
- Ditetapkan sebagai
enc
di RFC 9180, Bagian 4.1 - Format yang ditentukan berdasarkan HPKE KEM spesifik yang digunakan
encrypted_data
- Teks tersandi dan tag (yaitu,
ciphertext || tag
tanpa IV) - Ditetapkan sebagai
ct
di RFC 9180, Bagian 4 - Format yang ditentukan oleh HPKE AEAD tertentu yang digunakan
- Teks tersandi dan tag (yaitu,
X25519 KEM berbasis Diffie-Hellman
Untuk DHKEM X25519, nilai enc
adalah kunci publik Diffie-Hellman 32 byte milik pengirim.
ECIES-AEAD-HKDF
Untuk implementasi ECIES-AEAD-HKDF Tink, encapsulated_key
adalah output
dari Key Enkapsulation Mechanism (KEM) dan encrypted_data
adalah output
dari Data Enkapsulation Mechanism (DEM).
KEM
Bergantung pada jenis kunci, Tink menggunakan titik kurva eliptis yang dikompresi dan tidak dikompresi, sesuai dengan standar encoding RFC 8422/ANSI.X9-62.2005
. Untuk
titik yang tidak dikompresi, byte 0x04
diikuti oleh koordinat x
dan y
sebagai bilangan bulat ukuran tetap. Untuk koordinat terkompresi, byte 0x02
atau 0x03
dan koordinat x
sebagai bilangan bulat ukuran tetap digunakan. Untuk X25519
,
definisi RFC 7748 digunakan (koordinat x
sebagai bilangan bulat ukuran tetap).
DEM
Untuk encrypted_data
, Tink menggunakan format yang sama dengan AEAD. Termasuk di antaranya
menentukan IV.
Turunan kunci
Pertama, koordinat x x_ss
dari titik bersama dihitung. Kunci untuk
AEAD kemudian ditetapkan ke:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
dengan encapsulated_key
adalah output KEM penuh sebagai byte.
Tanda tangan digital
Tink mengikuti RFC yang sesuai. Primitif dapat menambahkan awalan output Tink 5 byte ke tag yang dihasilkan.
ECDSA
Bergantung pada kolom EcdsaSignatureEncoding dalam kunci, format tanda tangan ECDSA adalah IEEE P1363
atau ASN.1 DER
.
Format tanda tangan IEEE P1363
adalah r || s
, dengan r
dan s
dengan padding nol dan memiliki ukuran yang sama dalam byte dengan urutan kurva. Misalnya, untuk kurva NIST P-256
, r
dan s
diberi padding nol hingga 32 byte.
Tanda tangan DER dienkode menggunakan ASN.1
:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
Secara khusus, encoding tersebut adalah:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink mengikuti praktik terbaik untuk verifikasi tanda tangan, dengan hanya menerima tanda tangan ECDSA yang dienkode DER (tanda tangan berenkode BER alternatif tidak valid).
Hal ini membantu mencegah serangan pemograman tanda tangan, yang sering memengaruhi sistem mata uang kripto.