Skip to content

Instantly share code, notes, and snippets.

@phyro
Last active June 7, 2022 19:11
Show Gist options
  • Save phyro/fcecf15ac9fe5784478538b251e27180 to your computer and use it in GitHub Desktop.
Save phyro/fcecf15ac9fe5784478538b251e27180 to your computer and use it in GitHub Desktop.

Faceless Slatepacks

Currently, the encrypted slatepack output has different length depending on at which step the slatepack is. Moreover, the length depends on the number of inputs/outputs the transaction has. This can leak information about the progress of a transaction if slatepacks were public. We could see that a slatepack with a single signature was published and soon a transaction appeared which allows us to link the transaction with a slatepack. It doesn't tell us much, but it shows some patterns that may show some timing correlations between steps or similar.

To combat this we'd have to make the encrypted messages of the same length. This could be done by introducing a new field e.g. lorem_ipsum that would hold dummy data. We could agree every slatepack needs to be of length N and fill this dummy field accordingly. Another option would be to introduce a wrapper around the slatepack that is another encryption e.g. BEGINFACELESS. asdasdasd .ENDFACELESS which would encode something like

{
  "version": 1,
  "lorem_ipsum": "asdfasdfasdf",
  "slatepack": "BEGINSLATEPACK . asdfasdfsafasd ... .... . ENDSLATEPACK",
}

Both options would make every encrypted slatepack look the same regardless of the step it is at. We can then publish these publicly with a guarantee that there won't be any patterns between them except for timings.

Slatepacks are already very good at hiding the information, having them all look the same might push this even further.

Garbage bytes

The field we introduced makes us transfer garbage data which is bad for bandwidth. But it might be worth the privacy increase. In the worst case, we'd add 2x slatepack size which is a constant factor. So both the store and the users scanning are hit with a constant factor which means it's not that bad even if we had thousands of these.

@davidtavarez
Copy link

The field we introduced makes us transfer garbage data which is bad for bandwidth.
I would not use the word "bad" to be honest.

The length of lorem_ipsum should not be a constant but it should have a reasonable maximum and a minimum of 0 imo.

@phyro
Copy link
Author

phyro commented Jun 7, 2022

@davidtavarez yes, the size of the lorem_ipsum random bytes is such that len(slatepack) + len(lorem_ipsum) == N where N is some predefined constant e.g. 5kb. Since all encrypted messages now have a size of N bytes, they can't be distinguished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment