i2p.www/www.i2p2/pages/how_cryptography_de.html

{% extends "_layout_de.html" %}
{% block title %}Wie die Kryptography in I2P funktioniert{% endblock %}
{% block content %}
<p>Die Webseite wird gerade &uuml;berholt und dieses Dokument kann alte Informationen enthalten</p>
<p>
Es existieren einige kryptographische Algorythmen in I2P, wir haben diese aber
zu einem absolutem Minimum reduziert um unsere n&ouml;tige Anforderungen zu
erf&uuml;llen - einen symmetrischen Algorhythmus, einen asymmetrischen, einen
Algorythmus zum Signieren und einen Hashalgorhythmus. Diese kombinieren wir in
verschiedenen Arten und Weisen um eine Integrit&auml;t der Nachrichten zu 
erhalten (und somit nicht von einem MAC abzuh&auml;ngen). Und trotz dessen,
das wir es hassen, etwas Neues in Sachen Kryptographie zu machen, konnten wir
Referenz auf eine Diskussion (oder Bezeichnung) der Technik finden, die wir in
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> benutzen (aber wir sind 
sicher, das andere diese Technik auch implementiert haben).
<p>
<H2>ElGamal Verschl&uuml;sselung</H2>

<p>
Wir benutzen &uuml;bliche Primzahlen f&uuml;r die ElGamal Verschl&uuml;sselung 
und Entschl&uuml;sselung. Wir benutzen die ElGamal Verschl&uuml;sselung zur 
Zeit nur zum verschl&uuml;sseln des IV und des Session Keys in einem einzelnem
Block, gefolgt von der AES Verschl&uuml;sselung, die die Nutzdaten mit diesem 
Session Schl&uuml;ssel und IV verschl&uuml;sselt. Spezifiziert ist der 
nicht verschl&uuml;sselte ElGamal Block wie folgend formatiert (in Netzwerk Byte
Order): 
<p>
<p>
<PRE>
 |_________1_________2_________3_________4_________5_________6_________7_________8
 |nichtnull|H(Daten)
 |
 |
 |
 |          | Daten     ...  |

</PRE>
<p>
Die H(Daten) ist der SHA256 Wert der Daten, die in dem ElGamal Block 
verschl&uuml;sselt sind. Vor den H(Daten) steht ein zuf&auml;lliges Byte, das 
nicht Null ist. Die Daten im Block k&ouml;nnen bis zu 222 Bytes lang sein.
Die Spezifikation ist 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/ElGamalEngine.html">[im Quelltext]</a>.
<p>
ElGamal wird in I2P nie alleine genutzt, es ist immer ein Teil von 
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a>.
<p>
Die geteilt benutzte Primzahlfunktion ist die 

<a href="http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-ipsec-ike-modp-groups-05.txt">[Oakley Primzahlfunktion f&uuml;r 2048bit keys]</a>
<PRE>
 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
</PRE>
<p>
Es wird die 2 als Generator benutzt.
<p>
<H2>AES</H2>

<p>
Wir benutzen 256bit AES im CBC Modus mit dem PKCS#5 Padding f&uuml;r 16 Byte Blocks
(welches bedeuted, das jeder Block mit der Anzahl der aufgef&uuml;llten Bytes
als Daten aufgef&uuml;llt wird). 
Zur Spezifikation schaue in den 
 <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/CryptixAESEngine.html">[CBC Quelltext]</a> 
und f&uuml;r die Crytix AES 

<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/CryptixRijndael_Algorithm.html">[Implementation hier]</a>
<p>
In Situationen, in denen wir AES Daten streamen, nutzen wir die selben Algorhytmen, wie sie in 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/AESOutputStream.html">[AESOutputStream]</a> und
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/AESInputStream.html">[AESInputStream]</a>
implementiert sind.
<p>
F&uuml;r Situationen, in denen die Gr&ouml;se der zu sendenden Daten bekannt ist, 
verschl&uuml;sseln wir folgendes mit AES:
<p>
<PRE>
 |________1________2________3________4________5________6________7________8
 |H(Daten)| Gr&ouml;sse der Daten (in Bytes)  |  Daten     ...  | Zufall |
