pull down to refresh

emon: encrypted messaging over nostr with lightning integration ⚡emon.chat
1175 sats \ 33 comments \ @SebasWouters 20 Jan 2023 nostr freebie
write
preview
related posts
20 sats \ 20 replies \ @nerd2ninja 20 Jan 2023
What's the encryption algorithm its using?
reply
111 sats \ 18 replies \ @SebasWouters OP 20 Jan 2023
https://github.com/nostr-protocol/nips/blob/master/04.md
reply
27 sats \ 15 replies \ @nerd2ninja 20 Jan 2023
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
0 sats \ 10 replies \ @ek 20 Jan 2023
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
0 sats \ 9 replies \ @ek 20 Jan 2023
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
0 sats \ 8 replies \ @nerd2ninja 20 Jan 2023
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
0 sats \ 2 replies \ @nerd2ninja 20 Jan 2023
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
0 sats \ 1 reply \ @pi 20 Jan 2023
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.
view replies
0 sats \ 4 replies \ @ek 20 Jan 2023
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
60 sats \ 3 replies \ @nerd2ninja 20 Jan 2023
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.
view replies
0 sats \ 3 replies \ @SebasWouters OP 20 Jan 2023
How does the recipient not know the full key to decrypt it? It seems to be working
reply
12 sats \ 2 replies \ @nerd2ninja 20 Jan 2023
I don't know! This spec seems out of spec...its weird as hell
reply
0 sats \ 1 reply \ @SebasWouters OP 20 Jan 2023
I think it was always planned to update the spec in the future, you might be right that it's not super secure
reply
0 sats \ 0 replies \ @nerd2ninja 20 Jan 2023
Don't assume that on the basis of my dumbass. I'm learning a whole lot right now.
reply
0 sats \ 1 reply \ @melvincarvalho 20 Jan 2023
whoa! military grade!
reply
10 sats \ 0 replies \ @SebasWouters OP 20 Jan 2023
It's actually not that advanced. Doesn't provide forward secrecy like signal. Can and will be improved upon in the future.
reply
25 sats \ 0 replies \ @DarthCoin 20 Jan 2023
maybe none. Just using fancy words. Like "military grade security" 😂😂
reply
0 sats \ 3 replies \ @gandlaf21 21 Jan 2023
Just FYI, Encrypted messaging over nostr nip04 is not optimal, and way less secure than for example Signal or something alike.
some drawbacks of Nip04:
  • Senders PUBK is leaked
  • Recipients PUBK is leaked
  • Timestamp is leaked
  • If one private key gets compromised, the whole conversation can be decrypted (due to no key-ratcheting)
reply
0 sats \ 0 replies \ @SebasWouters OP 29 Jan 2023
https://excalidraw.com/#json=a3QchmPVJTwUmnGRdgWAE,ruanCZyI0JqggZlZOrLm_A
reply
0 sats \ 1 reply \ @kevkevin 21 Jan 2023
are they using Elliptic curve Diffie Helman is that why? Isn't the point of Diffie Helman to establish a symmetric that both parties can use but in order to do so you need to expose your pubkey
reply
0 sats \ 0 replies \ @gandlaf21 22 Jan 2023
Yes, the senders and receivers pub key are stored in the event data.
You could mask the receiver by sending to many pub keys, but only one real one.
ECDHKE is good, but for conversation, where multiple messages are sent back and forth, you want an additional security parameter. The keys for encryption and decryption should change with each message. So that if a key gets compromised, the history cannot be decrypted
reply
0 sats \ 1 reply \ @BloggingBitcoin 20 Jan 2023
Has anyone tried it yet? What's different about this vs. Encrypted messaging in Astral?
reply
0 sats \ 0 replies \ @SebasWouters OP 21 Jan 2023
It's probably exactly the same, messages sent on one should be readable on the other
reply
0 sats \ 0 replies \ @brugeman 20 Jan 2023
Works for me! How can I change the relay it's using? I don't see metadata of the people I'm talking to
reply
0 sats \ 4 replies \ @kevkevin 20 Jan 2023
url seems to be broken :/
reply
0 sats \ 2 replies \ @satcat 20 Jan 2023
login url 404 for me too
reply
0 sats \ 1 reply \ @SebasWouters OP 20 Jan 2023
refreshing the login page gives an error indeed, i need to fix that. You do need a nostr browser extension as well. you can get nos2x or the alby browser extension.
reply
0 sats \ 0 replies \ @SebasWouters OP 20 Jan 2023
404 should be fixed!
reply
0 sats \ 0 replies \ @SebasWouters OP 20 Jan 2023
It works for me?
reply