--- layout: post title: Overview and Logs for the tini2p Dev Meeting Held on 2019-03-28 summary: Project infrastructure, Current status, Roadmap, I2P proposal implementation, and miscellaneous tags: [dev diaries, i2p, crypto] author: el00ruobuob / oneiric --- # Logs **\** 0. greets **\** hi **\** Hey! **\** o/ **\** 1. Project infrastructure / DevOps **\** hi all **\** recently setup CircleCI, Docker and Bitbucket CI pipelines **\** going to try out Drone CI (integrates w/ GitLab), and decide on a final CI provider **\** will keep alternative configs in contrib/ **\** got a basic Docker image setup with everything needed to build tini2p **\** need to fix net tests to be able to run in a container for accurate coverage stats **\** other than that, CI is more-or-less setup **\** will be experimenting/playing with gitea over the next weeks, and mirror GitLab to GitHub, BitBucket, and gitea **\** unfortunately lost access to tini2p account on GitHub, though still have push ability **\** main github repo is now: https://github.com/tnii2p-project/tini2p **\** 404 :( **\** derp **\** type **\** typo **\** my fingers are terrible today **\** https://github.com/tini2p-project/tini2p **\** Yea! **\** -\_- **\** lol **\** anyway **\** any questions/comments? i think that's all for infrastructure stuff. **\** Do you see any dependency problems with Drone CI or the other choices? (I haven't used them so I'm not sure about any restrictions/costs.) **\** most of them i've seen are basically the same **\** x free hours for builds, then monery **\** the integrations are the differentiators **\** circle works with github and bitbucket, drone works with gitlab **\** sry, have to go due to emrf, bbl **\** think there are webhook integrations on most/all major gitserver providers **\** anyway **\** ttyl **\** anything else on 1? **\** 2. Current project status / what's been done **\** spent a lot of time replacing crypto++ with libsodium + tiny-AES-c **\** then realized, "oh, i need an SSL lib" **\** so, added LibreSSL as a dependency for potential future Keccak patch, and replaced tiny-AES-c with SSL impl **\** that's in an open MR: https://gitlab.com/tini2p/tini2p/merge\_requests/2 **\** finished with code cleanup, generic crypto/signature wrappers, and a basic experimental ECIES-X25519-AEAD-Ratchet impl **\** merged MR: https://gitlab.com/tini2p/tini2p/merge\_requests/1 **\** currently working on generic wrappers for the proposed Blake2b EdDSA variants **\** which i will discuss in 4 **\** questions/comments on 2? **\** awesome progress **\** will also hopefully be able to help zzz with ECIES testing (fingers-crossed) **\** thanks endogenic :) **\** 3. Short-term road map **\** implement the Blake2b sig variants to help other I2P projects with testing **\** implement tunnels + basic netdb **\** if lmdb interface is simple enough, will skip past doing blockfile format, and just use lmdb for addressbook/netdb needs **\** that's where i want to be anyway :) **\** adding alpha and beta milestones to the gitlab project **\** projected alpha release for 2019/07/10 **\** with a beta following 3 months after **\** will see how this first cycle goes, but will try to keep to that release schedule, or shorten it if feasible **\** good plan **\** the minimum usable set is generally critical to keep in mind to avoid getting lost along the way **\** dont think that's a huge issue here given the name "tiny" though :) **\** good origins **\** yeah, if shorter, may do alpha (2 months) -> beta (2 months) -> point release **\** true, as part of 4. i'll talk about the current sig variant proposals, and which of those will end up in tini2p **\** which is actually a nice transition (smooth endogenic) **\** 4. I2P proposal implementation **\** https://geti2p.net/spec/proposals/123-new-netdb-entries **\** https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet **\** https://geti2p.net/spec/proposals/146-red25519 **\** https://geti2p.net/spec/proposals/148-eddsa-blake2b-ed25519 **\** we went over 123 and 144 last meeting, iirc **\** one thing that has changed, zzz has said he will be switching focus back to ECIES, and hammering out some spec details **\** so we are getting closer to a finalized spec, which will reduce code footprint **\** 146 and 148 are the new sig variant proposals **\** for eddsa **\** RedDSA is needed for blinding encrypted lease sets, and Blake2b variants are needed to protect against LEA attacks **\** Ed25519ctx was also suggested, and is being considered for LEA protection **\** personally, think Ed25519ctx is gross given the alternatives, but it's in an RFC **\** RFC 8032 to be specific **\** the hash function in RFC 8032 isn't specified, other than being a crypto-secure hashing function with 512-bits security **\** Blake2b satifies all criteria **\** for full details see the proposals and #ls2 meeting logs **\** so, my plan is to write generic wrappers for all variants, then keep whichever get accepted **\** right now, it's looking like RedDSA-Blake2b-EdDSA can be used for all places where a signature is needed **\** a lot is still up in the air though, and nothing has been finalized yet **\** any comments/questions on 4? **\** one more thing actually, EdDSA-Blake2b-Ed25519 could also be used everywhere a signature is used **\** afaiui EdDSA-Blake2b-Ed25519 can also do blinding needed for encrypted lease sets **\** 5. Confirm next meeting time **\** same time two weeks? **\** yup **\** right on, meeting over. thanks to all for attending