---
title: "Post-quantum cryptography, Red Hat AI Enterprise'ı nasıl etkiliyor"
description: "Red Hat, post-quantum cryptography geçişinin AI pipeline'ları, model registry ve KServe endpoint'lerine etkisini anlattı. Hazırlık sırası burada."
image: "https://sezer.in/wp-content/uploads/2026/11/red-hat-social-share.jpg"
url: "https://sezer.in/haberler/post-quantum-cryptography-red-hat-ai-enterprise/"
date: "2026-11-03T22:12:05+03:00"
updated: "2026-11-03T22:12:05+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/post-quantum-cryptography-red-hat-ai-enterprise/"
---

# Post-quantum cryptography, Red Hat AI Enterprise'ı nasıl etkiliyor

Red Hat, post-quantum cryptography geçişinin Red Hat AI Enterprise bileşenlerini nasıl etkileyeceğini Workbench'ten model serving'e kadar tek tek anlattı. Şirket, NIST'in Ağustos 2024'te yayımladığı FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) ve FIPS 205 (SLH-DSA) standartlarını platformuna ekliyor. RHEL 9'da DEFAULT:PQ alt politikasıyla açılan bir Technology Preview olan PQC, RHEL 10.1'de varsayılan olarak açık geliyor.

## post-quantum cryptography nedir, ne işe yarar?

Post-quantum cryptography, yeterince güçlü kuantum bilgisayarların kıramayacağı varsayılan şifreleme ve dijital imza algoritmalarının genel adıdır. RSA ve elliptic curve tabanlı yöntemlerin yerini almak için geliştiriliyor. NIST bu alanda ML-KEM, ML-DSA ve SLH-DSA gibi algoritmaları standartlaştırdı. Geçiş sırasında klasik ve kuantuma dayanıklı algoritmaları birlikte kullanan hibrit modlar yaygın olarak tercih ediliyor.

## ML-KEM nedir, ne işe yarar?

ML-KEM, lattice tabanlı bir key encapsulation mekanizmasıdır ve önceki adı CRYSTALS-Kyber'dir. NIST tarafından FIPS 203 olarak standartlaştırıldı. TLS gibi protokollerde oturum anahtarını güvenli biçimde paylaşmak için kullanılır. Genellikle X25519 gibi klasik bir key exchange ile hibrit modda birlikte çalıştırılır.

## Bugün geçerli olan ve yol haritasında kalan

Yazıdaki değişikliklerin çoğu gelecek zamanla anlatılıyor. Bugün elle tutulur olan kısım işletim sistemi katmanı. RHEL 10.1'de PQC varsayılan olarak açık ve TLS handshake'i hibrit modda X25519 ile ML-KEM'i birlikte kullanabiliyor. Biri kırılırsa diğeri oturumu korumaya devam ediyor.

Image imzalarının ML-DSA ile doğrulanması, model ağırlıklarının imzalanması ve pipeline'larda CBOM taraması ise hazırlık aşamasında. Kaynak, temel PQC imzalama stratejisinin "in process" olduğunu, CBOM doğrulaması için scanner tarafında da çalışmanın sürdüğünü açıkça yazıyor. Yani post-quantum cryptography geçişinde bugün planlayabileceğiniz şey trafik şifrelemesi. İmza tarafında ürünün olgunlaşmasını bekliyorsunuz.

## Önce inference endpoint'leri

HNDL ("harvest now, decrypt later") saldırısında saldırgan şifreli trafiği bugün kaydediyor. Çözmek için ileride yeterince güçlü bir kuantum bilgisayarı bekliyor. Bu yüzden ömrü uzun gizli veri taşıyan bağlantılar öne çıkıyor. KServe endpoint'ine giden prompt'lar tam bu türden: finans özetleri, müşteri verisi, iç belgeler. Kaynak da model serving katmanını en riskli nokta olarak gösteriyor.

Burada kırılma noktası ağ yolundaki eski bileşenler. ML-KEM anahtarları ve şifreli metinleri elliptic curve karşılıklarından büyük. Önünüzdeki load balancer (yük dengeleyici) ya da eski bir client kütüphanesi büyüyen handshake'i kaldıramazsa inference (çıkarım) isteklerinde timeout ve kopan bağlantı görürsünüz. Önce node'lardaki crypto policy'yi ve OpenSSL sürümünü kontrol edin, sonra endpoint'e dışarıdan bağlanın:

