[tor-commits] [torspec] 19/19: tor-spec: Change KP to KP throughout

[gitolite role]

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main
in repository torspec.

commit f16803f6f93680f41f72bae29cf9dbef3962f94d
Author: Ian Jackson <ijackson at chiark.greenend.org.uk>
AuthorDate: Thu Jan 19 14:24:27 2023 +0000

    tor-spec: Change KP to KP throughout
    
    Emacs's idea of s/\bPK\b/KP/
---
 tor-spec.txt | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt
index cd95d79..e522135 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -123,10 +123,10 @@ see tor-design.pdf.
 
    KEY_LEN -- the length of the stream cipher's key, in bytes.
 
-   PK_ENC_LEN -- the length of a public-key encrypted message, in bytes.
-   PK_PAD_LEN -- the number of bytes added in padding for public-key
+   KP_ENC_LEN -- the length of a public-key encrypted message, in bytes.
+   KP_PAD_LEN -- the number of bytes added in padding for public-key
      encryption, in bytes. (The largest number of bytes that can be encrypted
-     in a single public-key operation is therefore PK_ENC_LEN-PK_PAD_LEN.)
+     in a single public-key operation is therefore KP_ENC_LEN-KP_PAD_LEN.)
 
    DH_LEN -- the number of bytes used to represent a member of the
      Diffie-Hellman group.
@@ -180,7 +180,7 @@ see tor-design.pdf.
 
    KEY_LEN=16.
    DH_LEN=128; DH_SEC_LEN=40.
-   PK_ENC_LEN=128; PK_PAD_LEN=42.
+   KP_ENC_LEN=128; KP_PAD_LEN=42.
    HASH_LEN=20.
 
    We also use SHA256 and SHA3-256 in some places.
@@ -196,14 +196,14 @@ see tor-design.pdf.
 0.4. A bad hybrid encryption algorithm, for legacy purposes.
 
    Some specifications will refer to the "legacy hybrid encryption" of a
-   byte sequence M with a public key PK.  It is computed as follows:
+   byte sequence M with a public key KP.  It is computed as follows:
 
-      1. If the length of M is no more than PK_ENC_LEN-PK_PAD_LEN,
-         pad and encrypt M with PK.
+      1. If the length of M is no more than KP_ENC_LEN-KP_PAD_LEN,
+         pad and encrypt M with KP.
       2. Otherwise, generate a KEY_LEN byte random key K.
-         Let M1 = the first PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes of M,
+         Let M1 = the first KP_ENC_LEN-KP_PAD_LEN-KEY_LEN bytes of M,
          and let M2 = the rest of M.
-         Pad and encrypt K|M1 with PK.  Encrypt M2 with our stream cipher,
+         Pad and encrypt K|M1 with KP.  Encrypt M2 with our stream cipher,
          using the key K.  Concatenate these encrypted values.
 
    Note that this "hybrid encryption" approach does not prevent
@@ -547,8 +547,8 @@ see tor-design.pdf.
          2 -- CREATED     (Acknowledge create)      (See Sec 5.1)
          3 -- RELAY       (End-to-end data)         (See Sec 5.5 and 6)
          4 -- DESTROY     (Stop using a circuit)    (See Sec 5.4)
-         5 -- CREATE_FAST (Create a circuit, no PK) (See Sec 5.1)
-         6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
+         5 -- CREATE_FAST (Create a circuit, no KP) (See Sec 5.1)
+         6 -- CREATED_FAST (Circuit created, no KP) (See Sec 5.1)
          8 -- NETINFO     (Time and address info)   (See Sec 4.5)
          9 -- RELAY_EARLY (End-to-end data; limited)(See Sec 5.6)
          10 -- CREATE2    (Extended CREATE cell)    (See Sec 5.1)
@@ -1196,7 +1196,7 @@ see tor-design.pdf.
    not very good.  (See Goldberg's "On the Security of the Tor
    Authentication Protocol".)
 
-   Define TAP_C_HANDSHAKE_LEN as DH_LEN+KEY_LEN+PK_PAD_LEN.
+   Define TAP_C_HANDSHAKE_LEN as DH_LEN+KEY_LEN+KP_PAD_LEN.
    Define TAP_S_HANDSHAKE_LEN as DH_LEN+HASH_LEN.
 
    The payload for a CREATE cell is an 'onion skin', which consists of
@@ -1204,12 +1204,12 @@ see tor-design.pdf.
    value is encrypted using the "legacy hybrid encryption" algorithm
    (see 0.4 above) to the server's onion key, giving a client handshake:
 
-       PK-encrypted:
-         Padding                       [PK_PAD_LEN bytes]
+       KP-encrypted:
+         Padding                       [KP_PAD_LEN bytes]
          Symmetric key                 [KEY_LEN bytes]
-         First part of g^x             [PK_ENC_LEN-PK_PAD_LEN-KEY_LEN bytes]
+         First part of g^x             [KP_ENC_LEN-KP_PAD_LEN-KEY_LEN bytes]
        Symmetrically encrypted:
-         Second part of g^x            [DH_LEN-(PK_ENC_LEN-PK_PAD_LEN-KEY_LEN)
+         Second part of g^x            [DH_LEN-(KP_ENC_LEN-KP_PAD_LEN-KEY_LEN)
                                            bytes]
 
    The payload for a CREATED cell, or the relay payload for an
@@ -1275,7 +1275,7 @@ see tor-design.pdf.
 
        NODEID      Server identity digest  [ID_LENGTH bytes]
        KEYID       KEYID(B)                [H_LENGTH bytes]
-       CLIENT_PK   X                       [G_LENGTH bytes]
+       CLIENT_KP   X                       [G_LENGTH bytes]
 
    The server generates a keypair of y,Y = KEYGEN(), and uses its ntor
    private key 'b' to compute:
@@ -1287,7 +1287,7 @@ see tor-design.pdf.
 
    The server's handshake reply is:
 
-       SERVER_PK   Y                       [G_LENGTH bytes]
+       SERVER_KP   Y                       [G_LENGTH bytes]
        AUTH        H(auth_input, t_mac)    [H_LENGTH bytes]
 
    The client then checks Y is in G^* [see NOTE below], and computes

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.