I2P SAM: Unsupported encryption options

[anikey]

Hi.

When an application tries to connect to some destinations via SAM (on Java router), it can't do that, because it errors out with CANT_REACH_PEER and "Unsupported encryption options". However, that destination can be contacted with other means (HTTP proxy, I2PSnark works too).

The follwing destination does not appear to be contactable over SAM: tracker2.postman.i2p

However, SAM still works for other destinations, for example: i2p-projekt.i2p

As a consequence of this uncontactability, some software may be unable to work in i2p. More concretely, i am talking about qBittorrent, which recently gained I2P support via SAM, but it can't contact tracker2.postman.i2p to announce itself. However, this problem does not appear to be specific to qBittorrent, because it still can be reproduced when testing with netcat (manually typing SAM protocol commands).

How is it possible to fix this problem?

P.S. i2pd seems to have a similar problem, but instead of erroring out, it just waits for a long time and then times out. I have posted that problem on the i2pd subforum earlier.

Edit: I have noticed (in router console leaseset lookup) that tracker2.postman.i2p has only ECIES_X25519 encryption key, while i2p-projekt.i2p has both ECIES_X25519 and ELGAMAL_2048 encryption keys listed. Is that related to the problem? Could it be that I2P SAM cannot connect to ECIES-only destinations?

Edit2: After some more digging, i have discovered that the error probably comes from

Code: Select all

router/java/src/net/i2p/router/message/OutboundClientMessageOneShotJob.java

In this file it says that:

Code: Select all

        if (_to.getEncType() != EncType.ELGAMAL_2048) {
            // Enc type in key cert, proposal 145, unsupported
            dieFatal(MessageStatusMessage.STATUS_SEND_FAILURE_UNSUPPORTED_ENCRYPTION);
            return;
        }

So, i'm guessing that I2P java does not support non-ELGAMAL encryption? But then how can it connect through other ways (HTTP proxy, i2p snark)? And most importantly, will non-elgamal become supported in SAM? (Please note that i'm not complaining, i am just noticing things).

[anikey]

Resolved!!
Thanks for helping, this is what it came down to:

You need to add 'i2cp.leaseSetEncType=4,0' to the SAM session create options!!

See discussion on github: https://github.com/qbittorrent/qBittorrent/issues/19625

[zzz]

Yeah, what happened here is that postman used to support both old and new encryption. He got some (imho bad) advice to disable old encryption, possibly during some thrashing to deal with ongoing attacks and network instability. And he disabled it, afaik, without any advanced notice, causing lots of things to break - because:

This bumped into the SAM defaults that are for old encryption only. So all SAM clients (XD and libtorrent derivatives such as qBittorrent) had to figure out why things stopped working, they had no idea. i2pd people, especially Vort, helped them out.

Complicating things, our SAM docs never had a recommendation to specify i2cp.leaseSetEncType=4,0. And most SAM libraries out there didn't do it either. In the old days, people writing SAM applications knew a lot about I2P, but these days SAM is their way into I2P and the SAM docs need to be very clear on concepts and recommendations. Bitcoin has been a big help, in a way, as they made some bad choices, we steered them to the right ones, and fixed our docs to match.

As a result of all this, we discovered that bitcoin was not setting the option either, and so all the bitcoin nodes were on old encryption. I filed a bug with them and they rapidly added the option, and I went through the SAM docs and fixed them up.

So it was quite a mess but some good things came out of it.