From a0496dbfaf25f898d331b2b070bccb2c65b4b97f Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 17 Sep 2016 15:15:43 +0000 Subject: [PATCH] proposal 111 updates --- i2p2www/spec/proposals/111-ntcp-2.rst | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/i2p2www/spec/proposals/111-ntcp-2.rst b/i2p2www/spec/proposals/111-ntcp-2.rst index c6b6ae20..0968b742 100644 --- a/i2p2www/spec/proposals/111-ntcp-2.rst +++ b/i2p2www/spec/proposals/111-ntcp-2.rst @@ -5,7 +5,7 @@ NTCP 2 :author: zzz :created: 2014-02-13 :thread: http://zzz.i2p/topics/1577 - :lastupdated: 2016-07-05 + :lastupdated: 2016-09-17 :status: Open :supercedes: 106 @@ -48,21 +48,25 @@ Design Goals so that DPI boxes and AV signatures can't easily classify them. Also ensure that the messages going to a single peer or set of peers do not have a similar pattern of bits -- Fix loss of bits in DH due to Java format (ticket #1112) +- Fix loss of bits in DH due to Java format (ticket #1112), + possibly (probably?) by switching to X25519 - Add "probing resistance" (as Tor calls it), this includes replay resistance - Maintain 2-way authenticated key exchange (2W-AKE). 1W-AKE is not sufficient for our application. +- Continue to use the variable-type, variable-length signatures (from the published + RouterIdentity signing key) for authentication. Do not rely on a separate published key. - Add options/version in handshake for future extensibility - Add resistance to malicious MitM TCP segmentation if possible - Don't add significantly to CPU required for connection setup; if possible, reduce it significantly - Replace HMAC-MD5 with something more secure (see RFC 6151), - possibly HMAC-SHA256 or Poly1305 + possibly HMAC-SHA256 or Poly1305 (see alternatives below). - Any new crypto should be readily available in libraries for use in Java (1.7), C++, and Go router implementations. - Include representatives of Java, C++, and Go router developers in the design - Minimize changes. -- Support both versions in a common set of code. +- Support both versions in a common set of code + (this may not be possible and is implementation-dependent in any case). @@ -72,9 +76,12 @@ Non-Goals - Bullet-proof DPI resistance... that would be pluggable transports, proposal #109 - A TLS-based transport... that would be proposal #104 - Don't change the symmetric stream crypto, continue to use AES-CBC-256 - (but do add flags in the handshake so we can change later) + (but do add flags in the handshake so we can change later). + However, why is using the last 16 bytes of the previous message as the IV + better than just using counter mode? To be researched. + Salsa 20 also an option (see alternatives below) - Post-Quantum (PQ) Crypto resistance - +- Deniability (there's signatures in there) Related Goals