Die Webseite wird gerade überholt und dieses Dokument kann alte Informationen enthalten
Es existieren einige kryptographische Algorythmen in I2P, wir haben diese aber zu einem absolutem Minimum reduziert um unsere nötige Anforderungen zu erfüllen - einen symmetrischen Algorhythmus, einen asymmetrischen, einen Algorythmus zum Signieren und einen Hashalgorhythmus. Diese kombinieren wir in verschiedenen Arten und Weisen um eine Integrität der Nachrichten zu erhalten (und somit nicht von einem MAC abzuhä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 ElGamal/AES+SessionTag benutzen (aber wir sind sicher, das andere diese Technik auch implementiert haben).
Wir benutzen übliche Primzahlen für die ElGamal Verschlüsselung und Entschlüsselung. Wir benutzen die ElGamal Verschlüsselung zur Zeit nur zum verschlüsseln des IV und des Session Keys in einem einzelnem Block, gefolgt von der AES Verschlüsselung, die die Nutzdaten mit diesem Session Schlüssel und IV verschlüsselt. Spezifiziert ist der nicht verschlüsselte ElGamal Block wie folgend formatiert (in Netzwerk Byte Order):
|_________1_________2_________3_________4_________5_________6_________7_________8 |nichtnull|H(Daten) | | | | | Daten ... |
Die H(Daten) ist der SHA256 Wert der Daten, die in dem ElGamal Block verschlüsselt sind. Vor den H(Daten) steht ein zufälliges Byte, das nicht Null ist. Die Daten im Block können bis zu 222 Bytes lang sein. Die Spezifikation ist [im Quelltext].
ElGamal wird in I2P nie alleine genutzt, es ist immer ein Teil von ElGamal/AES+SessionTag.
Die geteilt benutzte Primzahlfunktion ist die [Oakley Primzahlfunktion für 2048bit keys]
2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
Es wird die 2 als Generator benutzt.
Wir benutzen 256bit AES im CBC Modus mit dem PKCS#5 Padding für 16 Byte Blocks (welches bedeuted, das jeder Block mit der Anzahl der aufgefüllten Bytes als Daten aufgefüllt wird). Zur Spezifikation schaue in den [CBC Quelltext] und für die Crytix AES [Implementation hier]
In Situationen, in denen wir AES Daten streamen, nutzen wir die selben Algorhytmen, wie sie in [AESOutputStream] und [AESInputStream] implementiert sind.
Für Situationen, in denen die Gröse der zu sendenden Daten bekannt ist, verschlüsseln wir folgendes mit AES:
|________1________2________3________4________5________6________7________8 |H(Daten)| Grösse der Daten (in Bytes) | Daten ... | Zufall |
Nach den Daten folgt eine Applikationsabhängige Anzahl von zufällig erstellten Auffülldaten. Und dieses gesamte Segment (von H(Daten) bis zum Ende der zufälligen Daten ist AES verschlüsselt (256bit CBC mit PKCS#5).
Dieser Code ist in den safeEncrypt und safeDecrypt Methoden der [AESEngine] implementiert.
Signaturen werden mit 1024bit DSA erzeugt und verifiziert, wie es in der [DSAEngine] implementiert ist.
86108236b8526e296e923a4015b4282845b572cc
33
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
A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
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
Hashes in I2P sind bekannte, alte SHA256 wie es im [SHA256Generator] implementiert ist.
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üsselte protokollspezifische Felder und anschliessend alle AES verschüsselten Daten (wie oben beschrieben). In Zukunft wollen wir Session Tags, wie wir es bei den ElGamalAES+SessionTag machen, nutzen, um die 2048bit DH Aushandlungen zu vermeiden.
Wir würden gerne eine besser standardisierte Implementation (TLS/SSL oder gar SSH) nutzen, aber:
Die grundlegenden TCP Verbindungsalgorhythmen sind in der establishConnection() Funktion implementiert (die wiederrum exchangeKey() und identifyStationToStation()) in [TCPConnection] aufruft).
Dieses wird erweitert durch die [RestrictiveTCPConnection] Funktion, die die establishConnection() Methode aktualisiert um die Protokoll Version, die Uhrzeit und die öffentlich erreichbare IP Adresse des Knotens verifizieren zu können. (Da wir noch keine beschränkten Router unterstützen, verweigern wir die Kommunikation zu den Routern, die von anderen Routern auch nicht angesprochen werden können). {% endblock %}