From 279db60a94d27c5786c4e3115f5c14b33672973c Mon Sep 17 00:00:00 2001
From: Grishka <git@grishka.me>
Date: Thu, 13 Apr 2023 22:26:55 +0300
Subject: [PATCH] typo

---
 PROTOCOL.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PROTOCOL.md b/PROTOCOL.md
index 38728ec..18a8af4 100644
--- a/PROTOCOL.md
+++ b/PROTOCOL.md
@@ -119,7 +119,7 @@ The **next protocol secret** is further processed to obtain the two 32-byte AES
 Derive two 32-byte "device to device" keys using HKDF-SHA256:
 
 * **D2D client key**, using the **next protocol secret** for input key material, `82AA55A0D397F88346CA1CEE8D3909B95F13FA7DEB1D4AB38376B8256DA85510` for salt, and the string `client` for info
-* **D2D cerver key**, using the same parameters, except **info** is `server`
+* **D2D server key**, using the same parameters, except **info** is `server`
 
 Next, derive the four keys you will use for the actual encryption. All four use the same value of salt, which is `SHA256("SecureMessage")`, or `BF9D2A53C63616D75DB0A7165B91C1EF73E537F2427405FA23610A4BE657642E`. These keys are from the server POV; if you're the client, they need to be swapped around (decrypt/receive shoud use the server key and vice versa).