pull down to refresh
20 sats \ 20 replies \ @nerd2ninja 20 Jan 2023 \ on: emon: encrypted messaging over nostr with lightning integration ⚡ nostr
What's the encryption algorithm its using?
reply
What the heck...
AES is symetric encryption which can be okay if you encrypt the symmetric encryption key with an asymmetric algorithm and continue communication from there. Instead they have this method where the IV is the recepiants public key and the senders private key? But then the recipient wouldn't know the full key to decrypt it.
I'm really skeptical of this system right now...
reply
If the IV is the recipients public key and the public key doesn't change... IV should never be reused with the same key
Haven't taken a look yet though. Maybe they add some random stuff. Will do now
reply
Ah, ok, was a short one. IV is indeed random stuff:
let iv = crypto.randomFillSync(new Uint8Array(16))
Where did you get the idea that the IV contains the recipients public key?
reply
content MUST be equal to the base64-encoded, aes-256-cbc encrypted string of anything a user wants to write, encrypted using a shared cipher generated by combining the recipient's public-key with the sender's private-key; this appended by the base64-encoded initialization vector as if it was a querystring parameter named "iv".
Okay its not the IV, but don't they need to know each others IV to read each others encrypted messages? Well I understand the actual key is derived from this whole method, but I'm assuming this method is necessary for the recepiant to know what the key is in order to decrypt it.
Otherwise I'm completely wrong and the decryption key is just sent plainly to the receiver which would mean the relay is able to decrypt it too.
reply
let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)
Secp from what I understand, is only supposed to be for digital signatures. I currently understand that any encryption done with it could be cracked kinda easy.
let sharedX = sharedPoint.substr(2, 64)
var cipher = crypto.createCipheriv( 'aes-256-cbc', Buffer.from(sharedX, 'hex'), iv )
Still don't understand how the recepiant is getting the decryption key
Okay its not the IV, but don't they need to know each others IV to read each others encrypted messages?
Yes, you are right, they need it for decryption. The IV is available since it's appended as a query parameter.
How the recipient is able to derive the same key is a good question though. The key seems to be derived using elliptic curves. Will check how this works. They use this library: https://github.com/paulmillr/noble-secp256k1
How does the recipient not know the full key to decrypt it? It seems to be working
reply
I don't know! This spec seems out of spec...its weird as hell
reply
I think it was always planned to update the spec in the future, you might be right that it's not super secure
reply
Don't assume that on the basis of my dumbass. I'm learning a whole lot right now.
whoa! military grade!
reply
It's actually not that advanced. Doesn't provide forward secrecy like signal. Can and will be improved upon in the future.
reply
maybe none. Just using fancy words.
Like "military grade security" 😂😂
reply