Soru:
ECDSA - ECDH - Ed25519 - Curve25519
Omar
2014-02-04 15:53:50 UTC
view on stackexchange narkive permalink

OpenSSH'de (ECDH, ECDSA, Ed25519, Curve25519) bulunan ve en iyi güvenlik seviyesini sunan ECC algoritmaları arasında ve (ideal olarak) neden?

Bu oldukça garip bir ifade şekli. Curve25519, Diffie-Hellman (ECDH) yapabileceğiniz belirli bir eğridir. Diffie-Hellman, bir anahtarı değiştirmek için kullanılır. Ed25519 ve ECDSA imza algoritmalarıdır.
related: [SSH Anahtarı: Ed25519 - RSA] (http://security.stackexchange.com/questions/90077/ssh-key-ed25519-vs-rsa)
Ayrıca Bernstein'ın [Curve25519: yeni Diffe-Hellman hız kayıtları] 'na bakın (https://cr.yp.to/ecdh/curve25519-20060209.pdf).Oldukça iyi bir iş çıkarmış gibi görünüyor ve birçok sorunuzu yanıtlıyor.
Beş yanıtlar:
Tom Leek
2014-02-04 18:32:23 UTC
view on stackexchange narkive permalink

SSH'de iki algoritma kullanılır: bir anahtar değişim algoritması (Diffie-Hellman veya ECDH olarak adlandırılan eliptik eğri varyantı) ve bir imza algoritması. Anahtar değişimi, o oturum için verileri şifrelemek için kullanılacak gizli anahtarı verir. İmza, istemcinin doğru sunucuyla konuştuğundan emin olmasını sağlamak içindir (sunucu anahtar tabanlı istemci kimlik doğrulamasını zorlarsa istemci tarafından hesaplanan başka bir imza kullanılabilir).

ECDH bir eğri ; çoğu yazılım standart NIST eğrisi P-256 kullanır. Curve25519, "satış perdesi" P-256'dan daha güçlü değil daha hızlı olduğu başka bir eğridir. İnsan açısından performans farkı çok küçük: küçük bir bilgisayarda bir milisaniyeden daha az değerde hesaplamalardan bahsediyoruz ve bu SSH oturumu başına yalnızca bir kez oluyor. Fark etmeyeceksin. Her iki eğrinin de diğerinden "daha güçlü" olduğu söylenemez, pratik olarak (her ikisi de "kıramaz" diyarındadır) ne de akademik olarak (her ikisi de "128 bit güvenlik seviyesindedir").

Anahtar değişimi için ECDH kullanıldığında bile, çoğu SSH sunucusu ve istemcisi imzalar için DSA veya RSA anahtarlarını kullanır. Eliptik eğrilere dayalı bir imza algoritması istiyorsanız, bu ECDSA veya Ed25519; Eğri denkleminin kesin tanımı nedeniyle bazı teknik nedenlerden dolayı, bu P-256 için ECDSA, Curve25519 için Ed25519. Yine de, hiçbiri diğerinden daha güçlü değil ve hız farkı bir insan kullanıcı tarafından tespit edilemeyecek kadar küçük. Ancak çoğu tarayıcı (Firefox ve Chrome dahil) artık ECDH'yi desteklemiyor (dh de).

P-256 kullanımı şu anda daha iyi birlikte çalışabilirlik sağlamalıdır, çünkü Ed25519 çok daha yeni ve yaygın değil. Ancak yapılandırdığınız ve kendi makinelerinizden erişmek istediğiniz belirli bir sunucu için birlikte çalışabilirlik çok önemli değildir: hem istemci hem de sunucu yazılımını siz kontrol edersiniz.

Yani, temelde seçim estetiğe, yani mantıklı bir neden olmaksızın tamamen size kalmış. Zaten bu seçim güvenlik sorunlarına neden olmayacak; kriptografik algoritmalar, en zayıf değil, tüm sisteminizin en güçlü parçasıdır.

25519 için "satış konuşması" daha fazla: NIST değil, dolayısıyla NSA değil. Hız değil.
Aslında çok da hızlı. İyi yapılandırılmış Edwards / Montgomery eğrileri, yerleşik NIST eğrilerinden birkaç kat daha hızlı olabilir. Https://www.imperialviolet.org/2010/12/21/eccspeed.html
Aslında, yeni bir bilgisayarda gerçekten hız istiyorsanız, NIST onaylı ikili Koblitz eğrileri daha da hızlıdır (x86 AES talimatıyla birlikte gelen "taşımasız çarpma" işlem kodu sayesinde); K-233'te genel bir nokta çarpımı için 40000 döngü gibi bir şeye kadar, Curve25519'dan iki kat daha hızlı - ancak bu ekstra hızın gerçekten gözle görülür bir fark yarattığı bir senaryo bulmak zor.
[Bu IETF taslağından] (https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03#section-4) daha fazla "satış konuşması" geliyor: _NIST eğrilerinin rasgele olarak doğrulanabilir bir şekilde seçildiği ilan edilirken, bunları oluşturmak için kullanılan tohumlar için herhangi bir açıklama yoktur.Aksine, bu eğrileri seçmek için kullanılan süreç tamamen belgelenmiştir ve yeterince katıdır, böylece bağımsız doğrulama yapılmıştır.Üreten tarafın parametreleri kötü niyetle değiştirmesini engellediğinden, bu yaygın olarak bir güvenlik avantajı olarak görülmektedir.
DJB'nin http://safecurves.cr.yp.to/ web sitesine göre, NIST eğrisi Curve25519 kadar güvenli veya kusursuz olmayabilir.
Aslında üç algoritma var.Ana bilgisayar (ve istemci) anahtar algoritması (kimlik doğrulama), anahtar değişimi (kex) algoritması ve şifre.
@MartinSchröder, Enigma da Amerikalılar tarafından icat edilmedi ...
Ed25519 ile ortak anahtarın SSH ile kullanım için 4096 bit RSA'dan çok daha kısa olduğunu anlıyorum.
Brian Minton
2014-03-14 20:53:08 UTC
view on stackexchange narkive permalink

Ed25519'a Giriş 'ten, hız açısından bazı avantajlar ve bazı güvenlik avantajları vardır. Daha ilginç güvenlik avantajlarından biri, birkaç yan kanal saldırısına karşı bağışık olmasıdır:

  • Gizli dizi indeksi yok. Yazılım, RAM'deki gizli adreslerden verileri asla okumaz veya yazmaz; adreslerin örüntüsü tamamen tahmin edilebilir. Bu nedenle yazılım, önbellek zamanlama saldırılarına, hiper iş parçacığı saldırılarına ve CPU önbelleği yoluyla adres sızıntısına dayanan diğer yan kanal saldırılarına karşı bağışıktır.
  • Gizli dal koşulları yoktur. Yazılım hiçbir zaman gizli verilere dayalı koşullu şubeler gerçekleştirmez; sıçrama paterni tamamen tahmin edilebilir. Bu nedenle yazılım, şube tahmin birimi aracılığıyla bilgi sızıntısına dayanan yan kanal saldırılarına karşı bağışıktır.

Karşılaştırma için, çeşitli algoritmalar üzerinde gösterilen birkaç gerçek dünya önbellek zamanlama saldırısı oldu. http://en.wikipedia.org/wiki/Timing_attack

* "Daha ilginç güvenlik avantajlarından biri, çeşitli yan kanal saldırılarına karşı bağışık olmasıdır" * - Açık olanı belirtmek için, bu uygulamaya bağlıdır.Bernstein ekibinin kodu, Adam Langley'in kodu, Andrew Moon'un kodu (ve diğerleri) tamam olmalıdır.Ama keyfi bir uygulama için aynı şeyi söyleyebileceğinizi sanmıyorum.
Sanırım algoritmanın tasarımı, onu gizli dizi indeksleri veya dallanma koşulları kullanmadan gerçekleştirmeyi mümkün kılıyor demek daha doğru olur.Elbette, kötü bir şekilde uygulamanın hala mümkün olacağı konusunda haklısınız.
Uygulamaya bağlı olduğu için tek seferlik pedler güvenli değildir.
lxgr
2014-12-01 17:53:29 UTC
view on stackexchange narkive permalink

Ed25519'un (EC) DSA'ya göre önemli bir pratik avantajı vardır: İkinci algoritma ailesi, bozuk bir rastgele sayı oluşturucu ile birlikte imzalar için kullanıldığında tamamen bozulur. Böyle bir RNG hatası daha önce olmuştur ve çok iyi bir şekilde tekrar olabilir.

Teorik olarak, uygulamalar bu özel soruna karşı koruma sağlayabilir, ancak çok daha zordur her iki ucun da güvenli davranışı açıkça belirten bir algoritmayı (uyumluluk ihtiyaçlarınıza bağlı olarak) tercih etmekten veya uygulamaktan daha doğru bir uygulama kullandığını doğrulamak için (Ed25519).

zenith
2014-02-08 03:27:41 UTC
view on stackexchange narkive permalink

Curve25519'un, eğrinin şekli nedeniyle çeşitli yan kanal saldırılarına ve uygulama hatalarına karşı daha az uygun hale geldiğinden, aslında NIST eğrilerinden daha güvenli olduğu izlenimine kapılmıştım. Bkz .: http://safecurves.cr.yp.to

Ed25519, anahtar sözleşmeyi imzalamak için aynı anahtarı kullanabilme avantajına sahiptir (normalde Bunu yap). Bunun bir Edwards eğrisi olma özelliği olup olmadığını söyleyecek kadar matematiği yeterince iyi bilmiyorum, ancak anahtar anlaşma için Montgomery koordinat sistemine (etkin bir şekilde Curve25519'a) dönüştürüldüğünü biliyorum ... Ed25519 daha fazlası bir eğriden ziyade, akılda tutulması gereken diğer şeyler arasında (örneğin hashing) deterministik anahtar üretimini belirtir. Bu, birlikte çalışabilirliği korumak için farklı şekilde ele alınmaları gerektiğinden, olduğu gibi DJB uygulamaları hakkında sinir bozucu bir şeydir.

Mecki
2019-06-07 18:04:24 UTC
view on stackexchange narkive permalink

Şimdiye kadar hiçbir yanıtın doğrudan değinilemediği bir şey, sorularınızın az çok ilgisiz isimleri, sanki bunlar birbirine eşdeğer alternatiflermiş gibi bir araya getirmesidir ki bu aslında durum böyle değildir.

ECDH ve ECDSA sadece şifreleme yöntemlerinin isimleridir.

ECDH , iki tarafın güvenli olmayan bir anahtar üzerinde güvenli bir anahtar üzerinde pazarlık yapmak için kullanabileceği bir anahtar değişim yöntemidir. iletişim kanalı. Bu, DH (Diffie-Hellman) anahtar değişim yönteminin bir varyasyonudur. ECDH, Eliptik Eğri Diffie – Hellman anlamına gelir. Yine de ECDH yalnızca bir yöntemdir; bu, onu yalnızca belirli bir eliptik eğri ile kullanamayacağınız, onu birçok farklı eliptik eğri ile kullanabileceğiniz anlamına gelir.

ECDSA , bir veri parçasını, verilerde yapılacak herhangi bir değişikliğin imza doğrulamasının başarısız olmasına neden olacak şekilde imzalamak için kullanılabilir, ancak bu tür bir değişiklikten sonra saldırgan verileri doğru şekilde yeniden imzalayamaz. DSA 'nın (Dijital İmza Algoritması) bir varyasyonudur. ECDSA, Eliptik Eğri Dijital İmza Algoritması anlamına gelir. Ayrıca ECDSA yalnızca farklı eliptik eğrilerle kullanılabilen bir yöntemi açıklar.

ECDH ve ECDSA'nın güvenliği bu nedenle iki faktöre bağlıdır:

  1. Yöntemin kendisi ne kadar güvenli ? Yöntem güvenli değilse, kelimedeki en iyi eğri bunu değiştirmez.
  2. Kullanılan eğri ne kadar güvenli? Eğri güvenli değilse, yöntem teorik olarak doğru ise bir rol oynamayacaktır.

Curve25519 belirli bir eliptik eğrinin adıdır. Diğer eğriler Curve448, P-256, P-384 ve P-521 olarak adlandırılır.

Ed25519 , EdDSA 'nın somut bir varyasyonunun adıdır. . SHA-512 ve Curve25519 kullanarak EdDSA gerçekleştirirken, bu varyasyon Ed25519 olarak adlandırılır. EdDSA, tıpkı ECDSA gibi bir imza algoritmasıdır.

Bu nedenle, bir uygulama yalnızca anahtar değişimi için ECDH'yi veya verileri imzalamak için ECDSA'yı kullandığını söylüyorsa, belirli bir eğriden bahsetmeden, genellikle NIST eğrilerini (P-256, P-384 veya P-) kullanacağını varsayabilirsiniz. 512), yine de uygulama aslında kullanılan eğriyi her zaman açıkça belirtmelidir.

Güvenlik hakkındaki sorunuza cevap vermek gerekirse: ECDH ve ECDSA'nın kavramsal güvenli anahtar değişimi ve imzalama yöntemleri olduğu hemen hemen kanıtlanmıştır, dolayısıyla güvenlik ECDH ve ECDSA'nın en büyük kısmı, birisinin genel olarak eliptik kriptografiyi nasıl kıracağına (çok az olası ama imkansız değil) veya kullanılan eğrilerde bir kusur bulup bulmadığına (daha muhtemel) bağlıdır.

Bazı insanların NIST standart eğrileri yerine Curve25519'u tercih etmesinin nedeni, NIST'in neden bu eğrileri mevcut alternatifler lehine seçtiğini açıkça belgelememiş olmasıdır. " Eğriler, görünüşte en iyi güvenlik ve uygulama verimliliği için seçilmiştir " genel ifadesi, pazarlamaya çok benziyor ve kriptografik uzmanları ikna etmiyor.

NIST ayrıca 2006'da rastgele sayı üreteci tabanlı bir eliptik eğri şifrelemesini (Dual_EC_DRB) standartlaştırdı ve New York zamanları (Edward Snowden tarafından sızdırılan notları inceledikten sonra) NIST'i standardize etmek için etkileyen NSA olduğunu iddia etti bu özel rasgele sayı üreteci. Bu jeneratörde çok büyük bir zayıflık keşfedildi ve bunun NSA tarafından o jeneratöre dayalı TLS şifrelemesini kırabilmek için yerleştirilen kasıtlı bir arka kapı olduğuna inanılıyor. Görünüşe göre ANSI, Dual_EC_DRB ilk kez kendilerine gönderildiğinde zayıflığı keşfetti, ancak bundan nasıl kaçınılacağının farkında olmalarına rağmen, ne algoritmayı geliştirdiler ne de zayıflıkları duyurdular, bu yüzden buna izin verilmediğine inanılıyor (tıkaç emri) ). Zayıflık kamuya açık hale geldiğinde, standart 2014'te geri çekildi.

Bu arka plan bilgisiyle, elbette, insanlar gizemli NIST eğrisi parametrelerinin kaynağının aslında NSA olup olmadığını merak etmeye başladılar, çünkü bu eğriler de henüz kamuya açıklanmayan gizli zayıflıkları da içeriyor olabilir, ancak NSA biliyor olabilir. onlar hakkında ve böylece bu eğrilere dayanarak kriptografiyi kırabilir. Bu iddia için hiçbir kanıt yok, hatta varsayımsal bir kanıt bile yok ama kesinlikle mümkün ve bir peri masalından daha gerçekçi görünüyor. İşte bu yüzden insanlar bu eğrilere olan güvenlerini kaybettiler ve bunların dünya çapında herhangi bir gizli servisten etkilenme ihtimalinin düşük olduğu alternatiflere geçtiler.

Curve25519, Alman-Amerikan matematikçi ve kriptolog Daniel J tarafından yayınlandı Aynı zamanda ünlü Salsa20 akış şifresini ve şimdi yaygın olarak kullanılan ChaCha20 varyantını da tasarlayan Bernstein, 2005'te. Poly1305 mesaj kimlik doğrulamasını da icat etti. Google, ChaCha20'nin Poly1305 ile kombinasyon halinde, algoritma bozulmuş olduğu için RC4'ün kaldırılması gerektiğinden sonra TLS'de kullanılmak üzere güvenli bir alternatif olduğuna karar verdi. AES blok yonga cihazını kullanmaktan çok daha az hesaplama gücü gerektirir (pil çalışma süresinden tasarruf sağladığı için mobil cihazlar için çok yararlıdır), ancak yine de karşılaştırılabilir güvenlik sağladığına inanılmaktadır. ChaCha20 / Poly1305, RFC 7905'te standartlaştırılmıştır ve bugün itibariyle TLS istemci-sunucu iletişiminde yaygın olarak kullanılmaktadır. Dolayısıyla, Bernstein bir NSA casusu olsaydı, ki bu pek olası değildir, o zamanki haliyle hepimiz mahkum olacaktık, bugün sıklıkla kullanıldığı için TLS, verileri gizli servislerin gözünden korumak için muhtemelen yararsız olacaktır.

ECDSA çoklu eğrilerle kullanılabilmesine rağmen, aslında Bernstein'la kullanılmamaktadır.Ed25519 ve Ed448, farklı bir algoritma olan EdDSA'nın bazı teknik avantajları olan örnekleridir.Ve OpenSSH'de (sorulduğu gibi) komut seçeneği "ssh-keygen -t ecdsa" ve varsayılan dosya adı "id_ecdsa *" eğriyi değil, kablo ve "bilinen_hosts" vb. Dahil olmak üzere gerçek anahtarı (içerik) belirtir _do_;bkz. rfc5656.NistP-521 dahil, mevcut olmayan P-512 değil.
@dave_thompson_085 ECDSA'nın Bernstein ile kullanıldığını hiç iddia etmedim.OpenSSH'nin bir eğri belirlediğini hiç iddia etmedim.Bu yüzden lütfen daha önce yazmadığım şeyleri yorumlamaktan kaçının.Ve P-512 açıkça EdDSA için ECDSA gibi bir yazım hatasıydı, sonuçta çok fazla metin yazdım, bu yüzden yazım hataları hemen oldu.
Revizyon açıklamasında "sinir bozucu nitpickers" ı yanlış yazdığınız yerde bir yazım hatası olduğunu belirtmek istedim.


Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...