fix missing site_url's from translation tags on software.html

i2p2www/pages/downloads/macros

@@ -2,15 +2,15 @@
 {% set i2pinstall_jar_hash     = '3ddf3afb0c06edeed4810c6d1f34d909959dd94640adf7c638781b4a3b282e9e' %}
 {% set i2psource_hash          = 'dbccada6a353b54ceb844fe8cb0912c0363375a2f57214d23fcf463c4e6d2c4f' %}
 {% set i2pupdate_hash          = '328f85ba28ff6f60480aa0dcda88654fabeabcf63b732a770354bff7f134b135' %}
-{% set i2p_android_hash        = 'b35eb467511343a8aecdf6a1f19c0459baac007c99a93e0933ce5ab70b5a7261' %}
+{% set i2p_android_hash        = 'c4604736ec45f35a1570ace124cc2a111f1c8b2d04972f340752ef4833e9953f' %}
 {% set i2p_macnative_hash      = '70447e8a352654afd940cfc6c05f094732de7ab05db7c42c173e49f37259d601' %}
 
 {% set i2p_windows_subver = '' %}
 {% set i2p_macosx_launcher_version = '0.1.8' %}
 
-{% set i2p_android_version = '0.9.47-1' %}
+{% set i2p_android_version = '0.9.47' %}
 {% set i2p_android_version_kytv = '0.9.22' %}
-{% set i2p_android_version_fdroid = '0.9.47-1' %}
+{% set i2p_android_version_fdroid = '0.9.47' %}
 
 
 {% macro package_outer(type, name, icon) -%}

i2p2www/pages/site/about/software.html

@@ -10,7 +10,7 @@ has been actively developed since 2001.{%- endtrans %}</p>
 <p>{% trans %}The applications are made available through a webUI, which listens at 
 127.0.0.1:7657, and the main page of which is called the “Router Console,” 
 where you monitor the health of your connection to the network and access 
-applications to use on the network.{%- endtrans %}</p>
+applications that to use on the network.{%- endtrans %}</p>
 <h3>{% trans %}What is included:{%- endtrans %}</h3>
 <p>{% trans %}<strong>The Set Up Wizard</strong>: When you download the 
 I2P software, a set up wizard will guide you through a few configuration steps 

i2p2www/pages/site/docs/api/samv3.html

@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
-{% block lastupdated %}2020-10{% endblock %}
+{% block lastupdated %}July 2020{% endblock %}
-{% block accuratefor %}0.9.48{% endblock %}
+{% block accuratefor %}0.9.47{% endblock %}
 {% block content %}
 <p>Specified below is a simple client protocol for interacting with I2P.
 </p>
@@ -838,8 +838,8 @@ $port is the port number of the socket server to which SAM will
 forward connection requests. It is mandatory.
 
 </p><p>
-When a connection request arrives from I2P, the SAM bridge opens a
+When a connection request arrives from I2P, the SAM bridge requests a
-socket connection to $host:$port. If it is accepted in less
+socket connection from $host:$port. If it is accepted after no more
 than 3 seconds, SAM will accept the connection from I2P, and then:
 
 </p><p>

i2p2www/spec/proposals/152-ecies-tunnels.rst

@@ -6,7 +6,7 @@ ECIES Tunnels
     :author: chisana, zzz, orignal
     :created: 2019-07-04
     :thread: http://zzz.i2p/topics/2737
-    :lastupdated: 2020-10-26
+    :lastupdated: 2020-10-09
     :status: Open
     :target: 0.9.51
 
@@ -31,9 +31,6 @@ follow this spec for creating tunnels containing ECIES hops.
 This proposal specifies changes needed for ECIES-X25519 Tunnel Building.
 For an overview of all changes required for ECIES routers, see proposal 156 [Prop156]_.
 
-This proposal maintains the same size for tunnel build records,
-as required for compatibility. Smaller build records and messages will be
-implemented later - see [Prop157]_.
 
 
 Cryptographic Primitives
@@ -346,7 +343,7 @@ Summary of changes:
 - Unencrypted record is longer because there is less encryption overhead
 
 
-The request record does not contain any ChaCha reply keys.
+The request record does not contain any explicit tunnel or reply keys.
 Those keys are derived from a KDF. See below.
 
 All fields are big-endian.
@@ -387,9 +384,6 @@ Bit 7 indicates that the hop will be an inbound gateway (IBGW).  Bit 6
 indicates that the hop will be an outbound endpoint (OBEP).  If neither bit is
 set, the hop will be an intermediate participant.  Both cannot be set at once.
 
-The request exipration is for future variable tunnel duration.
-For now, the only supported value is 600 (10 minutes).
-
 The tunnel build options is a Mapping structure as defined in [Common]_.
 This is for future use. No options are currently defined.
 If the Mapping structure is empty, this is two bytes 0x00 0x00.
@@ -592,8 +586,7 @@ Request Record Keys (ECIES)
 -----------------------------------------------------------------------
 
 These keys are explicitly included in ElGamal BuildRequestRecords.
-For ECIES BuildRequestRecords, the tunnel keys and AES reply keys are included,
+For ECIES BuildRequestRecords, these keys are derived from the DH exchange.
-but the ChaCha reply keys are derived from the DH exchange.
 See [Prop156]_ for details of the router static ECIES keys.
 
 Below is a description of how to derive the keys previously transmitted in request records.
@@ -668,9 +661,6 @@ Failing to use unique keys opens an attack vector for colluding hops to confirm
   sesk = GENERATE_PRIVATE()
   sepk = DERIVE_PUBLIC(sesk)
 
-  // MixHash(sepk)
-  h = SHA256(h || sepk);
-
   End of "e" message pattern.
 
   This is the "es" message pattern:
@@ -776,15 +766,35 @@ This design minimizes risk.
 Implementation Notes
 =====================
 
-* Older routers do not check the encryption type of the hop and will send ElGamal-encrypted
+
-  records. Some recent routers are buggy and will send various types of malformed records.
-  Implementers should detect and reject these records prior to the DH operation
-  if possible, to reduce CPU usage.
 
 
 Issues
 ======
 
+* Is an HKDF required for the keys, what's the advantage of doing that vs.
+  just including them in the build record as before?
+
+* Make KDFs be similar to those in Noise (NTCP2) and Ratchet
+
+* HKDF output no more than 64 bytes preferred
+
+* In the current Java implementation, the full router hash field in the build
+  request record at bytes 4-35 is not checked and does not appear to be necessary.
+
+* Each record is CBC encrypted with the same AES reply key and IV, as with the current design.
+  Is this a problem? Can it be fixed?
+
+* In the current Java implementation, the originator leaves one record empty
+  for itself. Thus a message of n records can only build a tunnel of n-1 hops.
+  This is necessary for inbound tunnels (where the next-to-last hop
+  can see the hash prefix for the next hop), but not for outbound tunnels.
+  However, if the build message length is different for inbound and outbound
+  tunnels, this would allow hops to determine which direction the tunnel was.
+
+* Should we define new, smaller VTBM/VTBRM I2NP messages for all-ECIES tunnels
+  now instead of waiting for the rollout?
+
 
 
 Migration