commit c444e527a05314cad6ef1e39d31ad7e74cc2f018 Author: Nick Mathewson nickm@torproject.org Date: Mon Jul 24 14:26:57 2017 -0400
Clarify the TAP hybrid encryption scheme
This is only used in TAP and old-style hidden services, and it's half malleable. I've clarified how the code behaves by adding the change suggested in #22987. I've also noted:
I've also noted that we don't actually reach case 1 with any usage of this algorithm.
I've also replaced Roger's note that someday we'll add a MAC with an admonition not to use this hybrid encryption approach for anything new. We're not planning to add a MAC; we've migrated to ntor instead. --- tor-spec.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt index 3be622f..fd2aaf7 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -115,17 +115,20 @@ see tor-design.pdf.
The "hybrid encryption" of a byte sequence M with a public key PK is computed as follows: - 1. If M is less than PK_ENC_LEN-PK_PAD_LEN, pad and encrypt M with PK. + 1. If the length of M is no more than PK_ENC_LEN-PK_PAD_LEN, + pad and encrypt M with PK. 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, and let M2 = the rest of M. Pad and encrypt K|M1 with PK. Encrypt M2 with our stream cipher, using the key K. Concatenate these encrypted values. + [XXX Note that this "hybrid encryption" approach does not prevent an attacker from adding or removing bytes to the end of M. It also allows attackers to modify the bytes not covered by the OAEP -- - see Goldberg's PET2006 paper for details. We will add a MAC to this - scheme one day. -RD] + see Goldberg's PET2006 paper for details. Do not use it as the basis + for new protocols! Also note that as used in Tor's protocols, case 1 + never occurs.]
1. System overview