Bu çeviri makine öğrenimi kullanılarak oluşturulmuştur ve %100 doğru olmayabilir. İngilizce versiyonu görüntüle

Yeni Şifreleme Öneri Şablonu

Proposal 142
Meta
Author zzz
Created 2018-01-11
Last Updated 2018-01-20

Genel Bakış

Bu belge, ElGamal asimetrik şifrelememizin yerine geçecek veya buna eklenecek bir öneri sunarken dikkate alınması gereken önemli konuları açıklamaktadır.

Bu bir bilgilendirme belgesidir.

Motivasyon

ElGamal eski ve yavaştır ve daha iyi alternatifler mevcuttur. Ancak yeni bir algoritma eklemek veya geçiş yapmak için çözülmesi gereken birkaç sorun vardır. Bu belge bu çözülmemiş sorunlara dikkat çekmektedir.

Arka Plan Araştırması

Yeni kripto öneren herkesin öncelikle aşağıdaki belgelerle aşina olması gerekir:

Asimetrik Kripto Kullanımları

Gözden geçirme amaçlı, ElGamal’ı şu amaçlarla kullanıyoruz:

  1. Tünel Oluşturma mesajları (anahtar RouterIdentity içinde yer alır)

  2. Netdb ve diğer I2NP mesajlarının yönlendirici-yönlendirici şifrelenmesi (Anahtar RouterIdentity içinde yer alır)

  3. İstemci uçtan uca ElGamal+AES/OturumEtiketi (anahtar LeaseSet içinde yer alır, Hedef anahtarı kullanılmaz)

  4. NTCP ve SSU için geçici DH

Tasarım

ElGamal’ı başka bir şeyle değiştirmeyi öneren herhangi bir teklifin aşağıdaki ayrıntıları sağlaması gerekir.

Spesifikasyon

Yeni asimetrik kripto için herhangi bir teklif aşağıdaki unsurları tam olarak belirtmelidir.

1. Genel

Teklifinizde aşağıdaki soruları yanıtlayın. Aşağıdaki 2. maddedeki teknik detaylardan ayrı bir teklif olması gerekebileceğine dikkat edin, çünkü bu mevcut 111, 123, 136, 137 veya diğer tekliflerle çakışabilir.

  • Yukarıdaki 1-4 durumlarının hangileri için yeni kriptonun kullanılmasını öneriyorsunuz?
  • Eğer 1) veya 2) (yönlendirici) içinse, açık anahtar RouterIdentity içinde mi yoksa RouterInfo props içinde mi yer alacak? Anahtar sertifikasında kripto türünü kullanmayı mı planlıyorsunuz? Tam olarak belirtin. Her iki durumda da kararınızı gerekçelendirin.
  • Eğer 3) (istemci) içinse, açık anahtarı hedeften mi saklamayı ve anahtar sertifikasında kripto türünü mi kullanmayı planlıyorsunuz (ECIES teklifinde olduğu gibi), yoksa LS2’de mi saklamayı düşünüyorsunuz (123. teklif gibi), ya da başka bir şey mi? Tam olarak belirtin ve kararınızı gerekçelendirin.
  • Tüm kullanımlar için destek nasıl duyurulacak? Eğer 3) içinse, bu LS2’ye mi eklenecek yoksa başka bir yere mi? Eğer 1) ve 2) içinse, bu 136 ve/veya 137. tekliflere benzer mi olacak? Tam olarak belirtin ve kararlarınızı gerekçelendirin. Muhtemelen bunun için ayrı bir teklif gerekecektir.
  • Bunun nasıl ve neden geriye dönük uyumlu olduğunu tam olarak belirtin ve geçiş planını eksiksiz şekilde tanımlayın.
  • Teklifinizin ön koşulu olan henüz uygulanmamış teklifler hangileridir?

2. Spesifik kripto türü

Teklifinizde aşağıdaki soruları yanıtlayın:

  • Genel kripto bilgisi, spesifik eğriler/parametreler, seçiminizi tam olarak gerekçelendirin. Spesifikasyonlara ve diğer bilgilere bağlantılar verin.
  • ElG ve diğer alternatiflerle karşılaştırılmış hız testi sonuçları (uygulanabiliyorsa). Şifreleme, çözme ve anahtar oluşturma işlemlerini dahil edin.
  • C++ ve Java’da (hem OpenJDK, hem BouncyCastle hem de üçüncü taraf) kütüphane uygunluğu Üçüncü taraf veya Java dışı için bağlantılar ve lisanslar verin
  • Önerilen kripto türü numarası/ları (deneysel aralıkta mı değil mi)