NIP-04 replacement

[paulmillr]

I have opened pull request for (allegedly) NIP-44 Encrypted Direct Message (Versioned): #574

It uses versioning, XChaCha20 and hashed shared secret. Algorithm choice rationale is described in the pull request. New Versioning feature explicitly requires non-compatible versions to throw user-visible errors.

Please take a look at it! Any comments are welcome.

---

(old message)

Continuation of #107 and #303 with precise ideas.

I'll be listing points that must be clarified in separate posts each so that we can have a separate tree-based discussion branches for comfort.

So it seems like we're moving towards hashed ECDH key and xchacha20. My proposal:

// 1. Every user have their static keys
// const [alicesPrivate, bobsPub] = ...

function getConversationKey(privA, pubB) {
  const x = secp256k1.getSharedSecret(privA, pubB);
  return sha256(x); // must only contain 32b of X coordinate without additional parity byte
}
function encrypt_nip99(conversationKey, plaintext) {
  const iv = secureRandom(24);
  const ciphertext = xchacha20.encrypt(plaintext, conversationKey, iv);
  return { ciphertext, iv };
}

const convKey = getConversationKey(alicesPrivate, bobsPub);
const {ciphertext, iv} = encrypt_nip99(convKey, "hello")

const unsigned = JSON.stringify({
  kind: 99,
  content: {ciphertext, iv},
  pubkey: alicesPub,
  tags: [["p", alicesPub]]
});
const signed = secp256k1.schnorr.sign(unsigned, alicesPrivate);

[paulmillr]

A post per feature. Reply to this or other posts.

The first point is AES-GCM IV.

1. Fetch 12 bytes of IV from CSPRNG
2. Fetch 6 bytes from CSPRNG, and make other 6 bytes come from a timestamp.

I'd argue against 1 because collisions are likely in long-running conversations, with 12-byte nonces.

[paulmillr]

The second point is the need for MAC.

It doesn't seem to be needed, since we have signed messages? But we can't just leave NIP04 AES-CBC in, because CBC mode is pretty bad.

[earonesty]

yeah, im fine with gcm + mac, that's what i use

[paulmillr]

The third point is AES-GCM vs ChaCha20 / XChaCha20. I feel like maybe we should discuss this since we're changing the encryption method.

Advantages:

• ChaCha20 is standard defined in RFC7539. It is used in TLS 1.3 to encrypt web pages
• It is more secure. Reusing IV won't leak the key - unlike in AES-GCM. This is very important for long-running convos.
• It is faster than AES on budget smartphones
• It is present on many platforms, iOS, and others
• It can be implemented in 50-100 lines of code.
• XChaCha solves point 1, we can just fetch 24 bytes from CSPRNG. Collisions won't matter

Disadvantages:

• It is not present in webcrypto. Does this even matter? We are already using several primitives which are not present in webcrypto: secp256k1 getSharedSecret AND secp256k1 schnorr signatures.

If ChaCha is in, I can probably create a secure ChaCha package in a week or so.

[earonesty]

yes. nonce reuse only means messages with that nonce are compromised. not other messages. that's still a problem. and we still need 16 bytes. we could avoid using an hkdf in that case, but why do that? why even bother building something people might be able to attack, even rhetorically. version 1 should be:

• slow
• safe
• work everywhere
• easy to understand

thats my goal for v1

[paulmillr]

Chacha works everywhere and is arguably easier to understand than AES. And of course it is safer

[earonesty]

im ok with xchacha20, except that it's not gonna be optimized in a lot of situations, so will be slower (aes is heavily optimized)

here's what i would have to use ... in mobile/web dev stuff . that's what most people would wind up using until crypto.subtle ships with xchacha20 ... which seems like a "never"
https://github.com/paragonie/xchacha20-js

[earonesty]

i kinda dont care that much. xchacha is way better on iv collissions, but we pretty much solved any possibility of collission by hashing-in the iv, and then we have a more composeable algo, safer for someone to drop-in aes, chacha, or whatever they want. its a clean key, and a clean iv

[paulmillr]

here's what i would have to use ... in mobile/web dev stuff . that's what most people would wind up using until crypto.subtle ships with xchacha20 ... which seems like a "never"

You are already using noble crypto. same way, noble-chacha would be created and can be used.

[earonesty]