</PRE>
<p>
Nach den Daten folgt eine Applikationsabh&auml;ngige Anzahl von zuf&auml;llig 
erstellten Auff&uuml;lldaten. Und dieses gesamte Segment (von H(Daten) bis zum 
Ende der zuf&auml;lligen Daten ist AES verschl&uuml;sselt (256bit CBC mit PKCS#5). 

<p>
Dieser Code ist in den safeEncrypt und safeDecrypt Methoden der  
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/AESEngine.html">[AESEngine]</a>
implementiert.
<p>
<H2>DSA</H2>

<p>
Signaturen werden mit 1024bit DSA erzeugt und verifiziert, wie es in der
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/DSAEngine.html">[DSAEngine]</a> 
implementiert ist.
<p>
<H3>Die DSA Konstanten</H3>

<p>

<H4>SEED</H4>

<PRE>
 86108236b8526e296e923a4015b4282845b572cc
</PRE>
<H4>Z&auml;hler</H4>

<PRE>
 33
</PRE>
<p>
<H4>DSA Primzahl</H4>

<p>
<PRE>
 9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0
 A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23
 7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F
 F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C
 E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3
 B6051F5B 22CC1C93
</PRE>
<p>
<H4>DSA Quotient</H4>

<p>
<PRE>
 A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
</PRE>
<p>
<H4>DSA Generator</H4>

<p>
<PRE>
 C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236
 FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23
 C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE
 985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB
 5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3
 E93BE470 8CBCC82
</PRE>
<p>
<H2>SHA256</H2>

<p>
Hashes in I2P sind bekannte, alte SHA256 wie es im
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/crypto/SHA256Generator.html">[SHA256Generator]</a>
implementiert ist.
<p>
<H2>TCP Verbindungen</H2>

<p>
TCP Verbindungen werden zur Zeit (?) mit einer 2048 Diffie-Hellmann Implementation
ausgehandelt, die die Router Identity nutzt, gefolgt von einem Station zu Station
Agreement. Darauf folgen einige verschl&uuml;sselte protokollspezifische Felder 
und anschliessend alle AES versch&uuml;sselten Daten (wie oben beschrieben). 
In Zukunft wollen wir Session Tags, wie wir es bei den 
<a href="how_elgamalaes">ElGamalAES+SessionTag</a> machen, nutzen, um die 2048bit
DH Aushandlungen zu vermeiden. 
<p>
Wir w&uuml;rden gerne eine besser standardisierte Implementation (TLS/SSL oder gar SSH) 
nutzen, aber:
<p>
<OL>
<li> k&ouml;nnen wir irgendwie Sessions sicher wiederherstellen (wie bei den Session Tags) oder m&uuml;ssen
wir jedesmal eine volle Aushandlungsphase machen?
<li> k&ouml;nnen wir die x509 oder andere Zertifikate vereinfachen/umgehen und unsere eigene
RouterInfo Struktur nutzen (die die ElGamal und DSA Schl&uuml;ssel enth&auml;lt)?

</OL>
<p>
Die grundlegenden TCP Verbindungsalgorhythmen sind in der establishConnection() Funktion
implementiert (die wiederrum exchangeKey() und identifyStationToStation()) in 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/tcp/TCPConnection.html">[TCPConnection]</a>
aufruft).
<p>
Dieses wird erweitert durch die 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/tcp/RestrictiveTCPConnection.html">[RestrictiveTCPConnection]</a>
Funktion, die die establishConnection() Methode aktualisiert um die
Protokoll Version, die Uhrzeit und die &ouml;ffentlich erreichbare IP
Adresse des Knotens verifizieren zu k&ouml;nnen. (Da wir noch keine 
beschr&auml;nkten Router unterst&uuml;tzen, verweigern wir die Kommunikation 
zu den Routern, die von anderen Routern auch nicht angesprochen werden 
k&ouml;nnen).  {% endblock %}