I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Merge branch 'master' of i2pgit.org:I2P_Developers/i2p.www
Some checks failed
Sync Primary Repository to GitHub Mirror / sync (push) Has been cancelled
Details

Browse Source
This commit is contained in:
eyedeekay
2025-06-12 12:18:30 -04:00
parent de5aba25b8 422ec5aa3a
commit 287e7149de
18 changed files with 932 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
i2p2www/pages/downloads/debian.html
View File

@ -12,7 +12,7 @@
<li><a href="#debian">Knoppix</a></li>
</ul>
{% trans gtitlab='https://i2pgit.org/i2p-hackers/i2p.i2p/' -%}
{% trans gtitlab='https://i2pgit.org/I2P_Developers/i2p.i2p/' -%}
The I2P packages <em>may</em> work on systems not listed above. Please report any issues
with these packages on <a href="{{ gtitlab }}">Gitlab</a> at
<a href="{{ gtitlab }}">i2p.i2p</a>.

6
i2p2www/pages/downloads/easyinstall.html
View File

@ -20,7 +20,7 @@ Please verify that the hashes match the downloads when installing the bundle.
<h2>{{ _('What do I need to use it?') }}</h2>
<p><strong>{% trans -%}
Just Firefox (Or Tor Browser).{%- endtrans %}</strong>
{% trans issueurl="https://i2pgit.org/i2p-hackers/i2p.firefox/-/issues/2" -%}
{% trans issueurl="https://i2pgit.org/I2P_Developers/i2p.firefox/-/issues/2" -%}
This installer still requires Firefox to be installed on the system, it does not
bundle a Firefox installer of its own. Please obtain Firefox from Mozilla, or
Tor Browser from the Tor Project or one of their mirrors. If you would like to
@ -110,7 +110,7 @@ If you would like to examine the source code for individual components, you may
find it on i2pgit.org or github.com. The license for each respective component
can be found in the license directory of the <code>i2p.firefox</code> project.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://github.com/i2p/i2p.firefox">{% trans -%}Github Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/idk/i2p.plugins.firefox">{% trans -%}Gitlab Repository for Profile Manager{%- endtrans %}</a></div>
<div><a href="https://github.com/eyedeekay/i2p.plugins.firefox">{% trans -%}Github Repository Profile Manager{%- endtrans %}</a></div>
@ -120,7 +120,7 @@ contact us. For security-sensitive issues, please remember to check the
"This issue is confidential and should only be visible to team members with at least Reporter access"
option when filing the issue.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<h2>{{ _('How is it different from Tor Browser?') }}</h2>
<p>{% trans -%}
This is not a fork of Firefox. Instead, it is a browser profile with pre-configured

4
i2p2www/pages/downloads/firefox.html
View File

@ -87,7 +87,7 @@ If you would like to examine the source code for individual components, you may
find it on i2pgit.org or github.com. The license for each respective component
can be found in the license directory of the <code>i2p.firefox</code> project.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p.firefox">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://github.com/i2p/i2p.firefox">{% trans -%}Github Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/idk/i2p.plugins.firefox">{% trans -%}Gitlab Repository for Profile Manager{%- endtrans %}</a></div>
<div><a href="https://github.com/eyedeekay/i2p.plugins.firefox">{% trans -%}Github Repository Profile Manager{%- endtrans %}</a></div>
@ -97,7 +97,7 @@ contact us. For security-sensitive issues, please remember to check the
"This issue is confidential and should only be visible to team members with at least Reporter access"
option when filing the issue.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p.firefox/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<h2>{{ _('How is it different from Tor Browser?') }}</h2>
<p>{% trans -%}
This is not a fork of Firefox. Instead, it is a browser profile with pre-configured

4
i2p2www/pages/downloads/mac.html
View File

@ -113,13 +113,13 @@ I2P to launch when your user logs in by right-clicking on the I2P Dock icon.
If you would like to examine the source code for individual components, you may
find it on i2pgit.org.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p-jpackage-mac">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p-jpackage-mac">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div>{% trans -%}
If you wish to file an issue about the DMG Bundle, please use Gitlab to
contact us. For security-sensitive issues, please remember to check the
"This issue is confidential and should only be visible to team members with at
least Reporter access" option when filing the issue.
{%- endtrans %}</div>
<div><a href="https://i2pgit.org/i2p-hackers/i2p-jpackage-mac/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
<div><a href="https://i2pgit.org/I2P_Developers/i2p-jpackage-mac/issues">{% trans -%}Gitlab Repository{%- endtrans %}</a></div>
{% endblock %}

2
i2p2www/pages/site/comparison/index.html
View File

@ -30,7 +30,7 @@ The following are discussed on the <a href="{{ othernetworks }}">other networks
<li>Haystack</li>
</ul>
<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
You may contribute an analysis by entering a <a href="{{ trac }}">new issue on Github</a>.
{%- endtrans %}</p>

6
i2p2www/pages/site/comparison/other-networks.html
View File

