zzz.i2p

Development discussions
Proposal: ECIES-X25519-Ratchet-AEAD « Big Topics, Ideas, Proposals and Discussion « I2P Development
 
Tue, 13 Nov 2018, 11:59pm #1
zzz
Administrator
Zzz

placeholder
hope to have posted within two weeks

ref: netdb proposal
ref: ECIES proposal

Thu, 22 Nov 2018, 05:22pm #2
zzz
Administrator
Zzz

First draft posted:
http://i2p-projekt.i2p/spec/proposals/144

For now, expect the proposal to undergo frequent revisions, without notice.

We plan to have an initial discussion about it (not a formal review)
at the LS2 meeting Monday December 3, 7:30 PM UTC, IRC #ls2

Mon, 03 Dec 2018, 10:05pm #3
zzz
Administrator
Zzz

Next meeting:

7:30 PM UTC Monday December 10, IRC #ls2

New version of the proposal 2018-12-03 posted:
http://i2p-projekt.i2p/spec/proposals/144
https://geti2p.net/spec/proposals/144

Tue, 11 Feb 2020, 01:34pm #4
zzz
Administrator
Zzz

Orignal and I have completed testing of the basic operation of proposal 144, including tests with our own code at both ends, and between our two implementations.
This proves out both the implementations and the specification.

There's a lot of things in proposal 144 that we haven't implemented yet, but are required for reliable and secure operation of the protocol in various use cases and failure modes.
We deferred working on them until we got the basics working. So now it's time to start "phase 2" and make a TODO list.

All testing and meetings happen in IRC #ls2. Meetings are Mondays at 6:30 PM UTC.

The goal is to have the protocol solidified in time for the 0.9.46 release. Incompatible changes may still happen until then.

Phase 2 TODO
---------------

1) Unimplemented blocks
1: Session ID - required?
5: Options - required?
6: Message numbers - required?
7: Next key
8: Ack
9: Ack request

2) Zero static key (datagrams)

3) Key ratchet (Next key and ack)
KDF TBD

4) I2NP changes
Lookups / Verifies
Stores
Tunnel Test

5) Error recovery / starting over

6) Agree on expirations, limits, defaults

7) I2CP Options
Session options for tags
Per-message options for tags

8) Testing
multiple NS
multiple NSR
ES out-of-order, drops

9) Performance measurements and improvement

Last edited: Tue, 11 Feb 2020, 01:40pm by zzz

Fri, 14 Feb 2020, 01:52pm #5
Qubes
I2P Legend

Any chance of the reseed add-on? i2pd has a version on GitHub... https://github.com/PurpleI2P/pyseeder

Fri, 14 Feb 2020, 02:12pm #6
zzz
Administrator
Zzz

you're in the wrong thread, but I think eyedeekay was looking at the reseed plugin a while ago. Also, pyseeder is broken, see the GH issue.

Sun, 22 Mar 2020, 01:53pm #7
zab
I2P Legend

I would love to see how this fares in the testnet. (All I have is a testnet, and everything looks like a nail.) How do I enable it and is it anywhere near ready for such testing?


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Mon, 23 Mar 2020, 02:05pm #8
zzz
Administrator
Zzz

Good question. I'll work on a quick howto.

Mon, 23 Mar 2020, 03:31pm #9
zzz
Administrator
Zzz

Generic instructions, testnet or live net, using i2ptunnel GUI config:

edit: advanced flag no longer required as of latest mtn rev ECIES option is hidden behind the advanced flag. Add routerconsole.advanced=true to ~/.i2p/router.config for each router, and wait a minute for the config file to reload.

You need a ECIES client tunnel and ECIES server tunnel. These must be on different routers; in a "loopback" configuration the encryption code is bypassed. Should work with either stock 0.9.45 or trunk, but use same version for both routers, as we continue to make incompatible protocol changes.

