İçeriğe atla
HexaTransfer
Bloga dön
Karsilastirmalar ve alternatifler

Dosya Transferi Şifreleme Yöntemlerinin Ayrıntılı Karşılaştırması

AES-256, RSA, ChaCha20 ve uçtan uca ile sunucu tarafı şifreleme yaklaşımları dahil dosya transferi şifreleme yöntemlerinin teknik karşılaştırması.

2026'da dosya transferi servisleri beş temel şifreleme modelinden birini kullanıyor: yalnızca TLS (veri iletim sırasında şifrelenir, sunucuda düz metin olarak durur), sunucu taraflı AES-256 (sağlayıcı anahtarları elinde tutar), istemci taraflı AES-256-GCM via Web Crypto API (uçtan uca, anahtar URL fragment'ında), XChaCha20-Poly1305 akış şifrelemesi (genişletilmiş nonce, libsodium ve Tresorit tarafından kullanılır) ve OpenPGP hibrit şifrelemesi (Curve25519 ECC + AES-256 oturum anahtarları, Proton tarafından kullanılır). Doğru seçim tehdit modeline, performans kısıtlarına ve GDPR/KVKK gibi yasal gereksinimlere bağlıdır. Bu karşılaştırma her modelin ne yaptığını ve nerede başarısız olduğunu açıklar.

Beş Şifreleme Modeli

Model bir: Yalnızca TLS 1.3. Dosya, ağ iletimi sırasında şifrelenir; ardından sunucuda düz metin olarak saklanır. Örnekler: TLS üzerinden temel FTP (FTPS), aktarım sırasında şifreleme olmaksızın yapılan HTTP POST yüklemeleri. Pasif ağ dinlemesine karşı korur; başka hiçbir tehdide karşı değil.

Model iki: TLS + sunucu taraflı aktarımda şifreleme. AES-256, depolanan dosyayı şifreler; sağlayıcı ana anahtarı elinde tutar (genellikle AWS KMS, GCP Cloud KMS veya eşdeğeri içinde). Örnekler: WeTransfer, SwissTransfer, Dropbox. Soğuk depolama hırsızlığına karşı korur; içeriden erişime, mahkeme celbi veya canlı sunucu ihlaline karşı korumaz.

Model üç: Simetrik anahtarlı istemci taraflı E2EE. Tarayıcı veya istemci 256 bitlik bir anahtar türetir, AES-256-GCM ile şifreler ve anahtarı URL fragment'ına ya da bant dışı kanala yerleştirir. Örnekler: HexaTransfer, Send (Firefox Send protokol türevleri). Sunucu yalnızca şifreli metni görür ve hiçbir koşulda şifre çözme yapamaz.

