Asymmetric Kriptografi: RSA-OAEP, Elliptic Curve, ECDH Key Agreement ve Hybrid Encryption

Sürüm notu: Bu yazıdaki kodlar .NET 10 ve xUnit v3 4.0 ile derlenip denenmiştir; çıktılar Ubuntu 24.04 (OpenSSL 3.0) üzerinde alınmıştır.

Önce Tahmin Et

Bookstore her hafta tedarikçilerine satın alma siparişi dosyası gönderiyor: hangi ISBN'den (kitabın uluslararası numarası) kaç adet, hangi birim fiyatla. Dosya bir SFTP (SSH üzerinden dosya aktarım protokolü) klasörüne bırakılıyor ve tedarikçi oradan alıyor. Yeni bir tedarikçi sözleşmesine "dosyalar uçtan uca şifreli olmalı" maddesi eklendi: aradaki sunucu, yedekleme sistemi ya da klasöre erişimi olan herhangi biri dosyayı okuyamamalı.

Bir önceki yazıdan elimizde AES (Advanced Encryption Standard; standart blok şifre) tabanlı AES-GCM var. Sorun şu: tedarikçi dosyayı açmak için aynı anahtara sahip olmalı. Anahtarı ona nasıl ulaştıracaksın? E-postayla mı, telefonla mı, dosyanın yanına başka bir dosya olarak mı? Hangi kanalı seçersen seç, o kanal korumaya çalıştığın dosyadan daha güvenli olmak zorunda. Bu yazıda bu sorunu, yani anahtar dağıtımını çözüyoruz: public key kriptografisi, RSA (adını mucitleri Rivest, Shamir ve Adleman'dan alan public key algoritması) ve elliptic curve'ler, ECDH (Elliptic Curve Diffie-Hellman; iki tarafın ortak bir sır hesapladığı key agreement) ve hepsini birleştiren hybrid encryption.

Public Key Neyi Çözüyor

Asymmetric kriptografide her taraf bir anahtar çiftine sahip. Private key yalnız sahibinde duruyor; public key ise herkese verilebiliyor. Bir mesajı public key ile şifrelersen yalnız private key sahibi açabiliyor. Tedarikçi bize public key'ini bir kez gönderiyor; biz her dosyayı onunla şifreliyoruz. Gizli bir şey hiçbir kanaldan geçmiyor.

Ama iki kısıt var. Birincisi, asymmetric işlemler simetrik işlemlere göre çok yavaş ve doğrudan şifreleyebildikleri veri miktarı anahtar boyutuyla sınırlı. İkincisi, public key'in gerçekten tedarikçiye ait olduğundan emin olmak gerekiyor; bize gelen anahtar yolda değiştirildiyse dosyayı saldırgan için şifreleriz. İlk kısıtı bu yazıda hybrid encryption ile çözüyoruz. İkincisi, yani bir public key'i sahibine bağlamak, X.509 sertifikalarının işi ve serinin altıncı yazısının konusu. Burada tedarikçinin public key'ini güvenilir bir kanaldan, örneğin sözleşme sürecinde aldığımızı varsayıyoruz.

RSA: OAEP, PKCS#1 v1.5 ve Anahtar Boyutu

RSA, şifrelemede bir padding şeması ile kullanılıyor ve seçim önemli. RSA'nın standart dizisi PKCS'in (Public-Key Cryptography Standards; RSA şifrelemesinin kurallarını yazan belge dizisi) ilk belgesindeki eski v1.5 padding'i, kısaca PKCS#1 v1.5, padding oracle saldırılarına açık: sunucu, çözdüğü metnin padding'inin geçerli olup olmadığını hata mesajıyla, bağlantıyı kapatma biçimiyle ya da yanıt süresiyle belli ediyorsa, saldırgan bu sinyali kullanarak şifreli metni adım adım çözebiliyor. Daniel Bleichenbacher bu saldırıyı 1998'de yayımladı; 2017'deki ROBOT (Return Of Bleichenbacher's Oracle Threat; Bleichenbacher saldırısının hâlâ yaşadığını gösteren çalışma) aynı açığın, Alexa listesindeki ilk 100 domain'in 27'sinde hâlâ bulunduğunu gösterdi. Yeni kodda tek doğru seçim OAEP (Optimal Asymmetric Encryption Padding; rastgelelik ekleyen, güvenliği kanıtlanmış RSA padding'i), hash olarak da SHA (Secure Hash Algorithm; standart hash ailesi için kullanılan ad) ailesinden SHA-256: RSAEncryptionPadding.OaepSHA256.

RSA ile ne kadar veri şifreleyebileceğimizi görelim:

using RSA rsa = RSA.Create(2048);
foreach (int size in new[] { 190, 191 })
{
    try
    {
        byte[] ciphertext = rsa.Encrypt(new byte[size], RSAEncryptionPadding.OaepSHA256);
        Console.WriteLine($"{size} bytes -> {ciphertext.Length} bytes ciphertext");
    }
    catch (CryptographicException ex)
    {
        Console.WriteLine($"{size} bytes -> {ex.GetType().Name}: {ex.Message}");
    }
}

// Aynı girdi, iki şifreleme: OAEP rastgelelik içerir
byte[] a = rsa.Encrypt("Dune"u8, RSAEncryptionPadding.OaepSHA256);
byte[] b = rsa.Encrypt("Dune"u8, RSAEncryptionPadding.OaepSHA256);
Console.WriteLine($"same plaintext, same ciphertext: {a.AsSpan().SequenceEqual(b)}");

$ dotnet run --project src/Bookstore.CryptoLab -- rsa-limit
190 bytes -> 256 bytes ciphertext
191 bytes -> OpenSslCryptographicException: error:0200006E:rsa routines::data too large for key size
same plaintext, same ciphertext: False

2048 bit'lik bir anahtarla OAEP-SHA256, en fazla 190 byte şifreliyor: 256 byte'lık modülden iki hash uzunluğu ve iki byte padding'e gidiyor. Hata mesajı OpenSSL'den geliyor; Windows'ta aynı durumda CNG'nin (Windows'un kripto kütüphanesi) kendi mesajını görürsün, ama tip yine bir CryptographicException. Bizim sipariş dosyamız 229 byte; şimdiden sığmıyor. RSA ile veriyi parçalara bölüp şifrelemek de bir çözüm değil: yavaş, büyük ve parçaların sırası ya da bütünlüğü korunmuyor.

Anahtar boyutu için NIST'in (ABD Ulusal Standartlar ve Teknoloji Enstitüsü) anahtar yönetimi rehberi SP (Special Publication; NIST'in özel yayın dizisi) 800-57, RSA-2048'i 112 bit, RSA-3072'yi 128 bit güvenlik düzeyinde sayıyor; 112 bitlik anahtarla yeni veri korumayı 2030 sonuna kadar kabul ediyor, 2031'den itibaren en az 128 bit istiyor. Ekim 2026'da yayımlanan NIST IR (Interagency Report; NIST'in kurumlar arası raporu) 8547 ise bu takvimi kuantum geçişine bağladı: boyutu ne olursa olsun RSA, 2030'dan sonra deprecated, 2035'ten sonra yasak sayılacak. Yeni bir anahtar üretiyorsan 3072 bit'ten başla; kuantum bilgisayarların RSA'yı nasıl etkilediği ve yerine ne geldiği serinin post-quantum yazısının konusu.

Elliptic Curve: Neden Daha Küçük Anahtar

Elliptic curve kriptografisi aynı güvenlik düzeyini çok daha küçük anahtarlarla sağlıyor. Fark, anahtarları dışa aktardığımızda net görünüyor:

foreach (int bits in new[] { 2048, 3072 })
{
    using RSA rsa = RSA.Create(bits);
    Console.WriteLine($"RSA-{bits,-5} public key {rsa.ExportSubjectPublicKeyInfo().Length,3} bytes, private key {rsa.ExportPkcs8PrivateKey().Length,4} bytes");
}

foreach (ECCurve curve in new[] { ECCurve.NamedCurves.nistP256, ECCurve.NamedCurves.nistP384 })
{
    using ECDiffieHellman ecdh = ECDiffieHellman.Create(curve);
    Console.WriteLine($"{curve.Oid.FriendlyName,-9} public key {ecdh.ExportSubjectPublicKeyInfo().Length,3} bytes, private key {ecdh.ExportPkcs8PrivateKey().Length,4} bytes");
}

$ dotnet run --project src/Bookstore.CryptoLab -- key-sizes
RSA-2048  public key 294 bytes, private key 1216 bytes
RSA-3072  public key 422 bytes, private key 1793 bytes
nistP256  public key  91 bytes, private key  138 bytes
nistP384  public key 120 bytes, private key  185 bytes

P-256, RSA-3072 ile aynı 128 bit güvenlik düzeyinde ama public key'i beşte biri kadar. Anahtar üretimi de çok daha hızlı: RSA anahtarı üretmek büyük asal sayılar aramayı gerektiriyor, EC (elliptic curve; eliptik eğri) anahtarı ise rastgele bir sayıdan ibaret. P-256 ve P-384, NIST'in tanımladığı ve .NET'in her platformda desteklediği eğriler; serinin ilk yazısındaki platform tablosuna göre Brainpool gibi diğer eğrilerin desteği platforma göre değişiyor. Modern protokollerde sık gördüğün X25519 (Curve25519 eğrisi üzerinde tanımlı key agreement) için .NET 10'da bir class yok; .NET'teki durumu serinin son yazısında ele alacağız. Bookstore'da P-256 kullanıyoruz.

ECDH ile Ortak Sır ve Neden HKDF'ten Geçirilmeli

Elliptic curve ile doğrudan "şifreleme" yapmıyoruz; ECDH kullanıyoruz: iki taraf, kendi private key'i ve karşı tarafın public key'iyle aynı ortak sırrı hesaplıyor. Bookstore her mesaj için yeni, geçici bir anahtar çifti (ephemeral key) üretiyor; kendi ephemeral private key'i ile tedarikçinin public key'inden bir ortak sır hesaplıyor. Tedarikçi aynı sırrı kendi private key'i ile Bookstore'un ephemeral public key'inden hesaplıyor. Ephemeral public key dosyayla birlikte gidiyor; private key ise mesaj şifrelendikten sonra yok ediliyor.

Ortak sırrı doğrudan AES anahtarı olarak kullanmak yanlış. ECDH'nin ham çıktısı bir eğri noktasının koordinatı; tekdüze rastgele bir değer değil. Bir önceki yazıda HKDF (HMAC tabanlı anahtar türetme fonksiyonu) anlatırken söylediğimiz durum bu: girdi güçlü ve tekdüze bir anahtar değilse extract adımı ve salt şart. .NET 8 ile gelen DeriveRawSecretAgreement ham sırrı veriyor, biz de onu HKDF'ten geçiriyoruz:

// Ham ECDH çıktısı tekdüze rastgele değil: her zaman bir KDF'ten, salt ile geçir
private static byte[] DeriveKey(byte[] shared, byte[] ephemeralPublic, string keyId) =>
    HKDF.DeriveKey(HashAlgorithmName.SHA256, shared, 32, salt: ephemeralPublic,
        info: Encoding.UTF8.GetBytes($"bookstore/purchase-order/v1|{keyId}"));

Salt olarak ephemeral public key'i veriyoruz: gizli değil, her mesajda farklı ve iki tarafın da elinde. info ise anahtarı amaca ve alıcının anahtar kimliğine bağlıyor; aynı ortak sır başka bir protokolde başka bir anahtar üretir. KDF (Key Derivation Function; anahtar türetme fonksiyonu) adımını atlayan "ham ECDH çıktısının SHA-256'sı" gibi kestirmeler hem standart dışı hem de bağlam bilgisini kaybediyor.

Hybrid Encryption: Satın Alma Siparişi Dosyası

Hybrid encryption iki dünyayı birleştiriyor: asymmetric kriptografi yalnız 32 byte'lık bir simetrik anahtarı taşıyor, verinin kendisini bir önceki yazının AEAD'i (şifrelemeyle birlikte bütünlüğü de doğrulayan encryption), yani AES-GCM şifreliyor. Sitedeki serilerin ortak örnek uygulaması Bookstore (bir online kitapçı); kod Bookstore.Crypto library'sinin Hybrid klasöründe:

// Alıcıya giden kayıt. Binary alanlar Base64Url; kaydın tamamı JSON olarak serialize edilir.
public sealed record HybridEnvelope(int Version, string Algorithm, string KeyId, string EncapsulatedKey, string Nonce, string Ciphertext, string Tag);

public static HybridEnvelope Encrypt(ECDiffieHellman recipientPublicKey, string keyId, ReadOnlySpan<byte> plaintext)
{
    // Her mesaj için yeni bir anahtar çifti: gönderen hiçbir private key saklamıyor
    using ECDiffieHellman ephemeral = ECDiffieHellman.Create(ECCurve.NamedCurves.nistP256);
    byte[] ephemeralPublic = ephemeral.ExportSubjectPublicKeyInfo();
    byte[] shared = ephemeral.DeriveRawSecretAgreement(recipientPublicKey.PublicKey);
    byte[] key = DeriveKey(shared, ephemeralPublic, keyId);
    try
    {
        return Aead.Seal(Version, Algorithm, keyId, ephemeralPublic, key, plaintext);
    }
    finally
    {
        CryptographicOperations.ZeroMemory(shared);
        CryptographicOperations.ZeroMemory(key);
    }
}

Aead.Seal bir önceki yazıdaki fikri tekrar kullanıyor: sürüm, algoritma adı, keyId ve ephemeral public key şifrelenmiyor ama associated data olarak tag'e dahil ediliyor. Böylece biri dosyadaki algoritma adını ya da keyId'yi değiştirirse açma işlemi başarısız oluyor. Çözme tarafında ephemeral public key'in gerçekten P-256 üzerinde olduğunu da kontrol ediyoruz; dışarıdan gelen bir anahtarı beklediğin eğriye göre doğrulamadan kullanma.

Lab komutu iki tarafı da oynuyor: tedarikçi anahtar çiftini üretip public key'ini PEM (Base64 içeriği BEGIN/END satırları arasına koyan metin biçimi) olarak veriyor, Bookstore siparişi şifreliyor, tedarikçi şifreli private key'ini passphrase ile açıp siparişi okuyor:

$ dotnet run --project src/Bookstore.CryptoLab -- purchase-order
supplier-0042.key.pem: -----BEGIN ENCRYPTED PRIVATE KEY----- (8 lines)
supplier-0042.pub.pem: -----BEGIN PUBLIC KEY----- (4 lines)
PO-2026-11-0042.json.enc: 638 bytes for a 229-byte order
{
  "version": 1,
  "algorithm": "ECDH-P256.HKDF-SHA256.A256GCM",
  "keyId": "supplier-0042/2026",
  "encapsulatedKey": "MFkwEwYHKoZIzj0CAQYI...",
  "nonce": "A1HQBsW6CVgK9lJf",
  "ciphertext": "ASfmhuFdpGIn2Cjxepdb...",
  "tag": "9rbS3dE2Wcyv4o_Tu0kE4g"
}
supplier reads: {"purchaseOrderId":"PO-2026-11-0042","supplierId":"sup...
other supplier's key: AuthenticationTagMismatchException
keyId changed in transit: AuthenticationTagMismatchException
wrong passphrase: CryptographicException

229 byte'lık sipariş 638 byte'lık bir dosyaya dönüştü; farkın çoğu 91 byte'lık ephemeral public key, Base64Url ve JSON. Başka bir tedarikçinin anahtarı farklı bir ortak sır, dolayısıyla farklı bir AES anahtarı üretiyor ve tag tutmuyor. Binary alanlar için Base64Url seçtik: standart Base64'teki + ve / karakterleri JSON'da kaçış dizisine dönüşebiliyor ve URL'lerde sorun çıkarıyor.

Bu yapı yeni bir icat değil. Authentication ve Authorization serisinin JWT (JSON Web Token; imzalı ya da şifreli token biçimi) yazısında gördüğümüz JWE'nin (JSON Web Encryption; JWT'nin şifreli biçimi) ECDH-ES modu aynı fikri JSON formatında uyguluyor; RFC (Request for Comments; internet standartlarının yayımlandığı belge serisi) 9180 ile standartlaşan HPKE (Hybrid Public Key Encryption; anahtar kapsülleme, anahtar türetme ve AEAD'i tek bir standartta birleştiren yapı) ise aynı yaklaşımı protokol seviyesinde tanımlıyor. Karşı taraf bu standartlardan birini konuşuyorsa kendi formatını icat etme, onu kullan. Bizim formatımız tedarikçiyle ikili bir anlaşma; sürüm ve algoritma alanı da ileride HPKE'ye geçişi kolaylaştırmak için var.

Tedarikçinin RSA anahtarı varsa yapı aynı, yalnız anahtar taşıma kısmı değişiyor: rastgele bir DEK (Data Encryption Key; veriyi şifreleyen anahtar) üretilip OAEP ile şifreleniyor:

public static HybridEnvelope Encrypt(RSA recipientPublicKey, string keyId, ReadOnlySpan<byte> plaintext)
{
    byte[] dek = RandomNumberGenerator.GetBytes(32);
    try
    {
        byte[] wrapped = recipientPublicKey.Encrypt(dek, RSAEncryptionPadding.OaepSHA256);
        return Aead.Seal(Version, Algorithm, keyId, wrapped, dek, plaintext);
    }
    finally
    {
        CryptographicOperations.ZeroMemory(dek);
    }
}

Anahtarı Saklamak ve Taşımak: PEM, PKCS#8 ve Sertifika

Anahtarlar dosyaya ya da configuration'a genellikle PEM olarak yazılıyor; adı eskiden e-posta güvenliği için tasarlanmış Privacy-Enhanced Mail'den geliyor. İçerik ise standart yapılar: public key için SubjectPublicKeyInfo (-----BEGIN PUBLIC KEY-----), private key için PKCS#8 (private key'leri algoritmadan bağımsız saklayan standart yapı, -----BEGIN PRIVATE KEY-----). .NET'te ikisinin de import ve export method'ları var ve algoritmayı PEM etiketinden anlıyor:

// Tedarikçi tarafı: anahtar çiftini bir kez üret, Bookstore'a yalnız public key'i gönder
using (ECDiffieHellman supplierKey = ECDiffieHellman.Create(ECCurve.NamedCurves.nistP256))
{
    File.WriteAllText(Path.Combine(folder, "supplier-0042.pub.pem"), supplierKey.ExportSubjectPublicKeyInfoPem());
    PbeParameters pbe = new(PbeEncryptionAlgorithm.Aes256Cbc, HashAlgorithmName.SHA256, iterationCount: 600_000);
    File.WriteAllText(Path.Combine(folder, "supplier-0042.key.pem"), supplierKey.ExportEncryptedPkcs8PrivateKeyPem(passphrase, pbe));
}

// Tedarikçi tarafı: private key'i passphrase ile aç ve çöz
using ECDiffieHellman supplierPrivate = ECDiffieHellman.Create();
supplierPrivate.ImportFromEncryptedPem(File.ReadAllText(Path.Combine(folder, "supplier-0042.key.pem")), passphrase);

Private key'i diske yazman gerekiyorsa şifreli PKCS#8 kullan (-----BEGIN ENCRYPTED PRIVATE KEY-----). Anahtar, passphrase'ten PBKDF2 (parolayı binlerce kez HMAC'ten geçirerek anahtar türeten fonksiyon) ile türetilen bir AES anahtarıyla şifreleniyor; 600.000 iterasyon, Web Güvenliği (OWASP Top 10) serisinin parola saklama yazısındaki PBKDF2-HMAC-SHA256 önerisiyle aynı. Lab'daki passphrase dev-only-supplier-key-passphrase; gerçekte bu değer bir secret store'dan ya da bir insanın belleğinden gelir, kodda durmaz.

Tedarikçi çıplak bir public key yerine bir X.509 sertifikası da gönderebilir. Sertifika public key'i, sahibinin adı ve bir imza ile birlikte taşıyor; anahtarı ondan almak tek satır:

using X509Certificate2 received = X509Certificate2.CreateFromPem(pem);
using RSA publicKey = received.GetRSAPublicKey()!;
Console.WriteLine($"{received.Subject}, has private key: {received.HasPrivateKey}, RSA-{publicKey.KeySize}");

HybridEnvelope envelope = RsaHybrid.Encrypt(publicKey, "supplier-0042/2026-rsa", PurchaseOrder);
Console.WriteLine($"{envelope.Algorithm}: encapsulated key {Base64Url.DecodeFromChars(envelope.EncapsulatedKey).Length} bytes");

$ dotnet run --project src/Bookstore.CryptoLab -- rsa-certificate
CN=supplier-0042.example.com, has private key: False, RSA-3072
RSA-OAEP-SHA256.A256GCM: encapsulated key 384 bytes
round trip: True

Lab'daki sertifika kendinden imzalı ve bellekte üretiliyor; gerçek hayatta sertifikanın zincirini, geçerlilik tarihini ve kullanım amacını doğrulamadan içindeki anahtara güvenmemelisin. Bunun nasıl yapıldığı altıncı yazının konusu. RSA-3072 ile taşınan anahtar 384 byte; ECDH'deki 91 byte'lık ephemeral public key ile karşılaştır.

Üretimde Dikkat

Alıcının anahtarını keyId ile yönet. Tedarikçi anahtarını yenilediğinde yeni dosyalar yeni anahtarla şifrelenir; eski dosyalar eski keyId ile işaretli olduğu için tedarikçi hangi private key'i kullanacağını bilir. Anahtar değişimini sözleşme ekine ve takvime bağla: yeni public key'i aldığın tarihi, eskisini kullanmayı bıraktığın tarihi kaydet.

Bu yapıda forward secrecy yok: gönderen her mesajda yeni bir ephemeral key kullansa da, alıcının uzun ömürlü private key'i sızarsa o anahtarla şifrelenmiş bütün geçmiş dosyalar açılabilir. Dosya aktarımı gibi asenkron senaryolarda bu kaçınılmaz; korunmanın yolu alıcı anahtarını düzenli döndürmek ve eski private key'leri gerektiğinden uzun saklamamak. Canlı bağlantılarda forward secrecy'nin nasıl sağlandığını TLS (HTTPS'in altındaki şifreli bağlantı protokolü) yazısında göreceğiz.

Performans tarafında RSA private key işlemleri (çözme ve imzalama) public key işlemlerinden çok daha yavaş, EC işlemleri ise genelde ikisinin arasında. Saniyede binlerce dosya şifrelemiyorsan bu fark önemli değil; ama RSA anahtar üretimini bir istek yolunda yapma.

Private key'in yaşadığı yer, kodun kendisinden daha önemli. Production'da private key ya bir HSM (Hardware Security Module; anahtarı dışarı vermeden işlem yapan donanım) ya da Key Vault içinde, ya da en azından şifreli PKCS#8 ve erişimi kısıtlı bir secret store'da durmalı.

Sık Düşülen Tuzaklar

Birinci ve en yaygın tuzak, private key'i repo'ya ya da log'a koymak. Test için üretilen key.pem dosyası bir commit'e girer, repo bir gün public olur. Bu projenin .gitignore dosyasında *.pem ve *.key satırları bu yüzden var; DevSecOps serisinde anlatılan secret taraması da pipeline'da bunu yakalar. Log tarafında ise anahtar nesnesini ya da PEM metnini asla loglama; keyId yeterli.

İkincisi, RSA'yı PKCS#1 v1.5 padding ile kullanmak. Eski bir sistemle uyumluluk zorunlu değilse OAEP kullan; zorunluysa, çözme hatalarının dışarıya farklı yanıtlar olarak sızmadığından emin ol.

Üçüncüsü, ECDH ortak sırrını doğrudan anahtar yapmak ya da HKDF'e bağlam bilgisi vermemek. Aynı anahtar çifti iki farklı amaçla kullanılıyorsa info parametresi bu iki kullanımı birbirinden ayıran tek şey.

Dördüncüsü, gelen public key'i doğrulamadan kullanmak: başka bir eğri, geçersiz bir nokta ya da yanlış algoritma. ImportSubjectPublicKeyInfo noktanın eğri üzerinde olduğunu kontrol ediyor; eğrinin beklediğin eğri olduğunu ise sen kontrol etmelisin.

Beşincisi, "şifreli" ile "imzalı"yı karıştırmak. Tedarikçinin public key'i herkeste olduğu için, bu dosyayı herkes üretebilir. Dosyanın gerçekten Bookstore'dan geldiğini kanıtlamak için bir digital signature gerekiyor; bu da bir sonraki yazının konusu.

Küçük Bir Deneme

★☆☆ purchase-order komutunda PbeParameters'ın iterasyon sayısını 600.000'den 6.000.000'a çıkar ve ImportFromEncryptedPem süresini ölç. Bu süreyi kim, ne sıklıkla ödüyor? Bir web sunucusunun her istekte bu işlemi yapması neden yanlış olur?

★★☆ EcdhHybrid'i P-384 ile çalışacak şekilde genişlet: algoritma adına eğriyi ekle, çözme tarafında eğri kontrolünü algoritma adına göre yap. P-256 ile şifrelenmiş bir dosyanın P-384 anahtarıyla açılmaya çalışıldığında hangi exception'ı verdiğini test et.

★★★ Tedarikçi anahtar rotasyonunu tasarla: Bookstore'un elinde keyId'lerle eşlenmiş birden fazla tedarikçi public key'i olsun, yeni dosyalar en yeni anahtarla şifrelensin, tedarikçi tarafında da keyId'ye göre doğru private key'i seçen bir SupplierKeyRing yaz. Bilinmeyen bir keyId geldiğinde ne olmalı?

Bir sonraki yazıda bu yazının son tuzağını çözüyoruz: dosyayı kimin ürettiğini kanıtlamak. RSA-PSS ve ECDSA (elliptic curve tabanlı imza algoritması) ile digital signature, imza formatları, JSON imzalarken canonicalization sorunu ve Bookstore'un offline çalışan kurumsal kurulumları için imzalı bir lisans dosyası.