edit: you must stop the tunnel first! If the tunnel is a shared client, all shared client tunels must be stopped
Create or stop and edit your tunnels in the Hidden Services Manager (i2ptunnel). Changing encryption options on existing tunnels will not change the b32 on existing tunnels. At the bottom of the edit page, under encryption types, select either ECIES-X25519 or both (ElG and ECIES). If you pick ECIES only, you can't use the tunnel to talk to regular (ElG) destinations.

In live net testing, a typical setup is ECIES HTTP server tunnel, and a HTTP client tunnel with both ECIES and ElG. In a testnet, use any tunnel types you want, and ECIES-only on both sides is the most straightforward.

Start the tunnels and you should be able to make connections as usual.

That's it!

Last edited: Thu, 30 Apr 2020, 03:21pm by zzz

Tue, 24 Mar 2020, 08:15pm #10
zab
I2P Legend

Tested the above in the testnet. It basically works as expected, final transfer speed is about the same but cpu usage is noticeably less.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Thu, 02 Apr 2020, 11:56am #11
zzz
Administrator
Zzz

Update:

We continue to make non-backward-compatible changes (without announcement here, or even a dev build number change) as we proceed with our implementation and testing. Testers should continue to ensure that both sides of ECIES connections are running the same mtn/git version.

Our goal is to finish these breaking changes before the 0.9.46 release, scheduled for late May, so that we can start wider testing after that release.

Mon, 06 Apr 2020, 12:32pm #12
zzz
Administrator
Zzz

Java I2P status report (ref. post 4 above)

1) blocks: 7,8,9 done. These are the important ones.
3) key ratchet: done
4) I2NP: all done
5) start over: done, needs testing
6) defaults: progress, not done yet
8) testing: continuing

It's pretty much feature-complete now. 1) 3) and 4) were the big ones.

Edit:

Bumped to 0.9.45-6 with the above changes.
Protocol still subject to change as noted in post 11 above.

Last edited: Sat, 18 Apr 2020, 03:09pm by zzz

Tue, 07 Apr 2020, 01:54pm #13
zzz
Administrator
Zzz

ref: post 9 above, advanced flag no longer required to see the option, in latest mtn rev

Tue, 14 Apr 2020, 02:22pm #14
zzz
Administrator
Zzz

Ratchet improvements and bugfixes continue. The "muxed" configuration in particular (both ElGamal and Ratchet on a single dest) has a number of performance improvements and bug fixes.

0.9.45-9 has these changes. Unrelated streaming changes in -9 (see posts in the mtn subforum) may make everything go faster as well.

Protocol still subject to change as noted in post 11 above.

Sat, 18 Apr 2020, 03:20pm #15
zzz
Administrator
Zzz

Dual ratchet/ElG requires LS2 (0.9.38, ex-0.9.43 which has bugs, 38-42 hopefully work?)
Ratchet only requires 0.9.46

Tentative transition plan:

0.9.46 min version for ff support (prop 154)
0.9.46 option unhidden in i2ptunnel
0.9.47 enable dual-keys for i2psnark
0.9.47 enable dual-keys for http client tunnel
0.9.48 enable dual-keys for http server tunnel

Sat, 18 Apr 2020, 05:56pm #16
zab
I2P Legend

I guess I might as well enable dual keys for MuWire with 0.9.46 to help with testing. How do I do that from I2CP? Is there documentation anywhere?


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Sat, 18 Apr 2020, 07:05pm #17
zzz
Administrator
Zzz

Pass following option in properties to the socket manger factory:

i2cp.leaseSetEncType=4,0

You can verify it by finding the muwire leaseset on the leaseset debug tab of the netdb page in the console (routerconsole.advanced=true required)

Note that running with dual keys when most everybody else you are connecting to is ElG-only will have some (modest?) CPU cost, due to trial decryption with X5519 before ElG.

Once most everybody else is using dual keys also, it should be a modest CPU reduction over the ElG-only setup, as X25519/ratchet is faster and better.

Edit: Tested, works. But the CPU hit is much more than I expected. I'll be working on a fix.

Last edited: Sun, 19 Apr 2020, 12:30pm by zzz

