April 11, 2019
tini2p hi all, meeting in ~10 min.
tini2p Meeting agenda:
Proposals + status updates
Confirm next meeting time
tini2p bueno @k1nghat
looks taken care of ;)
Proposals + status updates
agh, effin markdown
tini2p Ecies updates
zzz has made another round of updates to Proposal 144 (ECIES-X25519-AEAD-Ratchet), including:
KDF 1, 2 & 3 for new session message
More fleshed out handshake protocol
Elligator2 for point obfuscation in new session message part 1
LeaseSet2 basic implementation tini2p/tini2p!4.
For full implementation, need to implement a blinding signature scheme
Which scheme to implement:
Red25519 (Ed25519-based scheme on prime-order subgroup)
Ed25519-Blinded (Ed25519-based scheme from tor)
XEdDSA-Gimli/Blake2b/Sha3/Sha512 (X25519-based scheme on prime-order Montgomery curve)
in Signal spec, hash is an unspecified, crypto-secure hashing function
Sha512 is the default in spec, Gimli is the default in libHydrogen
Have heard some concern voiced over implementing new proposals, with no backwards compat to current protocols.
I understand the want to have a router that can talk to routers on those older protocols.
Service is better on old stuff, until new stuff is widely propagated, old stuff is known to work, etc.
The main goals of this project are to implement a minimal, secure I2P router library, and promote/develop the new I2P protocols.
I've even considered splitting off tini2p into separate libraries, each using only one end-to-end crypto and one signing scheme.
However, I'm only one person, and currently the sole developer on this project.
ElGamal and DSA are being shelved soon(tm).
There are also existing router implementations that handle backwards compatibility very well, use those for talking to old stuff.
Updated Prop. 144
ok, onto the next
tini2p 3: Short-term goals
With the new end-to-end crypto & blinded signature schemes, it's necessary to take on a crypto library as a full dependency.
The high-level public APIs are great for standard use, but fall short when implementing new crypto (by design).
Adding a crypto library as a submodule dependency will grant full control over the internals, and exposing new APIs.
Great support and documentation for X25519 EC arithmetic
Internal EC functions are low-level enough to implement needed schemes
Has enough other crypto to be the sole crypto library used in tini2p
EC arithmetic done on Montgomery curve, no bi-map swapping
Blake2b and/or Sha3 would be ported from OpenSSL (if needed)
potential for upstream patches
patches are unlikely to be included (code bloat)
Support for X25519 EC arithmetic, but very limited/high-level (as intended)
X25519 maths are wrappers around ref10 and Ed25519 (faster, secure (as LibreSSL)?)
X25519 ref10 math is available, but implementing Elligator2 inverse map requires special care
All EC arithmetic done on Ed25519
Convert input(s) to Ed25519 point(s), do stuff, convert result to X25519 point
Could act as a replacement for libSodium
First-class support for X25519 arithmetic (it's the only crypto primitive for signing/encryption)
Uses Gimli for a generic hashing function
Would serve as basis for an XEdDSA-Gimli-384 signature proposal
X25519 maths are low-level enough to be useful for building ECIES-X25519
Very small code footprint
All above libraries are unlikely to adopt schemes used in I2P, which means maintaining a local fork dependency for any custom crypto.
str4d mentioned working on a potential new C crypto library based (at least in part, iirc) on dalek design.
FWIR, the new library would be low-level enough to implement new schemes, while still providing some protections to the user.
For the near-to-mid future:
Experiment w/ adding libHydrogen as a dependency, replacing uses of Blake2b with Gimli
Implement XEdDSA and ECIES primitives inside (libHydrogen, LibreSSL), and expose simple API
Write wrappers around libHydrogen API, if it's already low-level enough for XEdDSA + ECIES
Slightly hesitant to add LibreSSL as a full dependency due to library size.
LibreSSL is much smaller than OpenSSL, but much larger than libHydrogen.
If tini2p can make due with LibreSSL/OpenSSL as a system dependency, it will be much better for overall project/binary size.
That being said, if LibreSSL is a local fork, all unecessary bits can be removed with care (when such concerns become important).
Usually leave request open for aprox. 1 week, gives a chance for others to review, and to come back to it with fresh eyes for final self-review.
Outside of crypto concerns, will be working on Tunnels + NetDb, which are largely independent of crypto concerns
ugh repeating muhself
kinghat im here, i just for the most part dont know what it all means. more of a cheerleader! :P
tini2p heh, feel free to ask questions kinghat
or, can get you some pom-poms ;)
4: Meta issues
Setting up CI on GitLab.
Working on adding webhooks to the gitter, so those interested can stay updated.
Setting up IRC bouncer/server
^ listed in rough order of priority
CI should be the most simple, just haven't dedicated time to it
same with the webhooks for this gittter room
The IRC bouncer requires funds + time, and is fairly low-priority
costs are purely for hosting
kinghat check out thelounge.chat
tini2p Would like to have a presence on IRC, but other things are taking precedence. Especially since other means of public communication are available.
will do, thanks @k1nghat
kinghat i also have a VPS host my own thelounge, could probably setup an account if needed.
tini2p sure, but that doesn't really solve the problem
have had other offers for people to host my IRC bouncer. personally not comfortable with that, though i appreciate the offers
it really just comes down to paying for a VPS, and setting up a bouncer. simple, but annoying and costs funds
kinghat im in the us. i pay hetzer $2.50 a month for the VPS.
tini2p anyway, focus over the next two weeks will be implementing basic NetDb, updating ECIES implementation, and starting I2NP/Tunnels
$2.50 a month that i don't need to spend atm
kinghat sure, just letting you know its the cheapest ive found.
or just host it at home for $free50.
tini2p of course :)
anyway, spam and other bullshit have made IRC an annoying place to hang out. not in a hurry to rejoin
i'm on Irc2P, here on gitter, reddit, Wire… how many ways do people need to contact me?
5: Confirm next meeting time
Same time, two weeks? So, 2019-04-25 @ 18:00 UTC
tini2p alright, end of meeting, thanks to all for attending
which means you @k1nghat
Post tags : Dev Diaries, Kovri I2P Router, Cryptography