@ -14,7 +14,7 @@ The following networks are discussed on this page.
<li>Haystack</li>
</ul>
<p>{% trans comparison=site_url('comparison'), trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans comparison=site_url('comparison'), trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
Most of the following sections are fairly old, and may not be accurate.
For an overview of available comparisons, see the
<a href="{{ comparison }}">main network comparisons page</a>.
@ -246,13 +246,13 @@ I2P is, of course, open source. However, that source, and our
{%- endtrans %}</p>
<h2>{{ _('Paid VPN Services') }}</h2>
<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
You may contribute an analysis by entering a
<a href="{{ trac }}">new issue on Github</a>.
{%- endtrans %}</p>
<h2>{{ _('Others') }}</h2>
<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
You may contribute an analysis by entering a
<a href="{{ trac }}">new issue on Github</a>.
{%- endtrans %}</p>

2
i2p2www/pages/site/docs/applications/git-bundle.html
View File

@ -24,7 +24,7 @@
<pre><code>git fetch $HOME/.i2p/i2psnark/i2p.i2p.bundle</code></pre>
<h3 id="replace-the-bundle-remote-with-the-upstream-remote">{% trans -%}Replace the bundle remote with the upstream remote{%- endtrans %}</h3>
<p>{% trans -%} Now that you have a bundle, you can keep up with changes by setting the remote to the upstream repository source. {%- endtrans %}</p>
<pre><code>git remote set-url origin git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre>
<pre><code>git remote set-url origin git@127.0.0.1:I2P_Developers/i2p.i2p</code></pre>
<h2 id="generating-a-bundle">{% trans -%}Generating a Bundle{%- endtrans %}</h2>
<p>{% trans -%} First, follow the <a href="GIT.md">Git guide for Users</a> until you have a successfully <code>--unshallow</code>ed clone of clone of the i2p.i2p repository. If you already have a clone, make sure you run <code>git fetch --unshallow</code> before you generate a torrent bundle. {%- endtrans %}</p>
<p>{% trans -%}Once you have that, simply run the corresponding ant target:{%- endtrans %}</p>

6
i2p2www/pages/site/docs/applications/git.html
View File

@ -24,7 +24,7 @@ using the instructions on the home page.{%- endtrans %}</p>
<img src="/_static/images/git/register.png" alt="" /><figcaption>Registration is easy!</figcaption>
</figure>
<h2 id="second-create-a-project-to-test-with">Second: Create a project to test with</h2>
<p>{% trans -%} To make sure the setup process works, it helps to make a repository to test with from the server, and for the sake of this tutorial, we’re going to use a fork of the I2P router. First, browse to the i2p-hackers/i2p.i2p repository: {%- endtrans %}</p>
<p>{% trans -%} To make sure the setup process works, it helps to make a repository to test with from the server, and for the sake of this tutorial, we’re going to use a fork of the I2P router. First, browse to the I2P_Developers/i2p.i2p repository: {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/explore.png" alt="" /><figcaption>Browse to i2p.i2p</figcaption>
</figure>
@ -99,7 +99,7 @@ git fetch origin</code></pre>
</ul>
<ol type="1">
<li><p>{% trans -%}Set up a second remote in your local repository using the upstream source code.{%- endtrans %}</p>
<pre><code>git remote add upstream git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre></li>
<pre><code>git remote add upstream git@127.0.0.1:I2P_Developers/i2p.i2p</code></pre></li>
<li><p>{% trans -%}Pull in any upstream changes on your current master:{%- endtrans %}</p>
<pre><code>git pull upstream master</code></pre></li>
<li><p>{% trans -%}Before making any changes to the source code, check out a new feature branch to develop on:{%- endtrans %}</p>
@ -110,7 +110,7 @@ git push origin feature-branch-name</code></pre></li>
<li><p>{% trans -%}Submit a merge request. When the merge request is approved and brought into the upstream master, check out the master locally and pull in the changes:{%- endtrans %}</p>
<pre><code>git checkout master
git pull upstream master</code></pre></li>
<li><p>{% trans -%}Whenever a change to the upstream master(i2p-hackers/i2p.i2p) is made, you can update your master code using this procedure as well.{%- endtrans %}</p>
<li><p>{% trans -%}Whenever a change to the upstream master(I2P_Developers/i2p.i2p) is made, you can update your master code using this procedure as well.{%- endtrans %}</p>
<pre><code>git checkout master
git pull upstream master</code></pre></li>
</ol>

9
i2p2www/pages/site/docs/index.html
View File

@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %}
{% block lastupdated %}2022-08{% endblock %}
{% block accuratefor %}0.9.55{% endblock %}
{% block lastupdated %}2025-06{% endblock %}
{% block accuratefor %}0.9.67{% endblock %}
{% block content %}
<p>{% trans -%}
Following is an index to the technical documentation for I2P.
@ -19,7 +19,7 @@ The specifications linked below are currently supported in the network.
See the <a href="{{ site_url('spec/proposals') }}">{{ _('Proposals') }}</a> page for
specifications in discussion or development.
<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
The I2P Project is committed to maintaining accurate, current documentation.
If you find any inaccuracies in the documents linked below, please
<a href="{{ trac }}">enter a ticket identifying the problem</a>.
@ -122,6 +122,7 @@ Traditionally used only by Java applications and higher-level APIs.
{% trans %}How client messages are end-to-end encrypted by the router.{% endtrans %}
<ul>
<li><a href="{{ spec_url('ecies') }}">{{ _('ECIES-X25519-AEAD-Ratchet encryption for destinations') }}</a></li>
<li><a href="{{ spec_url('ecies-hybrid') }}">PQ Hybrid {{ _('ECIES-X25519-AEAD-Ratchet encryption for destinations') }}</a></li>
<li><a href="{{ spec_url('ecies-routers') }}">{{ _('ECIES-X25519 encryption for routers') }}</a></li>
<li><a href="{{ site_url('docs/how/elgamal-aes') }}">{{ _('ElGamal/AES+SessionTag encryption') }}</a></li>
<li><a href="{{ site_url('docs/how/cryptography') }}">{{ _('ElGamal and AES cryptography details') }}</a></li>
@ -256,7 +257,7 @@ ancient (str4d)
</li><li>
<a href="http://{{ i2pconv('zzz.i2p') }}/">{{ _('Developer forum inside I2P') }}</a>
</li><li>
<a href="https://i2pgit.org/i2p-hackers/i2p.i2p/issues">{{ _('Bug tracker') }}</a>
<a href="https://i2pgit.org/I2P_Developers/i2p.i2p/issues">{{ _('Bug tracker') }}</a>
</li><li>
<a href="https://github.com/i2p/i2p.i2p">{{ _('I2P Source exported to GitHub') }}</a>
</li><li>

4
i2p2www/pages/site/faq.html
View File

@ -1036,8 +1036,8 @@ either through our IRC network, IRC2P, or on Freenode.{%- endtrans %}</p>
<ul>
<li>{% trans -%}Our Bugtracker:{%- endtrans %}
<ul>
<li>{% trans -%}Non-private internet:{%- endtrans %} <a href="https://i2pgit.org/i2p-hackers/i2p.i2p/issues">https://i2pgit.org/i2p-hackers/i2p.i2p/issues</a></li>
<li>{% trans -%}On I2P:{%- endtrans %} <a href="http://git.idk.i2p/i2p-hackers/i2p.i2p/issues">http://git.idk.i2p/i2p-hackers/i2p.i2p/issues</a></li>
<li>{% trans -%}Non-private internet:{%- endtrans %} <a href="https://i2pgit.org/I2P_Developers/i2p.i2p/issues">https://i2pgit.org/I2P_Developers/i2p.i2p/issues</a></li>
<li>{% trans -%}On I2P:{%- endtrans %} <a href="http://git.idk.i2p/I2P_Developers/i2p.i2p/issues">http://git.idk.i2p/I2P_Developers/i2p.i2p/issues</a></li>
</ul>
<li>{% trans -%}Our forums:{%- endtrans %} <a href="http://{{ i2pconv('i2pforum.i2p') }}/">{{ i2pconv('i2pforum.i2p') }}</a></li>
<li>{% trans -%}You may paste any interesting logs to a paste service such as the non-private internet services listed on the

2
i2p2www/pages/site/get-involved/guides/dev-guidelines.html
View File

@ -109,7 +109,7 @@ check it into a new branch on your own gitlab account, create an MR, and assign
Assign the MR to yourself. Merge the MR yourself once the reviewer approves it.
</li>
<li>
Do not create WIP branches in the main i2p-hackers account (except for i2p.www).
Do not create WIP branches in the main I2P_Developers account (except for i2p.www).
WIP belongs in your own account. When the work is done, create an MR.
The only branches in the main account should be for true forks, like a point release.
</li>

4
i2p2www/pages/site/get-involved/guides/new-developers.html
View File

@ -65,7 +65,7 @@ Install <a href="{{ git_url }}">Git</a>.
</li>
<li><strong><a href="https://i2pgit.org">{% trans %}Outside I2P - (https://i2pgit.org){% endtrans %}</a></strong>
</li>
<code>git clone https://i2pgit.org/i2p-hackers/i2p.i2p.git</code>
<code>git clone https://i2pgit.org/I2P_Developers/i2p.i2p.git</code>
</ul>
<p>The read-only mirror is also still available at github.</p>
@ -100,7 +100,7 @@ see the <a href="{{ apps }}">application development guide</a>.
{%- endtrans %}</p>
<h2 id="development-ideas">{% trans %}Development ideas{% endtrans %}</h2>
<p>{% trans todo=site_url('get-involved/todo'), trac='https://i2pgit.org/i2p-hackers/i2p.i2p/issues' -%}
<p>{% trans todo=site_url('get-involved/todo'), trac='https://i2pgit.org/I2P_Developers/i2p.i2p/issues' -%}
See <a href="{{ todo }}">the project TODO list</a> or
<a href="{{ trac }}">the issue list on GitLab</a>
for ideas.

2
i2p2www/pages/spec/index.html
View File

@ -22,7 +22,7 @@ in during the course of development. Periodic reviews are conducted to update
the "accurate for" information.
</li></ul>
<p>{% trans trac='https://i2pgit.org/i2p-hackers/i2p.www/issues' -%}
<p>{% trans trac='https://i2pgit.org/I2P_Developers/i2p.www/issues' -%}
The I2P Project is committed to maintaining accurate, current documentation.
If you find any inaccuracies in the documents linked below, please
<a href="{{ trac }}">enter a ticket identifying the problem</a>.

83
i2p2www/spec/common-structures.rst
View File

@ -3,8 +3,8 @@ Common structures Specification
===============================
.. meta::
:category: Design
:lastupdated: 2025-04
:accuratefor: 0.9.66
:lastupdated: 2025-06
:accuratefor: 0.9.67
.. contents::
@ -84,15 +84,24 @@ X25519 keys are supported in RouterIdentities as of release 0.9.48.
======= ============== ====== =====
Type Length (bytes) Since Usage
======= ============== ====== =====
ElGamal 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there; discouraged for leasesets
P256 64 TBD Reserved, see proposal 145
P384 96 TBD Reserved, see proposal 145
P521 132 TBD Reserved, see proposal 145
X25519 32 0.9.38 Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
======= ============== ====== =====
================ ================= ====== =====
Type Length (bytes) Since Usage
================ ================= ====== =====
ElGamal 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there; discouraged for leasesets
P256 64 TBD Reserved, see proposal 145
P384 96 TBD Reserved, see proposal 145
P521 132 TBD Reserved, see proposal 145
X25519 32 0.9.38 Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
MLKEM512_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM768_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM1024_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM512 800 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM768 1184 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM1024 1568 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM512_CT 768 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM768_CT 1088 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM1024_CT 1568 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
================ ================= ====== =====
JavaDoc: http://{{ i2pconv('idk.i2p/javadoc-i2p') }}/net/i2p/data/PublicKey.html
@ -116,15 +125,21 @@ The default type is ElGamal. As of release
0.9.38, other types may be supported, depending on context.
Keys are big-endian unless otherwise noted.
======= ============== ====== =====
Type Length (bytes) Since Usage
======= ============== ====== =====
ElGamal 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there; discouraged for leasesets
P256 32 TBD Reserved, see proposal 145
P384 48 TBD Reserved, see proposal 145
P521 66 TBD Reserved, see proposal 145
X25519 32 0.9.38 Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
======= ============== ====== =====
================ ================== ====== =====
Type Length (bytes) Since Usage
================ ================== ====== =====
ElGamal 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there; discouraged for leasesets
P256 32 TBD Reserved, see proposal 145
P384 48 TBD Reserved, see proposal 145
P521 66 TBD Reserved, see proposal 145
X25519 32 0.9.38 Little-endian. See [ECIES]_ and [ECIES-ROUTERS]_
MLKEM512_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM768_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM1024_X25519 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM512 1632 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM768 2400 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
MLKEM1024 3168 0.9.67 See [ECIES-HYBRID]_, for handshakes only, not for Leasesets, RIs or Destinations
================ ================== ====== =====
JavaDoc: http://{{ i2pconv('idk.i2p/javadoc-i2p') }}/net/i2p/data/PrivateKey.html
@ -445,17 +460,20 @@ reserved 65535 Reserved f
The defined Crypto Public Key types are:
======== =========== ======================= =====
Type Type Code Total Public Key Length Usage
======== =========== ======================= =====
ElGamal 0 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there
P256 1 64 Reserved, see proposal 145
P384 2 96 Reserved, see proposal 145
P521 3 132 Reserved, see proposal 145
X25519 4 32 See [ECIES]_ and proposal 156
reserved 65280-65534 Reserved for experimental use
reserved 65535 Reserved for future expansion
======== =========== ======================= =====
================ =========== ======================= ====== =====
Type Type Code Total Public Key Length Since Usage
================ =========== ======================= ====== =====
ElGamal 0 256 Deprecated for Router Identities as of 0.9.58; use for Destinations, as the public key field is unused there
P256 1 64 Reserved, see proposal 145
P384 2 96 Reserved, see proposal 145
P521 3 132 Reserved, see proposal 145
X25519 4 32 0.9.38 See [ECIES]_ and proposal 156
MLKEM512_X25519 5 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM768_X25519 6 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
MLKEM1024_X25519 7 32 0.9.67 See [ECIES-HYBRID]_, for Leasesets only, not for RIs or Destinations
reserved 65280-65534 Reserved for experimental use
reserved 65535 Reserved for future expansion
================ =========== ======================= ====== =====
When a Key Certificate is not present, the preceeding 384 bytes in the
Destination or RouterIdentity are defined as the 256-byte ElGamal PublicKey
@ -1881,6 +1899,9 @@ References
.. [ECIES]
{{ spec_url('ecies') }}
.. [ECIES-HYBRID]_
{{ spec_url('ecies-hybrid') }}
.. [ECIES-ROUTERS]
{{ spec_url('ecies-routers') }}

836
i2p2www/spec/ecies-hybrid.rst Normal file
View File

@ -0,0 +1,836 @@
===================================
PQ Hybrid ECIES-X25519-AEAD-Ratchet
===================================
.. meta::
:category: Protocols
:lastupdated: 2025-06
:accuratefor: 0.9.67
.. contents::
Note
====
Implementation, testing, and rollout in progress in the various
router implementations. Check the documentation of those implementations for status.
Overview
========
This is the PQ Hybrid variant of the ECIES-X25519-AEAD-Ratchet protocol [ECIES]_.
It is the first phase of the overall PQ proposal [Prop169]_
to be approved. See that proposal for overall goals, threat models,
analysis, alternatives, and additional information.
This specification contains only the differences from standard [ECIES]_
and must be read in conjunction with that specification.
Design
======
We use the NIST FIPS 203 standard [FIPS203]_
which is based on, but not compatible with,
CRYSTALS-Kyber (versions 3.1, 3, and older).
Hybrid handshakes are as specified in [Noise-Hybrid]_.
Key Exchange
-------------
We define a hybrid key exchange for Ratchet.
PQ KEM provides ephemeral keys only, and does not directly support
static-key handshakes such as Noise IK.
We define the three ML-KEM variants as in [FIPS203]_,
for 3 new encryption types total.
Hybrid types are only defined in combination with X25519.
The new encryption types are:
================ ====
Type Code
================ ====
MLKEM512_X25519 5
MLKEM768_X25519 6
MLKEM1024_X25519 7
================ ====
Overhead will be substantial. Typical message 1 and 2 sizes (for IK)
are currently around 100 bytes (before any additional payload).
This will increase by 8x to 15x depending on algorithm.
New Crypto Required
-------------------
- ML-KEM (formerly CRYSTALS-Kyber) [FIPS203]_
- SHA3-128 (formerly Keccak-256) [FIPS202]_ Used only for SHAKE128
- SHA3-256 (formerly Keccak-512) [FIPS202]_
- SHAKE128 and SHAKE256 (XOF extensions to SHA3-128 and SHA3-256) [FIPS202]_
Test vectors for SHA3-256, SHAKE128, and SHAKE256 are at [NIST-VECTORS]_.
Note that the Java bouncycastle library supports all the above.
C++ library support is in OpenSSL 3.5 [OPENSSL]_.
Specification
=============
Common Structures
-----------------
See the common structures specification [COMMON]_ for key lengths and identifiers.
Handshake Patterns
------------------
Handshakes use [Noise]_ handshake patterns.
The following letter mapping is used:
- e = one-time ephemeral key
- s = static key
- p = message payload
- e1 = one-time ephemeral PQ key, sent from Alice to Bob
- ekem1 = the KEM ciphertext, sent from Bob to Alice
The following modifications to XK and IK for hybrid forward secrecy (hfs) are
as specified in [Noise-Hybrid]_ section 5:
.. raw:: html
{% highlight lang='dataspec' %}
IK: IKhfs:
<- s <- s
... ...
-> e, es, s, ss, p -> e, es, e1, s, ss, p
<- tag, e, ee, se, p <- tag, e, ee, ekem1, se, p
<- p <- p
p -> p ->
e1 and ekem1 are encrypted. See pattern definitions below.
NOTE: e1 and ekem1 are different sizes (unlike X25519)
{% endhighlight %}
The e1 pattern is defined as follows, as specified in [Noise-Hybrid]_ section 4:
.. raw:: html
{% highlight lang='dataspec' %}
For Alice:
(encap_key, decap_key) = PQ_KEYGEN()
// EncryptAndHash(encap_key)
ciphertext = ENCRYPT(k, n, encap_key, ad)
n++
MixHash(ciphertext)
For Bob:
// DecryptAndHash(ciphertext)
encap_key = DECRYPT(k, n, ciphertext, ad)
n++
MixHash(ciphertext)
{% endhighlight %}
The ekem1 pattern is defined as follows, as specified in [Noise-Hybrid]_ section 4:
.. raw:: html
{% highlight lang='dataspec' %}
For Bob:
(kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)
// EncryptAndHash(kem_ciphertext)
ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
MixHash(ciphertext)
// MixKey
MixKey(kem_shared_key)
For Alice:
// DecryptAndHash(ciphertext)
kem_ciphertext = DECRYPT(k, n, ciphertext, ad)
MixHash(ciphertext)
// MixKey
kem_shared_key = DECAPS(kem_ciphertext, decap_key)
MixKey(kem_shared_key)
{% endhighlight %}
Defined ML-KEM Operations
-------------------------
We define the following functions corresponding to the cryptographic building blocks used
as defined in [FIPS203]_.
(encap_key, decap_key) = PQ_KEYGEN()
Alice creates the encapsulation and decapsulation keys
The encapsulation key is sent in the NS message.
encap_key and decap_key sizes vary based on ML-KEM variant.
(ciphertext, kem_shared_key) = ENCAPS(encap_key)
Bob calculates the ciphertext and shared key,
using the ciphertext received in the NS message.
The ciphertext is sent in the NSR message.
ciphertext size varies based on ML-KEM variant.
The kem_shared_key is always 32 bytes.
kem_shared_key = DECAPS(ciphertext, decap_key)
Alice calculates the shared key,
using the ciphertext received in the NSR message.
The kem_shared_key is always 32 bytes.
Note that both the encap_key and the ciphertext are encrypted inside ChaCha/Poly
blocks in the Noise handshake messages 1 and 2.
They will be decrypted as part of the handshake process.
The kem_shared_key is mixed into the chaining key with MixHash().
See below for details.
Noise Handshake KDF
---------------------
Overview
````````
The hybrid handshake is defined in [Noise-Hybrid]_.
The first message, from Alice to Bob, contains e1, the encapsulation key, before the message payload.
This is treated as an additional static key; call EncryptAndHash() on it (as Alice)
or DecryptAndHash() (as Bob).
Then process the message payload as usual.
The second message, from Bob to Alice, contains ekem1, the ciphertext, before the message payload.
This is treated as an additional static key; call EncryptAndHash() on it (as Bob)
or DecryptAndHash() (as Alice).
Then, calculate the kem_shared_key and call MixKey(kem_shared_key).
Then process the message payload as usual.
Noise identifiers
`````````````````
These are the Noise initialization strings:
- "Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256"
- "Noise_IKhfselg2_25519+MLKEM768_ChaChaPoly_SHA256"
- "Noise_IKhfselg2_25519+MLKEM1024_ChaChaPoly_SHA256"
Alice KDF for NS Message
`````````````````````````
After the 'es' message pattern and before the 's' message pattern, add:
.. raw:: html
{% highlight lang='text' %}
This is the "e1" message pattern:
(encap_key, decap_key) = PQ_KEYGEN()
// EncryptAndHash(encap_key)
// AEAD parameters
k = keydata[32:63]
n = 0
ad = h
ciphertext = ENCRYPT(k, n, encap_key, ad)
n++
// MixHash(ciphertext)
h = SHA256(h || ciphertext)
End of "e1" message pattern.
NOTE: For the next section (payload for XK or static key for IK),
the keydata and chain key remain the same,
and n now equals 1 (instead of 0 for non-hybrid).
{% endhighlight %}
Bob KDF for NS Message
`````````````````````````
After the 'es' message pattern and before the 's' message pattern, add:
.. raw:: html
{% highlight lang='text' %}
This is the "e1" message pattern:
// DecryptAndHash(encap_key_section)
// AEAD parameters
k = keydata[32:63]
n = 0
ad = h
encap_key = DECRYPT(k, n, encap_key_section, ad)
n++
// MixHash(encap_key_section)
h = SHA256(h || encap_key_section)
End of "e1" message pattern.
NOTE: For the next section (payload for XK or static key for IK),
the keydata and chain key remain the same,
and n now equals 1 (instead of 0 for non-hybrid).
{% endhighlight %}
Bob KDF for NSR Message
`````````````````````````
After the 'ee' message pattern and before the 'se' message pattern, add:
.. raw:: html
{% highlight lang='text' %}
This is the "ekem1" message pattern:
(kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)
// EncryptAndHash(kem_ciphertext)
// AEAD parameters
k = keydata[32:63]
n = 0
ad = h
ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
// MixHash(ciphertext)
h = SHA256(h || ciphertext)
// MixKey(kem_shared_key)
keydata = HKDF(chainKey, kem_shared_key, "", 64)
chainKey = keydata[0:31]
End of "ekem1" message pattern.
{% endhighlight %}
Alice KDF for NSR Message
`````````````````````````
After the 'ee' message pattern and before the 'ss' message pattern, add:
.. raw:: html
{% highlight lang='text' %}
This is the "ekem1" message pattern:
// DecryptAndHash(kem_ciphertext_section)
// AEAD parameters
k = keydata[32:63]
n = 0
ad = h
kem_ciphertext = DECRYPT(k, n, kem_ciphertext_section, ad)
// MixHash(kem_ciphertext_section)
h = SHA256(h || kem_ciphertext_section)
// MixKey(kem_shared_key)
kem_shared_key = DECAPS(kem_ciphertext, decap_key)
keydata = HKDF(chainKey, kem_shared_key, "", 64)
chainKey = keydata[0:31]
End of "ekem1" message pattern.
{% endhighlight %}
KDF for split()
```````````````
unchanged
Message Format
--------------
NS Format
`````````
Changes: Current ratchet contained the static key in the first ChaCha section,
and the payload in the second section.
With ML-KEM, there are now three sections.
The first section contains the encrypted PQ public key.
The second section contains the static key.
The third section contains the payload.
Encrypted format:
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| |
+ +
| New Session Ephemeral Public Key |
+ 32 bytes +
| Encoded with Elligator2 |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ ML-KEM encap_key +
| ChaCha20 encrypted data |
+ (see table below for length) +
| |
~ ~
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for encap_key Section +
| 16 bytes |
+----+----+----+----+----+----+----+----+
| |
+ X25519 Static Key +
| ChaCha20 encrypted data |
+ 32 bytes +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for Static Key Section +
| 16 bytes |
+----+----+----+----+----+----+----+----+
| |
+ Payload Section +
| ChaCha20 encrypted data |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for Payload Section +
| 16 bytes |
+----+----+----+----+----+----+----+----+
{% endhighlight %}
Decrypted format:
.. raw:: html
{% highlight lang='dataspec' %}
Payload Part 1:
+----+----+----+----+----+----+----+----+
| |
+ ML-KEM encap_key +
| |
+ (see table below for length) +
| |
~ ~
| |
+----+----+----+----+----+----+----+----+
Payload Part 2:
+----+----+----+----+----+----+----+----+
| |
+ X25519 Static Key +
| |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Payload Part 3:
+----+----+----+----+----+----+----+----+
| |
+ Payload Section +
| |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
{% endhighlight %}
Sizes:
================ ========= ===== ========= ============= ============= ========== =======
Type Type Code X len NS len NS Enc len NS Dec len PQ key len pl len
================ ========= ===== ========= ============= ============= ========== =======
X25519 4 32 96+pl 64+pl pl -- pl
MLKEM512_X25519 5 32 912+pl 880+pl 800+pl 800 pl
MLKEM768_X25519 6 32 1296+pl 1360+pl 1184+pl 1184 pl
MLKEM1024_X25519 7 32 1680+pl 1648+pl 1568+pl 1568 pl
================ ========= ===== ========= ============= ============= ========== =======
Note that the payload must contain a DateTime block, so the minimum payload size is 7.
The minimum NS sizes may be calculated accordingly.
NSR Format
``````````
Changes: Current ratchet has an empty payload for the first ChaCha section,
and the payload in the second section.
With ML-KEM, there are now three sections.
The first section contains the encrypted PQ ciphertext.
The second section has an empty payload.
The third section contains the payload.
Encrypted format:
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| Session Tag 8 bytes |
+----+----+----+----+----+----+----+----+
| |
+ Ephemeral Public Key +
| |
+ 32 bytes +
| Encoded with Elligator2 |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| ChaCha20 encrypted ML-KEM ciphertext |
+ (see table below for length) +
~ ~
+ +
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for ciphertext Section +
| 16 bytes |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for key Section (no data) +
| 16 bytes |
+----+----+----+----+----+----+----+----+
| |
+ Payload Section +
| ChaCha20 encrypted data |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) for Payload Section +
| 16 bytes |
+----+----+----+----+----+----+----+----+
{% endhighlight %}
Decrypted format:
.. raw:: html
{% highlight lang='dataspec' %}
Payload Part 1:
+----+----+----+----+----+----+----+----+
| |
+ ML-KEM ciphertext +
| |
+ (see table below for length) +
| |
~ ~
| |
+----+----+----+----+----+----+----+----+
Payload Part 2:
empty
Payload Part 3:
+----+----+----+----+----+----+----+----+
| |
+ Payload Section +
| |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
{% endhighlight %}
Sizes:
================ ========= ===== ========= ============= ============= ========== =======
Type Type Code Y len NSR len NSR Enc len NSR Dec len PQ CT len opt len
================ ========= ===== ========= ============= ============= ========== =======
X25519 4 32 72+pl 32+pl pl -- pl
MLKEM512_X25519 5 32 856+pl 816+pl 768+pl 768 pl
MLKEM768_X25519 6 32 1176+pl 1136+pl 1088+pl 1088 pl
MLKEM1024_X25519 7 32 1656+pl 1616+pl 1568+pl 1568 pl
================ ========= ===== ========= ============= ============= ========== =======
Note that while NSR will normally have a nonzero payload,
the ratchet specification [ECIES]_ does not require it, so the minimum payload size is 0.
The minimum NSR sizes may be caculated accordingly.
Overhead Analysis
=================
Key Exchange
-------------
Size increase (bytes):
================ ============== =============
Type Pubkey (NS) Cipertext (NSR)
================ ============== =============
MLKEM512_X25519 +816 +784
MLKEM768_X25519 +1200 +1104
MLKEM1024_X25519 +1584 +1584
================ ============== =============
Speed:
Speeds as reported by [CLOUDFLARE]_:
================ ==============
Type Relative speed
================ ==============
X25519 DH/keygen baseline
MLKEM512 2.25x faster
MLKEM768 1.5x faster
MLKEM1024 1x (same)
XK 4x DH (keygen + 3 DH)
MLKEM512_X25519 4x DH + 2x PQ (keygen + enc/dec) = 4.9x DH = 22% slower
MLKEM768_X25519 4x DH + 2x PQ (keygen + enc/dec) = 5.3x DH = 32% slower
MLKEM1024_X25519 4x DH + 2x PQ (keygen + enc/dec) = 6x DH = 50% slower
================ ==============
Security Analysis
=================
NIST security categories are summarized in [NIST-PQ-END]_ slide 10.
Preliminary criteria:
Our minimum NIST security category should be 2 for hybrid protocols
and 3 for PQ-only.
======== ======
Category As Secure As
======== ======
1 AES128
2 SHA256
3 AES192
4 SHA384
5 AES256
======== ======
Handshakes
----------
These are all hybrid protocols.
Probably need to prefer MLKEM768; MLKEM512 is not secure enough.
NIST security categories [FIPS203]_ :
========= ========
Algorithm Security Category
========= ========
MLKEM512 1
MLKEM768 3
MLKEM1024 5
========= ========
Type Preferences
=================
The recommended type for initial support, based on security category and key length, is:
MLKEM768_X25519 (type 6)
Implementation Notes
=====================
Library Support
---------------
Bouncycastle, BoringSSL, and WolfSSL libraries support MLKEM now.
OpenSSL support is be in their 3.5 release April 8, 2025 [OPENSSL]_.
Shared Tunnels
--------------
Auto-classify/detect of multiple protocols on the same tunnels should be possible based
on a length check of message 1 (New Session Message).
Using MLKEM512_X25519 as an example, message 1 length is 816 bytes larger
than current ratchet protocol, and the minimum message 1 size (with only a DateTime payload included)
is 919 bytes. Most message 1 sizes with current ratchet have a payload less than
816 bytes, so they can be classified as non-hybrid ratchet.
Large messages are probably POSTs which are rare.
So the recommended strategy is:
- If message 1 is less than 919 bytes, it's the current ratchet protocol.
- If message 1 is greater than or equal to 919 bytes, it's probably MLKEM512_X25519.
Try MLKEM512_X25519 first, and if it fails, try the current ratchet protocol.
This should allow us to efficiently support standard ratchet and hybrid ratchet
on the same destination, just as we previously supported ElGamal and ratchet
on the same destination. Therefore, we can migrate to the MLKEM hybrid protocol
much more quickly than if we could not support dual-protocols for the same destination,
because we can add MLKEM support to existing destinations.
The required supported combinations are:
- X25519 + MLKEM512
- X25519 + MLKEM768
- X25519 + MLKEM1024
The following combinations may be complex, and are NOT required to be supported,
but may be, implementation-dependent:
- More than one MLKEM
- ElG + one or more MLKEM
- X25519 + one or more MLKEM
- ElG + X25519 + one or more MLKEM
It is not required to support multiple MLKEM algorithms
(for example, MLKEM512_X25519 and MLKEM_768_X25519)
on the same destination. Pick just one.
Implementation-dependent.
It is not required to support three algorithms (for example X25519, MLKEM512_X25519, and MLKEM769_X25519)
on the same destination. The classification and retry strategy may be too complex.
The configuration and configuration UI may be too complex.
Implementation-dependent.
It is not required to support ElGamal and hybrid algorithms on the same destination.
ElGamal is obsolete, and ElGamal + hybrid only (no X25519) doesn't make much sense.
Also, ElGamal and Hybrid New Session Messages are both large, so
classification strategies would often have to try both decryptions,
which would be inefficient.
Implementation-dependent.
Clients may use the same or different X25519 static keys for the X25519
and the hybrid protocols on the same tunnels, implementation-dependent.
Forward Secrecy
---------------
The ECIES specification allows Garlic Messages in the New Session Message payload,
which allows for 0-RTT delivery of the initial streaming packet,
usually a HTTP GET, together with the client's leaseset.
However, the New Session Message payload does not have forward secrecy.
As this proposal is emphasizing enhanced forward secrecy for ratchet,
implementations may or should defer inclusion of the streaming payload,
or the full streaming message, until the first Existing Session Message.
This would be at the expense of 0-RTT delivery.
Strategies may also depend on traffic type or tunnel type,
or on GET vs. POST, for example.
Implementation-dependent.
New Session Size
----------------
MLKEM will dramatically increase
the size of the New Session Message, as described above.
This may significantly decrease the reliability of New Session Message
delivery through tunnels, where they must be fragmented into
multiple 1024 byte tunnel messages. Delivery success is
proportional to the exponential number of fragments.
Implementations may use various strategies to limit the size of the message,
at the expense of 0-RTT delivery.
Implementation-dependent.
References
==========
.. [CLOUDFLARE]
https://blog.cloudflare.com/pq-2024/
.. [COMMON]
{{ spec_url('common-structures') }}
.. [ECIES]
{{ spec_url('ecies') }}
.. [ECIES-HYBRID]_
{{ spec_url('ecies-hybrid') }}
.. [FORUM]
http://zzz.i2p/topics/3294
.. [FIPS202]
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
.. [FIPS203]
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
.. [NIST-PQ-END]
https://www.nccoe.nist.gov/sites/default/files/2023-08/pqc-light-at-the-end-of-the-tunnel-presentation.pdf
.. [NIST-VECTORS]
https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/example-values
.. [Noise]
https://noiseprotocol.org/noise.html
.. [Noise-Hybrid]
https://github.com/noiseprotocol/noise_hfs_spec/blob/master/output/noise_hfs.pdf
.. [OPENSSL]
https://openssl-library.org/post/2025-02-04-release-announcement-3.5/
.. [PQ-WIREGUARD]
https://eprint.iacr.org/2020/379.pdf
.. [Prop169]
{{ proposal_url('169') }}

8
i2p2www/spec/ecies.rst
View File

@ -3,8 +3,8 @@ ECIES-X25519-AEAD-Ratchet
=========================
.. meta::
:category: Protocols
:lastupdated: 2025-04
:accuratefor: 0.9.66
:lastupdated: 2025-06
:accuratefor: 0.9.67
.. contents::
@ -22,6 +22,7 @@ The following features are not implemented as of 0.9.66:
- Zero static key
- Multicast
For the MLKEM PQ Hybrid version of this protocol, see [ECIES-HYBRID]_.
Overview
@ -3251,6 +3252,9 @@ References
.. [CRYPTO-ELG]
{{ site_url('docs/how/cryptography', True) }}#elgamal
.. [ECIES-HYBRID]_
{{ spec_url('ecies-hybrid') }}
.. [Datagrams]
{{ spec_url('datagrams') }}

23
i2p2www/spec/proposals/169-pq-crypto.rst
View File

@ -5,7 +5,7 @@ Post-Quantum Crypto Protocols
:author: zzz, orignal, drzed, eyedeekay
:created: 2025-01-21
:thread: http://zzz.i2p/topics/3294
:lastupdated: 2025-04-23
:lastupdated: 2025-06-12
:status: Open
:target: 0.9.80
@ -83,14 +83,10 @@ See the Priorities and Rollout section below for details.
================================== ======
Protocol / Feature Status
================================== ======
Hybrid EncTypes 5-7 Preliminary, final hash choices pending
Hybrid Dests, Ratchet Tested on live net, no net upgrade required
Select preferred combo Probably 6,4
Combo Hybrid/X25519 Dests, Ratchet
Combo Hybrid/X25519 NTCP2
Combo Hybrid/X25519 SSU2
Hybrid Routers, Dests, Ratchet
MLDSA SigTypes 12-14 Probably final
Hybrid MLKEM Ratchet and LS Approved 2026-06; beta target 2025-08; release target 2025-11
Hybrid MLKEM NTCP2 Some details to be finalized
Hybrid MLKEM SSU2 Some details to be finalized
MLDSA SigTypes 12-14 Proposal is stable but may not be finalized until 2026
MLDSA Dests Tested on live net, requires net upgrade for floodfill support
Hybrid SigTypes 15-17 Preliminary
Hybrid Dests
@ -243,7 +239,7 @@ New Crypto Required
Test vectors for SHA3-256, SHAKE128, and SHAKE256 are at [NIST-VECTORS]_.
Note that the Java bouncycastle library supports all the above.
C++ library support will be in OpenSSL 3.5 [OPENSSL]_.
C++ library support is in OpenSSL 3.5 [OPENSSL]_.
Alternatives
@ -965,7 +961,7 @@ MLKEM1024_X25519 7 32 1680+pl 1648+pl 1568+pl
================ ========= ===== ========= ============= ============= ========== =======
Note that the payload must contain a DateTime block, so the minimum payload size is 7.
The minimum message 1 sizes may be caculated accordingly.
The minimum message 1 sizes may be calculated accordingly.
@ -1077,7 +1073,7 @@ MLKEM1024_X25519 7 32 1656+pl 1616+pl 1568+pl
Note that while message 2 will normally have a nonzero payload,
the ratchet specification [ECIES]_ does not require it, so the minimum payload size is 0.
The minimum message 2 sizes may be caculated accordingly.
The minimum message 2 sizes may be calculated accordingly.
@ -1843,8 +1839,7 @@ Library Support
---------------
Bouncycastle, BoringSSL, and WolfSSL libraries support MLKEM and MLDSA now.
OpenSSL support will be in their 3.5 release scheduled for April 8, 2025 [OPENSSL]_.
3.5-alpha will be availabe March 11, 2025.
OpenSSL support is be in their 3.5 release April 8, 2025 [OPENSSL]_.
The southernstorm.com Noise library adapted by Java I2P contained preliminary support for
hybrid handshakes, but we removed it as unused; we will have to add it back

3
i2p2www/spec/tunnel-creation-ecies.rst
View File

@ -18,7 +18,7 @@ It is a portion of the overall proposal
There are two versions specified.
The first uses the existing build messages and build record size, for compatibility with ElGamal routers.
This specification is implemented as of release 0.9.48.
This specification was implemented as of release 0.9.48 and is now deprecated.
The second uses two new build messages and a smaller build record size, and may only be used with ECIES routers.
This specification is implemented as of release 0.9.51.
@ -138,6 +138,7 @@ ECIES replies use ChaCha20/Poly1305 AEAD for integrity, and authentication.
Long Record Specification
=========================
NOTE: Deprecated, obsolete. Use the Short Record format specified below.
Build Request Records