@eyedeekay
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+altonen
+dr|z3d
+hagen
+hk
+mareki2p
+orignal
+postman
+qend-irc2p
+snex
+weko
+wodencafe
Arch
BubbRubb
Daddy_
Daddy_1
Danny
DeltaOreo
FreeB
FreefallHeavens
Irc2PGuest58427
Irc2PGuest60590
Irc2PGuest630423
Irc2PGuest92548
Irc2PGuest95056
Onn4l7h
Onn4|7h
Sisyphus
Sleepy
SlippyJoe_
T3s|4_
Teeed
acetone_
ardu
b3t4f4c3__
bak83_
boonst
dr4wd3
eyedeekay_bnc
guest7621
not_bob_afk
not_human
onon_
poriori_
profetikla
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
w8rabbit
x74a6
segfault
zzz: dr|z3d: eyedeekay: in proposal 169 i guess crypto should be implemented also by non-openssl libraries like nacl, libsodium, etc. if not, please consider self-implemented version in pure c89. it will be usefull in java by wrapper and c++ and any other language, go as an example
eyedeekay
One would indeed be useful but for go-i2p it's a NACK, one of the most useful things about having a Go router is all the cross-compile targets Go can support, as long as you don't use CGO
segfault
openssl isn't secure library. supporting ways to use other libraries is very important for paranoid anonymouses
eyedeekay
frankly we're more likely to export a C library from our Go source than the other way around
eyedeekay
but that also means we can't use openssl either so that's probably good
segfault
i offer add "proposal cannot be applyed until depedences-free library in pure c89 not implemented" in proposal 169 or other implementations of i2p will became never
segfault
will become never*
segfault
bcs pure c89 library = library in any language
eyedeekay
Sure a C library would be great in that way, but I can only speak for what go-i2p will do right now and right now our rule is no-FFI, no CGo
eyedeekay
Both for our sanity and for the eventual goal of leveraging Go to export a C library and cross-compile for weird stuff
segfault
eyedeekay: you can wrap pure c89 library as go library and use it in go-i2p without troubles, like other any go library
zzz
no. new crypto has to be standardized and available in some libraries. It's not a requirement that we reimplement it in your favorite language, that's your problem
zzz
if you want to ask DJB to do it, great, but I think he's pushing Classic McElice ))
segfault
zzz: for now i2p router can be implemented using only one library: noise (with noise reference implementation). if i2p accept this proposal openssl will become required library. openssl is very bad solution for paranoid solutions (why libressl and etc become?) that's great backdoor. also that kills any tries to implement i2p by other languages
eyedeekay
CGo without troubles is a thing I will believe when I see it. I'm always happy to see more people working on libraries, but I agree with zzz.
zzz
wrong segfault. we're using the bouncycastle lib.
segfault
eyedeekay: this library will have a few functions: generate keypair, encrypt, decrypt, sign, check sign.
segfault
zzz: bc is unique java library. c have no library, c++ have no library, go have no library, rust have no library, delphi have no library, c# have no library, etc
zzz
not our problem. Every language will have MLKEM/MLDSA support library in the next year or two. We are not going to wait, and we're not writing libraries for your favorite language, that's not our job
zzz
See the timeline at the bottom of the proposal. This will take several years. Are you saying we are not allowed to start?
eyedeekay
go std is planned to get PQ this year, we will likely use that
eyedeekay
~1.26 for MLDSA
segfault
zzz: why not? you can start, i mean don't make it a standard of protocol for now. discuss, try implement and so on, but only as part of proposal. i offer make it a new standard if and only if library for many languages will be allowed.
zzz
no, you have it backwards. First we approve a standard, then we implement it, then we roll it out, and years later we deprecate the old encryption.
zzz
standards come first, not last
orignal
zzz, do you exclude PQ from the release?
orignal
or let users use it
segfault
zzz: ok, thx. please don't forget about potential implementations. try fix problems as easy as possible. many implementations is more security.
zzz
I'm confident there will be a C lib and many other libs sometime in the next two years
zzz
orignal, nothing is checked in, and won't be until we have at least one more review
orignal
so, I will exclude too
zzz
you can leave yours in if you like, but we really need to decide the hash issue
orignal
C lub? openssl and boringssl are C libs
zzz
he doesn't like openssl, he wants it in his favorite lib, whatever that is, and wants us to write it?
orignal
he can like or not like whaever he wants. It's his problem only
orignal
PQ implemnetations is not an I2P business at all
orignal
and I told you few moths ago
orignal
*months
orignal
onon has made a stratgic mistake poiting him to prop 169 ))
segfault
orignal: you are right. i just tell about dependences. for now only noise (with reference implemntation) library required. also openssl have big security troubles (check libressl and etc implementations)
orignal
and why it should be mine or zzz's problem?
orignal
do whateever you want
segfault
orignal: no problem. zzz just answer me that standard will applyed first, not last
segfault
orignal: and many languages will have pq libs in a few years
zzz
huh?
zzz
it's available in java and C++, coming soon in Go and Rust. That's all we need for now. We aren't going to wait for a C lib before approving the proposal.
eyedeekay
Actually looks like rust more-or-less already has it :)
orignal
how about python? ))
eyedeekay
python: mlkem published on Feb 8, 2025
orignal
great