From 944550077184a3a5061c4d60c9f477626891fced Mon Sep 17 00:00:00 2001 From: Christopher Sanborn <23085117+christophersanborn@users.noreply.github.com> Date: Sun, 30 Sep 2018 00:34:53 -0400 Subject: [PATCH] Typo in table markdown --- bsip-1203.md | 1 + 1 file changed, 1 insertion(+) diff --git a/bsip-1203.md b/bsip-1203.md index 4a78abd..44f52af 100644 --- a/bsip-1203.md +++ b/bsip-1203.md @@ -31,6 +31,7 @@ The current implementation allows for a receipt to be embedded in each Tx output **One-time PubKey:** | Chosen from randomness by sender   **_(33 bytes)_** **Message PubKey:** | Public key controlled by recipient.   **_(33 bytes)_**
**Cipher Text:** | AES encrypted message, using _key ← Shared(OTK,MPK)_ + _Note: Present behavior is to use the Address PubKey as the message PubKey, which reveals intended recipient!!_ A very simple solution would be to change the behavior of using the APK as the message PubKey, and instead to use the Tx output AuthKey as the message PubKey. Because the recipient is able to derive the private key behind the AuthKey through knowledge of the OTK PubKey and the recipient's APK, the recipient would simply need to test the OTK against each of their APK private keys to see if the resulting AuthKey matches the message PubKey. If it does, then the output is recognized as destined to the recipient, even though the recipient's Address PubKey is not identified in the memo header. The computational cost of this is one Diffie Hellman round, a hash operation, and a child key derivation.