Clarify manage_data value in SEP-10 #366
Conversation
| @@ -81,7 +81,7 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object | |||
| * time bounds: `{min: now(), max: now() + 300 }` (we recommend expiration of 5 minutes to give user time to sign transaction) | |||
| * operations: `manage_data(source: client_account, key: '<anchor name> auth', value: random_nonce())` | |||
| * The value of key is not important, but can be the name of the anchor followed by `auth`. It can be at most 64 bytes. | |||
| * The value must be a 64 byte long base64 encoded cryptographic-quality random string | |||
| * The value must be 64 bytes long. It contains a 48 byte cryptographic-quality random string encoded using base64 (for a total of 64 bytes after encoding). | |||
There was a problem hiding this comment.
I'm reviewing lightsail-network/java-stellar-sdk#243 and the change here is pretty confusing. It looks like you expect 48 random bytes instead of 64 bytes: in other words the expected value is base64(r[48]) (64 bytes long after encoding) vs r[64]. I don't think it decreases security (correct me if I'm wrong) and the client gets 64 bytes in return anyway but it's confusing. Any reason this was changed?
There was a problem hiding this comment.
We changed the text here because it's not obvious that a Base64 digit represents 6 bits, to generate a random 64 bytes base64 string, we need 48 random bytes = (64 * 6)/8. This was a result of the PR here: https://github.com/stellar/js-stellar-sdk/pull/396/files
There was a problem hiding this comment.
I still don't understand why putting 48 base64-encoded bytes in manage_data.value is better than raw 64 bytes... In other words this is the same (in terms of security, brute force attack is hard for both options) but when passing 64 bytes you don't need to base64 encode anything. Basically the code before this: stellar/js-stellar-sdk#396 change worked fine.
There was a problem hiding this comment.
It just means all the characters are readable. It's easier for visual inspection & debugging.
There was a problem hiding this comment.
I think the intended advantage is just that it can be easily printed/serialised for debugging purposes. Raw bytes are harder to see.
No description provided.