Bu sayfada, Tink'in anahtarlar ve temel çıkış için tel biçimi açıklanmaktadır. Bu doküman, Tink'e ek diller eklemek isteyen kriptograflar ve kablo uyumlu bir mod isteyen diğer üst düzey kripto kitaplıklarının bakımını yapanlar için hazırlanmıştır. Genel kitlelere yönelik değildir.
Anahtar kümesi serileştirme
Tink, anahtar kümelerini serileştirmek için Google protobuf kullanır.
- İkili olarak serileştirilmiş anahtar grubu, tink.proto içinde tanımlanan serileştirilmiş bir Keyset proto'dur. Bir anahtarın KeyData değer özelliği, ilgili anahtar türünün serileştirilmiş bir proto'sudur.
- JSON olarak serileştirilmiş anahtar grubu, JSON biçiminde serileştirilmiş bir anahtar grubu proto'sudur. KeyData değerinin hâlâ ikili olarak serileştirilmiş bir proto olduğunu unutmayın.
- Şifrelenmiş anahtar kümesi, tink.proto içinde tanımlanan, serileştirilmiş bir EncryptedKeyset proto'dur. Şifrelenmiş bir ikili serileştirilmiş anahtar kümesi ve isteğe bağlı olarak şifrelenmemiş bazı KeysetInfo meta verileri içerir.
Tink Çıkış Öneki
Çoğu Tink temel öğesi, aşağıdakilerden oluşan 5 baytlık bir çıkış önekini destekler:
- 1 baytlık sürüm:
0x01 - 4 baytlık anahtar ipucu: Bu, kullanılan anahtarın anahtar kimliğidir.
Bazı eski anahtarlar da sürüm baytını 0x00 destekleyebilir.
Bu önekin kimliğinin doğrulanmadığını ve güvenlik amacıyla kullanılamayacağını unutmayın. Tink, şifre çözme veya doğrulama sürecini hızlandırmak için bunu ipucu olarak kullanır.
AEAD
Genel olarak Tink, AEAD şifreli metinlerini şu şekilde biçimlendirir:
prefix || IV || ciphertext || tag
İlgili RFC'de aksi belirtilmediği sürece. prefix boş veya 5 baytlık bir Tink çıkış önekidir.
AES-CTR-HMAC
AES-CTR-HMAC için Tink, MAC'yi ilişkili verilerle (AD) aşağıdaki şekilde hesaplar:
AD || IV || ciphertext || bitlen(AD)
Burada bitlen(AD), AD'nin 64 bitlik büyük endian işaretsiz tam sayı olarak gösterilen bit cinsinden uzunluğudur. Bu HMAC şeması, Mcgrew'in AES-CBC-HMAC taslağını temel alır.
Deterministik AEAD
Tink, AES-SIV için RFC 5297'yi uygular ve sentetik başlatma vektörünü (SIV) şifrelenmiş metnin başına yerleştirir. İlkel, 5 baytlık bir Tink çıkış ön eki ekleyebilir.
RFC 5297, ilişkili verilerin listesini desteklerken Tink yalnızca tam olarak bir ilişkili veriyi destekler. Bu veri, RFC 5297'deki tek öğeli bir listeye karşılık gelir. Boş ilişkili veriler, boş bir liste değil, boş bir öğe içeren bir listedir.
Akış AEAD
AES-CTR HMAC ve AES-GCM-HKDF sayfalarına bakın.
Zarf şifrelemesi
Zarf şifreleme, Tink'in AEAD temel öğelerini kullanarak verileri veri şifreleme anahtarıyla DEK şifreler. Şifreleme şu şekilde çalışır:
- Belirli bir anahtar şablonu (veya anahtar parametreleri) kullanılarak yeni bir
DEKoluşturulur. DEK, bayt dizesine dönüştürülür. Anahtar türü proto'nun protokol arabelleği serileştirmesi için kullanılan serileştirme biçimi. Örneğin, bu, AES GCM anahtar türünün DEK'si için aes_gcm.proto içinde tanımlanan serileştirilmiş birAesGcmKeyprotokol arabelleği mesajıdır. Protokol arabelleğinin nasıl serileştirileceği hakkında bilgi için Protokol arabelleği serileştirme başlıklı makaleyi inceleyin.- Serileştirilmiş
DEK, harici bir sağlayıcı (ör. GCP) tarafındanencrypted DEKolarak şifrelenir. DEK, düz metni ilişkili verilerle birlikteciphertextolarak şifrelemek için kullanılır. Bu nedenle,ciphertext,DEKile ilişkili AEAD temel öğesiyle aynı biçime sahiptir.
Zarf şifrelemenin çıkış biçimi aşağıdaki gibidir:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length, encrypted DEK uzunluğunu 32 bitlik büyük endian tamsayı olarak depolayan 4 bayttır.
MAC
Tink, ilgili RFC'leri takip eder. Temel öğeler, etikete 5 baytlık bir Tink çıkışı öneki ekleyebilir.
PRF kümesi
Tink, ilgili RFC'leri takip eder. PRF için anahtar türünün, aynı algoritmanın MAC anahtar türünden farklı olduğunu ve çıkış uzunluğunu içermediğini unutmayın. PRF Set anahtarları hiçbir zaman Tink çıkışı ön eki eklemez. Bu, çıktının aslında bir PRF olmasını sağlar.
Karma şifreleme
Tink hibrit şifrelemesi için genel kablo biçimi şöyledir:
prefix || encapsulated_key || encrypted_data
prefix boş veya 5 baytlık bir Tink çıkış önekidir. Her anahtar türü, encapsulated_key baytlarının nasıl ayrıştırılacağı ve bu baytların nasıl ayrıştırılacağıyla ilgili bilgileri içerir.
HPKE (Hibrit Ortak Anahtar Şifreleme)
Tink, RFC 9180'de tanımlanan HPKE standardını izler. Bir HPKE şifreleme paketi aşağıdaki üç temel öğeyi içerir.
- Anahtar kapsülleme mekanizması (KEM)
- Anahtar türetme işlevi (KDF)
- İlişkili verilerle kimliği doğrulanmış şifreleme (AEAD)
HPKE standardı, RFC 9180, Bölüm 10'da genel bir kablo biçimi tanımlamaz. Tink'in HPKE uygulaması aşağıdaki encapsulated_key ve encrypted_data değerlerini kullanır.
encapsulated_key- Gönderenin seri hale getirilmiş ortak anahtarı
- RFC 9180, Bölüm 4.1'de
encolarak tanımlanır. - Kullanılan HPKE KEM'e göre belirlenen biçim
encrypted_data- Şifrelenmiş metin ve etiket (ör.
ciphertext || tag(IV olmadan) - RFC 9180, Bölüm 4'te
ctolarak tanımlanır. - Kullanılan HPKE AEAD'ye göre belirlenen biçim
- Şifrelenmiş metin ve etiket (ör.
X25519 Diffie-Hellman tabanlı KEM
X25519 DHKEM'ler için enc değeri, gönderenin 32 baytlık Diffie-Hellman genel anahtarıdır.
ECIES-AEAD-HKDF
Tink'in ECIES-AEAD-HKDF uygulamasında encapsulated_key, Anahtar Kapsülleme Mekanizması'nın (KEM) çıkışı, encrypted_data ise Veri Kapsülleme Mekanizması'nın (DEM) çıkışıdır.
KEM
Anahtar türüne bağlı olarak Tink, RFC 8422/ANSI.X9-62.2005 kodlama standartlarını izleyerek sıkıştırılmış ve sıkıştırılmamış eliptik eğri noktaları kullanır. Sıkıştırılmamış noktalar için bayt 0x04, x ve y koordinatıyla sabit boyutlu tamsayılar olarak takip edilir. Sıkıştırılmış koordinatlar için 0x02
veya 0x03 baytı ve x koordinatı sabit boyutlu bir tam sayı olarak kullanılır. X25519 için RFC 7748 tanımı kullanılır (x koordinatı sabit boyutlu tam sayı olarak).
DEM
encrypted_data için Tink, AEAD ile aynı biçimi kullanır. Buna bir IV belirtmek dahildir.
Anahtar türetme
Önce paylaşılan noktanın x koordinatı x_ss hesaplanır. AEAD için anahtar şu şekilde ayarlanır:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
Burada encapsulated_key, bayt olarak tam KEM çıkışıdır.
Dijital imzalar
Tink, ilgili RFC'leri takip eder. Temel öğeler, oluşturulan etikete 5 baytlık bir Tink çıkışı öneki ekleyebilir.
ECDSA
Anahtardaki EcdsaSignatureEncoding alanına bağlı olarak ECDSA imzasının biçimi IEEE P1363 veya ASN.1 DER olur.
IEEE P1363 imzasının biçimi r || s şeklindedir. Burada r ve s, sıfırlarla doldurulmuş ve eğrinin sırası ile aynı boyuttadır (bayt cinsinden). Örneğin, NIST P-256 eğrisi için r ve s değerleri 32 bayt olacak şekilde sıfırlarla doldurulur.
DER imzası ASN.1 kullanılarak kodlanmıştır:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
Özellikle kodlama:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink, yalnızca DER kodlamalı ECDSA imzalarını kabul ederek imza doğrulamayla ilgili en iyi uygulamaları takip eder (alternatif BER kodlamalı imzalar geçersizdir).
Bu sayede, genellikle kripto para sistemlerini etkileyen imza değiştirme saldırıları önlenir.
Harici Mu ML-DSA ön karma değerleri
Prehash temel işlevi, bir iletiyi prehash değerine dönüştürür. Bu değer, SignPrehash temel işlevi tarafından imzalanır. External Mu modundaki ML-DSA için RFC 9881'de açıklandığı gibi, ön karma değeri aşağıdaki düzene sahip 69 bayttır:
0xff || key_id (4 bytes, big-endian) || mu (64 bytes)
mu,SHAKE256(tr || 0x00 || 0x00 || message, 64)olarak hesaplanan ML-DSA mesajı temsilcisidir. Buradatr, ortak anahtarın 64 baytlık karma değeridir, ilk0x00, saf ML-DSA için FIPS 204 alan ayırıcıdır ve ikinci0x00, bağlam dizesinin (boş) uzunluğudur.tr, ortak anahtardan türetildiği içinmu, bu anahtara kriptografik olarak bağlıdır. Ancak bağlamanın kontrol edilmesi için orijinal ileti gerekir.- 5 baytlık önek, Tink çerçevelemesidir ve
muparametresinin bir parçası değildir. Bu yöntem, karma öncesi değeri belirli bir anahtarla ilişkilendirir. Böylece SignPrehash, hangi anahtarla imza oluşturacağını bilir ve anahtarı olmayan bir karma öncesi değeri reddedebilir. Önek, düz meta veridir ve hiçbir şeyi kriptografik olarak bağlamaz. Herkes bunu yeniden yazabilir.
İmzalama, tam olarak 69 bayt olmayan, 0xff ile başlamayan veya anahtar kimliği, anahtar kümesindeki etkin bir anahtarla eşleşmeyen girişleri reddeder.