0 sats \ 9 replies \ @ek 20 Jan 2023 \ parent \ on: emon: encrypted messaging over nostr with lightning integration ⚡ nostr
Ah, ok, was a short one. IV is indeed random stuff:
Where did you get the idea that the IV contains the recipients public key?
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
reply
The code looks familiar. It seems they are implementing nip 4, encrypted DMs, to send messages back and forth.
It generates a shared secret, based on the sender's private key and the recipient's public key to encrypt the message (I think) so that the recipient can decrypt it.
reply
Yeah no kidding that's the code I'm referencing. NIP 4 was the link I was sent by SebasWouters when I asked what encryption algorithm its using.
reply
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
reply
https://medium.com/asecuritysite-when-bob-met-alice/a-bluffers-guide-to-secp256k1-404e423e612
The main applications of secp256k1 are in digital signing (ECDSA) and key exchange (ECDH)
ECDH with secp256k1 can apparently be used to generate a shared key which is then used in the AES cipher. I'm continuing this rabbit hole though because my mind is getting blown to bits:
https://asecuritysite.com/ecdh
You guys gotta learn this with me. This is nuts if true. If the participants really can't find each other's private keys after this exchange.
reply
Will learn this with you when I have more time. I am on mobile atm and switching tabs and stuff gets really annoying haha
reply
Nooo because in order for this to work,
"Bob will generate a public key (B) and private key (b), as will Alice (A and a). They then exchange their public keys, and the shared key will then be a×b×G, and where G is the generator point on the elliptic curve."
Okay so Bob sends bG to Alice and Alice sends aG to bob, but then that means Alice can do result/G = b and Bob can do result/G = a and then on NOSTR start posting notes as each other's identities...right?
reply
No. I haven't watched your video but Computerphile made a very good video about diffie hellman:
reply