i would like to start the conversation from here:

async nip04XEncrypt(privkey: string, pubkey: string, content: string, version: number) : Promise<string> {
    const key = secp256k1.getSharedSecret(privkey, '02' + pubkey)
    const normalizedKey = key.slice(1,33)
    const iv = randomBytes(16)
    const derivedKey = hkdf(sha256, normalizedKey, iv, undefined, 32);
    
    let plaintext = utf8Encoder.encode(content)
    let cryptoKey = await crypto.subtle.importKey(
      'raw',
      derivedKey,
      {name: 'AES-GCM'},
      false,
      ['encrypt']
    )

    let ciphertext = await crypto.subtle.encrypt(
      {name: 'AES-GCM', iv},
      cryptoKey,
      plaintext
    )

    let ctb64 = base64.encode(new Uint8Array(ciphertext))
    let ivb64 = base64.encode(new Uint8Array(iv.buffer))
   
    return ctb64 + "??" + ivb64 + "??" + version.toString()
  }

i see no reason to play with dangerous iv's anymore. a new key every time ... derived from 16 bytes. unassailable is better than using times, which can be attacked.

[earonesty]

arguing for symmetric key reuse is kinda weird really

[earonesty]

also looking at the code here, sha256 vs hkdf is basically the same perf:

https://github.com/paulmillr/noble-hashes/blob/main/src/hkdf.ts

the only difference is the addition of a counter during the rounds

hkdf(m, salt:iv) ==== sha256(m + "1" + iv + "2")

[earonesty]

so you prevent length extension by appending a counter, it's fine. harmless really. lets just use it

[earonesty]

then the choice of xchacha and aes is equivocal, we can ship an NIP with both versions listed, and let people vote on it or something. xchacha20 can be registered as v1 and aesgcm can be registered as v2.

[paulmillr]

arguing for symmetric key reuse is kinda weird really

Why? It's safe. Same key could be used safely on 2^32 messages in gcm, or on 2^80 messages in chacha.

hkdf is 10 times slower, look into readme, or run benchmarks by yourself.

[earonesty]

this is an ephemeral public key encryption standard proposal layered on the nip04 replacement above

async nipXXEncrypt(pubkey: string, inner: UnsignedEvent, version: number): Promise<NostrEvent> {
    const event = await this.signEvent(inner)
    const content = JSON.stringify(event)
    const iv = randomBytes(16)
    const dpriv_n = (BigInt("0x" + this.privKey) * BigInt("0x" + Buffer.from(iv).toString("hex"))) % secp256k1.CURVE.n
    const epriv = dpriv_n.toString(16)
    const epub = getPublicKey(epriv)
    const encrypted = await this.nip04XEncrypt(epriv, pubkey, content, version, iv)
    const unsigned = {
      kind: 99,
      content: encrypted,
      pubkey: this.pubKey,
      tags: [["p", pubkey]]
    }
    const signed = await this.signEventWith(unsigned, epriv, epub)
    return signed
  }

the need for this is to layer other protocols on top of it... not as a "blinded DM" although that works too!

this allows you to send someone a message with the following properties:

• you can't decrypt it later
• the public key is not yours, so it doesn't appear to come from you
• the receiver can verify the public key of the sender

this is suitable for a NIP38 group chat invitation, for example. the advantage to having one standard is that it improves plausible deniability

[paulmillr]

the need for this is to layer other protocols on top of it

Could you give an example? Which protocols?

[earonesty]

for example: https://github.com/nostr-protocol/nips/pull/59/files should use this system for all invitation messages. invitations are purely directional, there's never a reason to look in the envelope for the sender.

[earonesty]

this also allows an observer to not know the sender (who invited them), and doesn't leak the metadata (sender info) that a regular message leaks. all messages to the board can use this protocol too. it's a flexible protocol.

[paulmillr]

Folks are saying relays don't push through messages from keys they don't know. How is that going to play through?

[earonesty]

i said that, and relays should have other, better ways of authenticating connections (at the ssl/cert level, for example), relying on a fixed public key for deeper protocols seems broken, and it's good to get away from that. not saying it won't be problematic for some people, but there are other ways around that problem

i like the idea that both this and the other use the same basic encryption primitives and versions and that this can be used as a "base layer" for more complex stuff, that's all