Sun, 19 Apr 2020, 02:22pm #18
zzz
Administrator
Zzz

Pushed a change to adapt the trial decryption strategy based on previous traffic, will be in 0.9.45-11. Looks promising but continuing to test.

Edit: I'm not so sure it was a real CPU issue, it's almost impossible to come to solid conclusions based on testing in the real net. In any case, -11 has the improvement, maybe it helps, maybe not. Shouldn't hurt.

Last edited: Sun, 19 Apr 2020, 03:15pm by zzz

Thu, 23 Apr 2020, 04:22pm #19
zzz
Administrator
Zzz

Several fixes pushed as 0.9.45-12

Sat, 25 Apr 2020, 09:00pm #20
zzz
Administrator
Zzz

We're continuing to make great progress. As the proposal is becoming much more solid, I'm updating the estimates of savings vs. the existing ElGamal/AES encryption scheme. The highlights:

* 3x reduction in CPU overhead for the new session handshake
* 12x reduction in data overhead for the new session handshake
* 3x reduction in data overhead for existing session messages
* 10x reduction in in-memory tag storage

These are really impressive improvements, and we're looking forward to rolling them out for wider testing in the 0.9.46 release.

Last edited: Mon, 27 Apr 2020, 09:07pm by zzz

Mon, 27 Apr 2020, 08:12pm #21
zzz
Administrator
Zzz

Orignal and I have completed initial compatiblity testing of the rather complex "next key" feature. This is block type 7 in the todo list from post #4 above. (Also, FYI, it's one of the two "ratchets" in our "double ratchet" scheme taken from Signal). No protocol changes were required.

With both of our ratchets now working, transfers over 100 MB total between two peers should now work, even between Java i2p and i2pd.

We also today went through the other unimplemented blocks and declared them optional for now. And we agreed on some other parameters.

While we still reserve the right to make breaking changes before the .46 release, it's getting less likely. As usual, we encourage testers to use the same dev build version at both ends.

Thanks to our testers, please keep testing.

Last edited: Mon, 27 Apr 2020, 09:08pm by zzz

Wed, 29 Apr 2020, 02:09pm #22
YesYesYes well maybe
I2P Legend

Impressive work.

Sat, 02 May 2020, 10:58pm #23
zzz
Administrator
Zzz

stats.i2p and zzz.i2p now running LS2 dual key ElG/Ratchet. To test ratchet, Make sure you have a recent dev build. Then change your http client proxy to use both ElGamal and ECIES under 'encryption types' as documented in post #9 above.

If you're running 0.9.37 or earlier, you can't read this because you don't have LS2 support.

Sun, 03 May 2020, 11:34am #24
orignal
I2P Legend

This post is written through a ratchet connection.

Tue, 05 May 2020, 02:38pm #25
zzz
Administrator
Zzz

0.9.45-16 fixes inability to change encryption type on servers

Tue, 05 May 2020, 05:49pm #26
zzz
Administrator
Zzz

We made our final decisions yesterday on things definitely pushed out to .47 or later. These are advanced features, mostly targeted at efficient handling of one-way and datagram traffic patterns.

For .47 or later:

- Termination block
- Options block and parameter negotiation
- PN block
- zero static key
- ratchet-layer responses
- ratchet-layer throttling?
- Additional tuning of parameters / limits / timeouts
- I2CP session and per-packet tag params
- MTU proposal 155

Last edited: Fri, 29 May 2020, 02:04pm by zzz

Thu, 07 May 2020, 03:42pm #27
zzz
Administrator
Zzz

Proposal migrated to spec at http://i2p-projekt.i2p/spec/ecies

I will continue to keep both the proposal and the spec in sync.
Proposal contains additional background and discussion that's not in the spec.

17 hours ago #28
zzz
Administrator
Zzz

Updates for post-0.9.46 release, working through the list in #26 above:

I implemented the MTU increase (proposal 155) in 0.9.46-3, pushed May 30.

I implemented ratchet-layer responses in 0.9.46-4, pushed today.