Model dört: Kimliği doğrulanmış akış şifreleri. XChaCha20-Poly1305, 24 baytlık nonce kullanır (ChaCha20-Poly1305'teki 12 bayta kıyasla); bu da çok büyük dosyalarda doğum günü sınırı çakışmalarını uygulanamaz kılar. Örnekler: libsodium secretbox (Internxt), Tresorit Send. AES-NI donanım hızlandırmasının yaygın olmadığı durumlarda (eski Android cihazlar, IoT) tercih edilir; zira ChaCha20 yazılımda hızlıca çalışır.

Model beş: Hibrit açık anahtar + simetrik. OpenPGP (RFC 9580, 2024 revizyonu), dosya başına AES-256 oturum anahtarını şifrelemek için ECC Curve25519 veya RSA-4096 kullanır. Örnekler: Proton Drive, geleneksel GPG dosya şifrelemesi. Asimetrik anahtar yönetimine olanak tanır; alıcının açık anahtarına sahipseniz gönderici ile alıcı arasında ortak bir sır gerekmez.

AES-256 ile ChaCha20 Arasındaki Gerçek Farklar

Her ikisi de 256 bitlik simetrik şifredir. AES-256, NIST standardıdır (FIPS 197) ve donanım hızlandırmasına sahiptir (x86'da AES-NI, mobilde ARM Kriptografi Uzantıları). Modern donanımda AES-256-GCM, çekirdek başına 2-4 GB/s hızında çalışır. ChaCha20-Poly1305 ise saf yazılımda çekirdek başına 1-2 GB/s hızında çalışır; AES-NI donanımı olmayan sistemlerde AES'ten daha hızlıdır. 4 GB'lık bir dosyayı şifreleyen masaüstü bir bilgisayar için her iki algoritma da iki saniye içinde tamamlar; darboğaz ağdır. Kriptografik açıdan her ikisi de 2026'da eşit derecede güvenli kabul edilmektedir.

RSA Dosya Transferinde Neredeyse Kullanılmıyor

RSA-4096, işlem başına 512 baytlık düz metni şifreler. RSA'yı doğrudan 1 GB'lık bir dosyayı şifrelemek için kullanmak anlamsızdır; milyonlarca 512 baytlık bloğa bölmek gerekir. Desen her zaman hibriddir: RSA, dosya başına AES-256 oturum anahtarını sarar; AES içeriği şifreler. ECC Curve25519, çoğu yeni tasarımda RSA'nın yerini almıştır; daha hızlı, daha küçük anahtarlarla (256 bit ECC, 3072 bit RSA güvenliğine eşdeğerdir) ve zamanlama saldırılarına karşı dirençlidir. 2024 güncellemeli OpenPGP, RSA yerine Curve25519'u (anahtar değişimi için X25519) önermektedir. RSA'yı yalnızca eski SFTP dağıtımlarında görmeye devam edersiniz.

URL Fragment Anahtarları Neden Belirleyicidir

HexaTransfer ve Firefox Send protokol soyağacı, şifreleme anahtarını URL fragment'ına (#'den sonraki kısım) yerleştirir. Tarayıcılar, RFC 3986 gereği fragment'ları HTTP isteğinde hiçbir zaman iletmez. Bu, sunucunun GET /file/abc123 gibi bir istek aldığı ancak anahtarı içeren fragment'ı asla görmediği anlamına gelir. Kullanıcı tam URL'yi yapıştırdığında ya da tıkladığında fragment, tarayıcının belleğinde kalarak istemci taraflı şifre çözmeyi destekler. Bu yaklaşım, ikincil bir kanal gerektirmeksizin paylaşılabilir bir E2EE bağlantısı sunmanın mimari açıdan en zarif yoludur.

Uçtan Uca ve Sunucu Taraflı Şifreleme: Tehdit Modeli Testi

Sunucu taraflı şifreleme yalnızca bir tehdide karşı koruma sağlar: depolama aygıtının fiziksel olarak çalınması. Disk çalınırsa AES-256 şifrelemesi, birisi KMS'yi ele geçirene kadar verileri okunamaz biçimde tutar. Uçtan uca şifreleme ise sunucunun yapabileceği her şeye karşı korur: mahkeme celbi, içeriden erişim, canlı verilere ulaşan fidye yazılımı veya devlet düzeyinde zorlama. Tehdit modeliniz "veri merkezinden disk çalınması" ise sunucu taraflı yeterlidir. "Hükümet, rakip veya saldırgan servisi veri teslim etmeye zorluyor" ise yalnızca E2EE sizi korur.

Kimliği Doğrulanmış Şifreleme Zorunludur

MAC'siz düz AES-CBC, seçili şifreli metin sorguları ile şifreli metni çözebilen dolgu oracle saldırılarına (BEAST, Lucky13) izin verir. Modern dosya transferi, AEAD kullanmak zorundadır: AES-256-GCM (NIST SP 800-38D) veya ChaCha20-Poly1305 (RFC 8439). Poly1305 etiketi veya GCM etiketi, şifreli metni ve ilişkili tüm verileri (dosya boyutu, nonce, dosya adı başlığı) doğrular. İletim sırasında bir bit bozulursa şifre çözme açıkça başarısız olur. 2026'da HMAC sarmalayıcısı olmadan hâlâ AES-CBC kullanan bir servis, 2010 güvenlik anlayışıyla çalışıyor demektir.

Parola Korumalı Transferler İçin Anahtar Türetme

Bir kullanıcı transferi korumak için parola girdiğinde, parolayı doğrudan AES anahtarı olarak kullanamazsınız; düşük entropilidir ve kaba kuvvete açıktır. Modern anahtar türetme seçenekleri: 600.000 iterasyonlu PBKDF2-SHA-256 (OWASP 2023 önerisi), N=2^17 ile scrypt veya 19 MiB bellek ve 2 iterasyonla Argon2id. HexaTransfer, 600.000 iterasyonlu PBKDF2 kullanır. Tresorit, Argon2id kullanır. Her ikisi de GPU destekli parola kırma saldırılarına karşı direnir. 10.000 iterasyonlu PBKDF2 hâlâ kullanan sağlayıcılar (2015 rehberi), yetersiz koruma altındadır.

Karşılaştırma Tablosu

| Yöntem | Gizlilik | Kimlik Doğrulama | Sunucu Düz Metni Görür mü? | Kuantum Riski | |---|---|---|---|---| | Yalnızca TLS 1.3 | İletim sırasında | Evet (MAC) | Evet | Anahtar değişimi risk altında | | Sunucu taraflı AES-256 | Aktarımda + iletimde | Evet | Evet (anahtara sahip) | Düşük | | İstemci taraflı AES-256-GCM | Tam yol | Evet (GCM etiketi) | Hayır | Düşük | | XChaCha20-Poly1305 | Tam yol | Evet (Poly1305 etiketi) | Hayır | Düşük | | OpenPGP (Curve25519 + AES-256) | Tam yol | Evet (MDC/OCB) | Hayır | Curve25519 risk altında |

Kuantum Sonrası Değerlendirmeler

Shor algoritması, yeterince büyük kuantum bilgisayarlar ortaya çıktığında Curve25519 ve RSA'yı tehdit eder. Simetrik şifreler (AES-256, ChaCha20), Grover algoritması tarafından zayıflatılır ancak kırılmaz; 256 bitlik anahtarlar 128 bitlik kuantum sonrası güce sahip olmaya devam eder. NIST, 2024'te kuantum sonrası anahtar kapsülleme için ML-KEM (Kyber) standardını belirledi. Signal, 2023'te PQXDH'ye geçiş yaptı. Dosya transferi servisleri henüz bu yeni standartları geniş çapta benimsemedi; ancak "şimdi topla, sonra şifrele" riski, uzun süreli arşivlerin bugün 256 bitlik simetrik şifreleme kullanmasını zorunlu kılar.

Yöntemi Seçmek

Tek seferlik hassas transfer, kısa saklama: URL fragment anahtarlarıyla istemci taraflı AES-256-GCM. HexaTransfer bu uygulamadır. Süregelen uyumluluk gerektiren iş akışları: denetim günlükleriyle XChaCha20-Poly1305 (Tresorit). Anahtar yönetimiyle çok alıcılı iletişim: OpenPGP (Proton Drive, GPG). Büyük merkeziyetsiz dağıtım: silme kodlamasıyla libsodium secretbox (Storj üzerinde Internxt). Hassas olmayan yüksek hacimli transfer: TLS + aktarımda şifreleme kabul edilebilir. GDPR ve KVKK uyumluluğu için E2EE kullanan AB merkezli bir servis tercih edin.

hexatransfer.com'da deneyin — ücretsiz, hesap gerekmez, 10 GB'a kadar.

Uçtan uca şifreleme ile büyük dosyaları güvenle gönderin

Uçtan uca şifreleme ile 10 GB'a kadar dosya ücretsiz aktarın. Hesap gerekmez. Dosyalarınız yüklenmeden önce tarayıcınızda şifrelenir — başka kimse okuyamaz.

Dosya gönder