i2p: update leaseset encryption types #35696

jpk68 commented at 12:08 AM on July 10, 2026: none

Updates the I2P SAM leaseset parameters to 6,4 (MLKEM-768/ECIES-X25519), as is now recommended by the I2P project. ElGamal leasesets are now considered "legacy" and likely should not be used anymore.

i2p: update leaseset encryption types 412540e18d

DrahtBot commented at 12:08 AM on July 10, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35696.

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	kevkevinpal
Concept ACK	jonatack
Approach NACK	janb84

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

sedited requested review from vasild on Jul 10, 2026

fanquake added the label Needs Backport (31.x) on Jul 10, 2026

kevkevinpal commented at 1:48 PM on July 12, 2026: contributor

ACK 412540e

I validated that this is the correct change. We could also just use 4 but I think it makes sense to use both 6,4

We might want to add a release note similar to how we did here https://github.com/bitcoin/bitcoin/pull/29440/changes#diff-e04cb1e9f29f76897c6b84334238f621ff45ba13cf180ad1d0d442d50ebe51f7R57-R60

Without the release note, breakages on old routes look like unexplained I2P breakages.

in src/i2p.cpp:428 in 412540e18d

 424 | @@ -425,7 +425,7 @@ void Session::CreateIfNotCreatedAlready()
 425 |          const Reply& reply = SendRequestAndGetReply(
 426 |              *sock,
 427 |              strprintf("SESSION CREATE STYLE=STREAM ID=%s DESTINATION=TRANSIENT SIGNATURE_TYPE=7 "
 428 | -                      "i2cp.leaseSetEncType=4,0 inbound.quantity=1 outbound.quantity=1",
 429 | +                      "i2cp.leaseSetEncType=6,4 inbound.quantity=1 outbound.quantity=1",

janb84 commented at 2:12 PM on July 13, 2026:

                      "i2cp.leaseSetEncType=6,4,0 inbound.quantity=1 outbound.quantity=1",

jonatack commented at 9:15 PM on July 22, 2026:

<strike>IIUC, this change should be fine in any case, as transient sessions are enabled only when -i2pacceptincoming is set to false, rather than the default of true. If an upgraded node running 6,4 initiates an outbound connection to a pre-#29200 peer, it fetches the legacy node's Type 0 LeaseSet. The upgraded node's local router, whether i2pd or the Java I2P one, still retains outbound ElGamal for backwards compatibility and the connection succeeds over Type 0 ElGamal.</strike>

Edit, correcting myself, I2P connection negotiation requires a mutually supported encryption type between both endpoints' local SAM sessions for the two tunnels. The comment #35696 (review) stands here as well.

in src/i2p.cpp:446 in 412540e18d

 442 | @@ -443,7 +443,7 @@ void Session::CreateIfNotCreatedAlready()
 443 |  
 444 |          SendRequestAndGetReply(*sock,
 445 |                                 strprintf("SESSION CREATE STYLE=STREAM ID=%s DESTINATION=%s "
 446 | -                                         "i2cp.leaseSetEncType=4,0 inbound.quantity=3 outbound.quantity=3",
 447 | +                                         "i2cp.leaseSetEncType=6,4 inbound.quantity=3 outbound.quantity=3",

janb84 commented at 2:12 PM on July 13, 2026:

                                         "i2cp.leaseSetEncType=6,4,0 inbound.quantity=3 outbound.quantity=3",

jonatack commented at 9:23 PM on July 22, 2026:

An argument could be made for setting 6,4,0 for the edge case of a pre-#29200 node attempting to make an I2P connection to a peer running this change, as the pre-#29200 node's SAM session only has a Type 0 ElGamal active and the connection with 6,4 will fail. I would guess there are a few dozen to maybe a couple of hundred such legacy I2P nodes.

If we do 6,4,0 instead, the 0 could be dropped when the i2pd and java i2p routers completely remove backward compatibility support for ElGamal (type 0), which they still drop down to today for pre-#29200 nodes.

janb84 commented at 2:15 PM on July 13, 2026: contributor

Why not create a setting for maximum compatibility ? or is ElGamal compromised ?

Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

jpk68 commented at 2:44 PM on July 13, 2026: none

Why not create a setting for maximum compatibility ? or is ElGamal compromised ?

Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

janb84 commented at 7:18 AM on July 14, 2026: contributor

Approach NACK, breaking backward compatibility on "likely should not be used anymore" isn't strong enough for me to justify it. ElGamal is not removed yet and there is no removal date picked (yet).

I think this PR is to early or should be restructured to explain why breaking backwards compatibility is justified. (or find a way to keep backwards compat.)

eyedeekay commented at 6:56 PM on July 14, 2026: none

Hi, I'd just like to offer some informal clarification here. ElGamal in I2P is supported for now, and we don't know about any concrete vulnerabilities in the way we use it. However, there are good reasons to not use it:

It violates the "Don't roll your own crypto" rule. ElGamal in I2P comes from a time when things were more custom and less standardized on peer reviewed crypto.
It is not implemented by every router. New implementations of I2P have elected not to support ElGamal.
Java I2P and i2pd have elected to not support ElGamal alongside post-quantum support.

In essence, that means that as PQ gets rolled out in I2P, ElGamal will degrade in usability, and the valuable properties will be provided by the other crypto types. What this would look like is that you would be able to build ElGamal tunnels because the I2P and i2pd routers would still support it, but you would not be able to simultaneously use it to talk to ML-KEM enabled tunnels. If you're using old ElGamal crypto, consider migrating off of it by changing crypto types from 0, to 4,0, then to 4, then 6,4.

eyedeekay commented at 8:05 PM on July 14, 2026: none

Also, if there is a true need for backward-compatibility, then one option would be to create a separate, ElGamal-only tunnel for legacy support. That way, you could also toggle whether the legacy tunnel is enabled at all. I'm not convinced this would be truly necessary, but it would satisfy a backward compatibility requirement. If it is decided that backward compatibility with ElGamal is truly required, then I would recommend that be done in a separate PR.

nebula-21 commented at 4:35 PM on July 22, 2026: contributor

Why not create a setting for maximum compatibility ? or is ElGamal compromised ? Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

Could you link where this was discussed or stated?

I found no documented limit for leaseSetEncType. The doc page states "Multiple encryption types are allowed". And i2pd docs show the example as i2cp.leaseSetEncType = <comma-separated codes> without specifying any limits.

If I'm not wrong, then @janb84's suggestion lgtm.

jonatack commented at 9:37 PM on July 22, 2026: member

Concept ACK 412540e18d877c4a34cf9c8fb43dfd34a603d5f5 modulo #35696 (review); it may be better to set 6,4,0 instead, and the 0 could be dropped later when the i2pd and java i2p routers completely remove backward compatibility support for ElGamal (type 0), which they still can drop down to today for pre-#29200 nodes.

If you're using old ElGamal crypto, consider migrating off of it by changing crypto types from 0, to 4,0, then to 4, then 6,4.

Alternatively, we could wait on this change until i2pd and java i2p drop ElGamal fully and then we upgrade at that time from 4,0 to 6,4.

DrahtBot requested review from janb84 on Jul 22, 2026

jonatack commented at 10:01 PM on July 22, 2026: member

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

I'm not sure. Are you talking about leaseSetType instead of leaseSetEncType?

i2pd seems to have a 6,4,0 setting in its config file: https://github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Config.cpp#L140

fanquake referenced this in commit 51143291a6 on Jul 23, 2026

jpk68 commented at 5:18 PM on July 23, 2026: none

Could you link where this was discussed or stated?

I found no documented limit for leaseSetEncType. The doc page states "Multiple encryption types are allowed". And i2pd docs show the example as i2cp.leaseSetEncType = <comma-separated codes> without specifying any limits.

If I'm not wrong, then @janb84's suggestion lgtm.

This was discussed in a DM with @eyedeekay. Upon looking further, it seems that i2pd does indeed support more than two encryption types at once, however, Java I2P does not. You can see this for yourself by attempting to create a session with such parameters through telnet:

SESSION STATUS RESULT=I2P_ERROR MESSAGE="Error creating I2PSocketManager: [SAM TCP Client(CLOSED)]: Failed to build tunnels - Disconnected from router while waiting for tunnels: bad session configuration parameters"

Alternatively, we could wait on this change until i2pd and java i2p drop ElGamal fully and > then we upgrade at that time from 4,0 to 6,4.

I think you'll be waiting quite some time for this to happen. In my opinion, it would be prudent to upgrade to PQ leasesets sooner rather than later, with the "compromise" of breaking compatibility with older routers using potentially insecure encryption types.

jonatack commented at 6:39 PM on July 23, 2026: member

In my opinion, it would be prudent to upgrade to PQ leasesets sooner rather than later, with the "compromise" of breaking compatibility

one option would be to create a separate, ElGamal-only tunnel for legacy support

I think not breaking connections with pre-#29200 peers is more important at this time and an option like that should be done first before upgrading to PQ.