agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Typo in table markdown

Browse source
This commit is contained in:
Christopher Sanborn 2018-09-30 00:34:53 -04:00 committed by GitHub
parent effbe1bcde
commit 9445500771
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
bsip-1203.md
View file

@ -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)_** **One-time PubKey:** | Chosen from randomness by sender   **_(33 bytes)_**
**Message PubKey:** | Public key controlled by recipient. &nbsp; **_(33 bytes)_**<br> **Message PubKey:** | Public key controlled by recipient. &nbsp; **_(33 bytes)_**<br>
**Cipher Text:** | AES encrypted message, using _key &leftarrow; Shared(OTK,MPK)_ **Cipher Text:** | AES encrypted message, using _key &leftarrow; Shared(OTK,MPK)_
_Note: Present behavior is to use the Address PubKey as the message PubKey, which reveals intended recipient!!_ _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. 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.