```
update-crypto-policies --show
openssl version
openssl s_client -connect model-endpoint.example.com:443 </dev/null
```

Bağlantıyı güncel bir RHEL 10.1 host'undan ve üretimdeki en eski client'ın çalıştığı ortamdan ayrı ayrı deneyin. Hibrit mod bu karışık durum için tasarlandı: eski client klasik X25519 ile, güncellenmiş bir iç servis ML-KEM ile aynı modele ulaşabiliyor.

## İmzalar hibrit gelmiyor

Yazıdaki en az göze çarpan ama en çok iş çıkaracak ayrıntı şu. Key exchange tarafında hibrit mod eski client'larla uyumu koruyor. ML-DSA imzaları ise pure PQC sertifikalarıyla dağıtılacak. OpenShift Service Mesh ile kurulan service mesh (servis ağı) içindeki mTLS için cert-manager'ın da pure ML-DSA sertifika üretmeye geçeceği belirtiliyor.

Pratik sonucu açık: ML-DSA'yı tanımayan bir bileşen bu sertifikayı doğrulayamaz. Mesh içinde kendi build ettiğiniz eski bir sidecar (yardımcı container) image'ı ya da güncellenmeyen üçüncü taraf bir operator varsa, post-quantum cryptography geçişinde ilk kırılacak parça o olur. Kaynak, Workbench'i S3 ya da ODF'ye bağlayan driver ve operator'ların PQC destekli kütüphanelerle, örneğin PQC destekli Go sürümleriyle derlenmesi gerektiğini de söylüyor. Envanteri bu gözle çıkarın: hangi bileşen hangi TLS kütüphanesiyle build ediliyor ve onu kim güncelliyor.

Pipeline tarafında beklenen kural da sert. İmzası ML-DSA ile doğrulanamayan image'ı OpenShift admission controller durduracak. Tekton ya da Argo Workflows ile çalışan pipeline'larınızın hangi CUDA base image'larını ve özel Python ortamlarını nereden çektiğini şimdiden listeleyin. Kural devreye girdiğinde imzasız image'lar bu listeden çıkacak.

## Workbench trafiğinde performans payı

Dağıtık training sırasında yüzlerce paralel veri çekme süreci açılınca her handshake biraz daha fazla bant genişliği harcıyor. Kaynak bu yükü "slightly higher" diye niteliyor, yani darboğaz beklemeyin ama ölçün. Bağlantıları yeniden kullanan client yapılandırması handshake sayısını, dolayısıyla bu yükü azaltır. MPI ve NCCL ile giden worker trafiğinin bir kısmı zaten şifresiz çalışıyor. Değişiklik bu katmana değil, control plane trafiğine dokunuyor.

## Post-quantum cryptography hazırlığında sıra

- Kriptografi envanteri çıkarın. Kaynak bunun için Red Hat Lightspeed telemetry ve Ansible Automation Platform öneriyor. Modellerin nerede durduğu, Workbench'in veriye nasıl bağlandığı, KServe endpoint'lerini hangi sertifikanın koruduğu listede olsun.
- Node'ları RHEL 10'un PQC yeteneklerine taşıyacak OpenShift yükseltmesini planlayın. RHEL 9'da PQC'yi DEFAULT:PQ ile açtıysanız, 10.1'de bu alt politika genel açma anahtarı olarak gerekmiyor; yükseltme sonrası özel policy'lerinizi gözden geçirin.
- Edge'deki load balancer, ingress ve client'larla büyük handshake testini yapın.
- Mesh ve operator envanterini pure ML-DSA uyumuna göre işaretleyin.

Ertelenebilecek iş de belli. Kaynak, AI pipeline'larını bugün yeniden yazmanız gerekmediğini söylüyor. Model imzalama ve CBOM taraması ürün tarafında hazır olduğunda devreye alınacak; o güne kadar yapılacak iş, imzalanacak artifact'lerin ve image'ların listesini hazır tutmak.