&zzz
+R4SAS
+RN_
+eche|off
+nilbog
+orignal
+postman
+qend-irc2p
+sourceress
Arch
Birdy
Irc2PGuest30010
Irc2PGuest36077
Irc2PGuest49364
Irc2PGuest51117
Irc2PGuest6564
Irc2PGuest65656
Irc2PGuest67278
Irc2PGuest74235
Irc2PGuest83482
MatrixBot
Onn4l7h
Over
Sleepy
Teeed
Yotsu
aargh3
ac9f
acetone_
ahiru
anontor
b3t4f4c3__
bob___
cims
dr4wd3_
dr|z3d
duanin2
f00b4r
hababam_
hagen_
leopold
makoto
marek
marek22k
n2
noidea
not_bob_afk
nyaa2pguy
o3d3_
poriori
profetikla
r00tobo
rapidash
solidx66
stormycloud[m]
test7363673
uop23ip
urist_
user_
w8rabbit
zelgomer
mesh
zzz: I noticed that DSAEngine has methods for sign and verify, but none for encrypt and decrypt? But the method SigUtil has methods to convert SigningPuyblicKey and SigningPrivateKey to Java Keys
mesh
zzz: if somebody did, say, want to encrypt data offline using a Destination would that be the right way to go about it?
zzz
mesh no
zzz
signing and encryption keys are different
zzz
you can't use one for the other
mesh
zzz: interesting. Should I2PSession#getDecryptionKey and Destination#getPublicKey be used for decryption and encryption?
zzz
yes and no. those keys are not used for anything and are going away. see proposal 161.
zzz
encryption is a lot more complicated than signing
zzz
I don't think there's anything in i2p that you can mindlessly grab and use for something else without knowing what you're doing
zzz
w.r.t. encryption
mesh
zzz: The signing keys are stable though right? That is, they never ever change. What's the harm of using them for (offline) encryption? The idea here is to possibly encrypt data and then make it available via torrent, not necessarily to speak i2p.
zzz
signature algorithms are not encryption algorithms
zzz
and encrypted communication is very different application from encrypting data at rest
mesh
zzz: yeah. So is there a keypair available from the Destination that you might recommend for encrypting data at rest?
zzz
no
mesh
zzz: not even the decruptionkey/publickey? Understand those might go away in the future
zzz
read up about encryption algorithms in general, symmetric vs. asymmetric, key types, etc.
zzz
you could, maybe, use the key in the destination, if it wasn't going away, but it would be a terrible choice
mesh
zzz: terrible as in not secure or terrible as in it will break one day?
zzz
again, no no no. we haven't magically solved your problem and you can just slap it in
mesh
hehe ok. I will do more research. I was thinking it would be great if the keys in the Destination could be used for sign and encrypt... then you wouldn't have to distribute a separate set of keys "out of band"
zzz
decryption requires private keys which are always out of band
mesh
but it's not the end of the world. As long as we can reliably sign data using I2PSession#getPrivateKey then this opens the door for signing another set of keys
mesh
zzz: no, I know that. The idea would be somebody uses I2PSession#getDecryptionKey to encrypt data and another person uses Destination#getPublicKey to decrypt the data.
zzz
backwards
mesh
zzz: why do you say backwards? Are those keys not a symmetric public/private keypair?
mesh
but anyways it sounds like it will break one day. And part of me realizes that it's a bad idea because keys can be broken, compromised... when encrypting/decrypting data at rest what you really want is a "Session Key", right?
zzz
you decrypt with private keys. you encrypt with public keys
zzz
I believe the tool you're looking for is GPG
mesh
zzz: hmm yeah I see what you're saying now.
mesh
It's really a matter of distributing the public key securely. But I wouldn't need gpg... I could do that using i2p. But then this requires a server listening at a Destination.