Could we eliminate the authentication step entirely?

[HerbCaudill]

Nik Graf has pointed out to me that the signature challenge that we use for authentication is vulnerable to a kind of replay attack: Eve could simultaneously initiate connections with both Alice and Bob, and pass Alice's proof of identity on to Bob in order to impersonate Alice.

I've written a failing test to confirm that this attack would get Eve past the authentication phase:

// this test fails
it('rejects a proof replay attack', () => {
  const aliceSecretKeys = alice.user.keys
  const alicePublicKeys = redactKeys(aliceSecretKeys)

  // 🦹‍♀️ Eve sends an identity claim to Bob claiming to be Alice
  const evesClaimToBeAlice: KeyScope = { type: USER, name: 'alice' }

  // 👨🏻‍🦲 Bob replies with a challenge to "Alice"
  const bobsChallenge = challenge(evesClaimToBeAlice)

  // 🦹‍♀️ Eve connects to the real Alice and receives her identity claim
  const alicesClaim = { type: USER, name: 'alice' }

  // instead of generating her own challenge...
  let evesChallenge = challenge(alicesClaim)

  // 🦹‍♀️ ... Eve sends Alice a copy of the challenge Bob sent
  evesChallenge = bobsChallenge

  // 👩🏾 Alice signs the challenge with her private key and returns it to Eve
  const alicesProof = prove(evesChallenge, aliceSecretKeys)

  // 🦹‍♀️ Eve returns the signed challenge to Bob
  const evesProof = alicesProof

  // 👨🏻‍🦲 Bob checks Eve's proof
  const validationOfEvesProof = verify(bobsChallenge, evesProof, alicePublicKeys)

  // uh oh.......
  expect(validationOfEvesProof).not.toBeValid()
})

However, Eve's connection would not succeed, because she would have no way to negotiate a session key (see below for details). Eve would need to to generate a seed and encrypt it asymmetrically using Alice's private key, which she doesn't have.

This makes me wonder if we couldn't just dispense with the authentication stage altogether. Alice and Bob would each present their identity claims, and as soon as both were received, any communication would be asymmetrically encrypted until they were able to negotiate a session key, at which point everything would be symmetrically encrypted.

She can't use the replay trick described above — passing along whatever Alice sent her — because the seed is asymmetrically encrypted and can only be decrypted by a specific recipient. Depending on who the recipient is (who Alice thinks she's talking to):

• If the recipient isn't Bob, then Bob will not be able to decrypt the seed.
• If the recipient isn't Eve, then Eve won't be able to decrypt the seed

Either way they won't be able to come up with a shared session key and they won't be able to communicate.

---

Additional context

A connection goes through the following states:

1. Awaiting identity claim
   Alice sends an identity claim and waits for Bob to send his. An identity claim looks like this:

   {
     type: 'USER',
     name: 'alice',
   }

2. Authenticating
   Alice sends Bob an identity challenge, consisting of Bob's identity claim plus a timestamp and a random 32-byte nonce:

   {
     type: 'USER',
     name: 'alice',
     timestamp: 1642975424929,
     nonce: 'rYVHtlSsmqaM9lvbxD5IHeKD...'
   }

   Bob responds by signing the challenge with his private key and sending back the signature as proof of his identity. Alice checks Bob's signature using Bob's public key, which is stored on the chain.

   Simultaneously, Bob challenges Alice's identity and she proves her identity in the same way.

3. Negotiating session key
   This is a Diffie-Hellman-like process: Alice generates a random 32-byte seed, encrypts it asymmetrically with her private key and Bob's public key, and sends it to Bob. On his end, Bob does the same.

   Bob decrypts Alice's seed using her public key and his secret key. He combines the two seeds and hashes them to come up with a session key. On her end, Alice does the same and ends up with the same session key.

   From now until the end of the connection, all communication between Alice and Bob is symmetrically encrypted using this session key.

4. Synchronizing chains
   Alice and Bob exchange information about their chains, and send the other any links that they might be missing, until they both have the exact same chain.

5. Connected
   At this point the application can use this as a secure connection to transmit any sort of message.