WireGuard vs. OpenVPN (Verschlüsselung, Authentifizierung)
Hallo zusammen,
WireGuard wird als sichere (oder sogar derzteit sicherste) VPN-Technik bezeichnet.
Derzeit verbinde ich mich mobil über OpenVPN (for Android) mit meinem Heimnetz (dort läuft der OpenVPN-Server). Ich überlege, dies auf WireGuard umzustellen.
An WireGuard gefällt mir, dass es eine schlanke Konfiguration hat (im Gegensatz zu OpenVPN). Allerdings frage ich mich, wieso WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher sein soll wie OpenVPN.
Bei OpenVPN nutze ich dafür Zertifikate und Schlüssel mit tausenden von Bits. Bei WireGuard werden offenbar lediglich vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen eingesetzt.
Also, daher die Frage: Ist WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher wie OpenVPN obwohl nur vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen anstelle von sehr langen Schlüsseln/Zertifikaten zum Einsatz kommen?
Grüße
M.
WireGuard wird als sichere (oder sogar derzteit sicherste) VPN-Technik bezeichnet.
Derzeit verbinde ich mich mobil über OpenVPN (for Android) mit meinem Heimnetz (dort läuft der OpenVPN-Server). Ich überlege, dies auf WireGuard umzustellen.
An WireGuard gefällt mir, dass es eine schlanke Konfiguration hat (im Gegensatz zu OpenVPN). Allerdings frage ich mich, wieso WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher sein soll wie OpenVPN.
Bei OpenVPN nutze ich dafür Zertifikate und Schlüssel mit tausenden von Bits. Bei WireGuard werden offenbar lediglich vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen eingesetzt.
Also, daher die Frage: Ist WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher wie OpenVPN obwohl nur vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen anstelle von sehr langen Schlüsseln/Zertifikaten zum Einsatz kommen?
Grüße
M.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3928598150
Url: https://administrator.de/contentid/3928598150
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
6 Kommentare
Neuester Kommentar
Moinsen,
kannst du hierfür
eine Quelle anführen?
Das soll nicht provokant gemeint sein, es interessiert mich wirklich (denn das habe ich bisher so noch nicht gehört).
Danke...
kannst du hierfür
Zitat von @Mr.IT.Sec:
WireGuard wird als sichere (oder sogar derzteit sicherste) VPN-Technik bezeichnet.
WireGuard wird als sichere (oder sogar derzteit sicherste) VPN-Technik bezeichnet.
eine Quelle anführen?
Das soll nicht provokant gemeint sein, es interessiert mich wirklich (denn das habe ich bisher so noch nicht gehört).
Danke...
Moin.
Des weiteren kommen hier auch modernere und effizientere Protokolle (wie z.B. ChaCha20) mit elliptischen Kurven zum Einsatz bei denen die Schlüssel in der Regel auch viel kürzer ausfallen können um die gleiche Sicherheit zu erreichen wie mit den Diffie Hellmann Verfahren, weil bei diesen Protokollen der Aufwand für den Angreifer bei geringerer Schlüssellänge wesentlich höher ist. Des weiteren nutzen diese Verfahren auch bevorzugt Hardwarebeschleunigung und bieten so eine bessere Gesamtperformance als OpenVPN.
Und ob dein Key/Zertifikat nun als Datei oder als Base64 kodierter Text vorliegt macht hier ehrlich gesagt keinen Unterschied.
Einfach mal das technische White paper lesen...
https://www.wireguard.com/papers/wireguard.pdf
Also, daher die Frage: Ist WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher wie OpenVPN obwohl nur vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen anstelle von sehr langen Schlüsseln/Zertifikaten zum Einsatz kommen?
Jepp. s.o. das mit den kurzen Schlüsseln ist ja nur ein Missverständnis deinerseits.
Cheers
certguy
Zitat von @Mr.IT.Sec:
Bei OpenVPN nutze ich dafür Zertifikate und Schlüssel mit tausenden von Bits. Bei WireGuard werden offenbar lediglich vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen eingesetzt.
Äh nö, Pivate und Public Key sind nur Base64 kodiert und wirken daher nur kurz! In Wirklichkeit sind die auch 256bit lang, zusätzlich lässt sich mit einem preshared Key zusätzliche 256bits in die Crypto hinein mischen.Bei OpenVPN nutze ich dafür Zertifikate und Schlüssel mit tausenden von Bits. Bei WireGuard werden offenbar lediglich vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen eingesetzt.
Des weiteren kommen hier auch modernere und effizientere Protokolle (wie z.B. ChaCha20) mit elliptischen Kurven zum Einsatz bei denen die Schlüssel in der Regel auch viel kürzer ausfallen können um die gleiche Sicherheit zu erreichen wie mit den Diffie Hellmann Verfahren, weil bei diesen Protokollen der Aufwand für den Angreifer bei geringerer Schlüssellänge wesentlich höher ist. Des weiteren nutzen diese Verfahren auch bevorzugt Hardwarebeschleunigung und bieten so eine bessere Gesamtperformance als OpenVPN.
Und ob dein Key/Zertifikat nun als Datei oder als Base64 kodierter Text vorliegt macht hier ehrlich gesagt keinen Unterschied.
Einfach mal das technische White paper lesen...
https://www.wireguard.com/papers/wireguard.pdf
Also, daher die Frage: Ist WireGuard in Bezug auf Verschlüsselung des Datenverkehrs und gegenseitige Authentifizierung von Server/Client genauso sicher wie OpenVPN obwohl nur vergleichsweise kurze private/öffentliche Schlüssel-Sequenzen anstelle von sehr langen Schlüsseln/Zertifikaten zum Einsatz kommen?
Cheers
certguy
Hallo,
Wireguard ist in der Hinsicht einfacher, dass die Authentifizierung auf 256-Bit-ECC-Schlüssel festgelegt ist. Wenn Du für OpenVPN Schlüssel, bzw. dort signiert als Zertifikate, mit Längen im kb-Bereich gewohnt bist, handelt es sich um RSA-Zertifikate. Ebenso kannst Du OpenVPN aber mit ECC-Zertifikaten betreiben.
Kritisieren kann man, dass 256 Bit für ECC ausreichend, aber schon nicht mehr zeitgemäß ist, und die Wahl für ein "modernes" VPN eher pragmatisch erscheint, vergleichbar mit 2048 Bit RSA- oder 128 Bit AES-Schlüssellängen.
Grüße
Richard
Wireguard ist in der Hinsicht einfacher, dass die Authentifizierung auf 256-Bit-ECC-Schlüssel festgelegt ist. Wenn Du für OpenVPN Schlüssel, bzw. dort signiert als Zertifikate, mit Längen im kb-Bereich gewohnt bist, handelt es sich um RSA-Zertifikate. Ebenso kannst Du OpenVPN aber mit ECC-Zertifikaten betreiben.
Kritisieren kann man, dass 256 Bit für ECC ausreichend, aber schon nicht mehr zeitgemäß ist, und die Wahl für ein "modernes" VPN eher pragmatisch erscheint, vergleichbar mit 2048 Bit RSA- oder 128 Bit AES-Schlüssellängen.
Grüße
Richard
Hallo,
ChaCha20 AVX2 implementation had a bug related to carries. On occasion the tail of the cipher text
would be incorrect. The bug appeared to be relatively rare when the CPU had AVX2, and it did not
appear in other implementations like SSE or NEON. The bug was fixed in Crypto++ 8.6. Also see
Issue 1069 and Commit 20962baf4440 Zitat (Auszug)
Alles in allem ist es eben einfach so das man eine Block und einen Stream Technik auch nicht
einfach so miteinander vergleichen kann. Beide haben Ihre Vor- und Nachteile.
AES-256 GCM wird durch AES-NI Hardware seitig unterstützt und kann auch bei dem Einsatz von
Intel QAT auf beiden Seiten des VPN richtig den Durchsatz steigern.
ChaCha20Poly1035 wird/ kann durch AVX in den CPUs unterstützt und demnächst auch durch den
Intel QAT Treiber 2.0, da ist dann schon mal auf beiden Seiten eine Hardware seitige Unterstützung
die man dann eben auch besser miteinander vergleichen kann.
Bei den ARM basierenden Geräten ist eine andere Hardware vorhanden und dort wir das ganze dann
eben mittels ASIMD oder NEON unterstützt und von daher ist der ChaChaPoly dort dann meist auch
etwas schneller als AES-GCM.
Hier mal eine Seite mit Benchmarks dazu
Dobby
Cryptopp
WireGuard wird als sichere (oder sogar derzeit sicherste) VPN-Technik bezeichnet.
ChaChaPoly verschlüsselt halt jedes Bit im Stream und AES256-GCM ganze Blöcke.ChaCha20 AVX2 implementation had a bug related to carries. On occasion the tail of the cipher text
would be incorrect. The bug appeared to be relatively rare when the CPU had AVX2, and it did not
appear in other implementations like SSE or NEON. The bug was fixed in Crypto++ 8.6. Also see
Issue 1069 and Commit 20962baf4440 Zitat (Auszug)
Alles in allem ist es eben einfach so das man eine Block und einen Stream Technik auch nicht
einfach so miteinander vergleichen kann. Beide haben Ihre Vor- und Nachteile.
AES-256 GCM wird durch AES-NI Hardware seitig unterstützt und kann auch bei dem Einsatz von
Intel QAT auf beiden Seiten des VPN richtig den Durchsatz steigern.
ChaCha20Poly1035 wird/ kann durch AVX in den CPUs unterstützt und demnächst auch durch den
Intel QAT Treiber 2.0, da ist dann schon mal auf beiden Seiten eine Hardware seitige Unterstützung
die man dann eben auch besser miteinander vergleichen kann.
Bei den ARM basierenden Geräten ist eine andere Hardware vorhanden und dort wir das ganze dann
eben mittels ASIMD oder NEON unterstützt und von daher ist der ChaChaPoly dort dann meist auch
etwas schneller als AES-GCM.
Hier mal eine Seite mit Benchmarks dazu
Dobby
- Quellenhinweise
Cryptopp