@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+dr|z3d
+hagen
+hk
+lbt
+not_bob_afk
+orignal
+postman
+radakayot
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens_
Irc2PGuest32178
Irc2PGuest32605
Irc2PGuest38796
Irc2PGuest54664
Irc2PGuest59134
Irc2PGuest63915
Irc2PGuest77229
Irc2PGuest90091
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Sleepy
Soni
Teeed
acetone_
aeiou
aisle
ardu
b3t4f4c3___
bak83
dickless
dr4wd3_
eyedeekay_bnc
foobar
mareki2p
poriori
profetikla
qend-irc2p
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
w8rabbit
x74a6
eyedeekay
phil mentioned something interesting in go-i2p-dev just now re: SAMv3 and it's got me thinking... some background info, the Go SAMv3 libraries share a common `i2pkeys` library which provides convenient ways to use DEST GENERATE by storing keys in data files mapped to a string defined by the application "application name"
eyedeekay
But in order to accomplish this it actually contains a tiny SAMv3 library, just enough to do DEST GENERATE and manage(store to disk, load from disk) the result.
eyedeekay
Which is a little incongruous as phil pointed out, because i2pkeys is actually also a SAM library and it's sole purpose is to be imported into other SAM libraries
eyedeekay
The reason for this is convenience, because IMO i2pkeys should probably switch to using go-i2p/lib/crypto to generate when it becomes stable, but for now that's not possible, so instead we do DEST GENERATE
eyedeekay
But even then it's maybe still little incongruous to be managing keys this way.
eyedeekay
So here's the interesting bit:
eyedeekay
But what if there were a way to have a key stored and loaded automatically via SAMv3?
eyedeekay
What if, during SESSION CREATE, it were possible to pass a "named" destination, not a key, but just an identifying string, like
eyedeekay
SESSION CREATE DESTINATION=applicationName
eyedeekay
the SAM bridge then determines if the string is a valid key, if it isn't, it assumes a named application and enforces a reasonable limit to the character set and length of the name
eyedeekay
and SAMv3 manages the key automatically by(pardon my nasty pseudocode):
eyedeekay
if applicationNameDotdat.exists()
eyedeekay
return SAM error that says key name in use and halt session creation
eyedeekay
else
eyedeekay
create applicationNameDotdat and store keys in sam directory
eyedeekay
return session for keys: applicationNameDotdat
eyedeekay
Seems pretty simple, is there something I'm obviously missing?
zzz
eyedeekay, our SAM server v1 java API (NOT the SAM protocol) actually does support this
zzz
it stores keys in the file 'sam.keys' in a hosts.txt-style format
zzz
there's a few reasons why it's not great
zzz
- security: all applications have access to all keys
zzz
- lifecycle: the server-side has no sense of application lifecycle or removal, so keys are forever
zzz
- clients are best positioned to do storage of their own keys in an appropriate location and manner
zzz
- namespace collisions / multiple identical clients
zzz
so the SAMv3 philosophy is that it's the applications' problem. If you wanted to build that feature into your client-side lib that would be fine, although it may have some of the same issues listed above
eyedeekay
That's sort of what I of did with go-i2p/i2pkeys in line with the philosophy that applications should manage the keys, it doesn't map 1/1 to this idea yet but the API is pretty OK for now
eyedeekay
that "all applications have access to all keys" security issue is especially not awesome
eyedeekay
explanation makes sense, thanks
zzz
seems like you have a zillion go libs with duplicated code/functions, maybe you have some master plan to dedup everything and create dependencies?
zzz
I can't begin to keep track of them all
orignal
zzz, I have a promlem
orignal
I'm able to sign and verify own LS2 with MLDSA44, but your fails