monero-site/_posts/2019-04-11-logs-for-the-tini2p-dev-meeting-held-on-2019-04-11.md
2019-04-13 18:46:00 +02:00

135 lines
7.1 KiB
Markdown

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