diff --git a/_posts/2019-04-11-logs-for-the-tini2p-dev-meeting-held-on-2019-04-11.md b/_posts/2019-04-11-logs-for-the-tini2p-dev-meeting-held-on-2019-04-11.md new file mode 100644 index 00000000..c73eb699 --- /dev/null +++ b/_posts/2019-04-11-logs-for-the-tini2p-dev-meeting-held-on-2019-04-11.md @@ -0,0 +1,135 @@ +--- +layout: post +title: Overview and Logs for the tini2p Dev Meeting Held on 2019-04-11 +summary: Current project status, Roadmap, Meta issues, and miscellaneous +tags: [dev diaries, i2p, crypto] +author: el00ruobuob / oneiric +--- + +# Logs + +**tini2p** hi all, meeting in ~10 min. +**tini2p** Meeting agenda: +Greetings +Proposals + status updates +Short-term goals +Meta issues +Confirm next meeting time +**kinghat** hola +**tini2p** bueno @k1nghat +Greetings +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 +any questions/comments? +ok, onto the next +**tini2p** 3: Short-term goals +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. + +LibreSSL +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) +libSodium +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 +libHydrogen +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 +any questions/comments? +**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 +;)