@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+not_bob_afk
+orignal
+postman
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest12767
Irc2PGuest59134
Irc2PGuest67483
Irc2PGuest74564
Irc2PGuest96699
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Sisyphus
Sleepy_
SoniEx2
Yotsu
anon4
b3t4f4c3__
bak83
boonst
cancername
cumlord
eyedeekay_bnc
l337s
onon_1
plap
poriori_
qend-irc2p
r3med1tz
radakayot_
rapidash
scottpedia
segfault
shiver_
solidx66
u5657_
uop23ip
w8rabbit
wodencafe2
x74a6
yoppie
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.