Logs from tini2p meeting of 2019-04-11

_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  
+;)