monero-site/_posts/2019-04-11-logs-for-the-tini2p-dev-meeting-held-on-2019-04-11.md

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