Message padding

[AdamISZ]

An easy todo: !sig messages should have fixed length to avoid leaking info. !tx messages don't seem to need it, as same for all counterparties. For the other encrypted messages, I will have a think; hopefully it's not an issue. But the fix for !sig messages is trivial, since the DER encoding defines the length of the signature itself, so I'll get on it.

[chris-belcher]

It can be noted that this can be a backward-compatible change. Any signatures which the taker doesn't recognize it will just drop and carry on. So you can send padding as a DER encoded signature of all zeros and it will work.

[AdamISZ]

Yes, I was having similar musings yesterday on IRC.I convinced myself that we can't do it because the sig is pulled in as chunks[1] after separating on whitespace, and base64 encoded ofc. We could add extra whitespace after the b64 encoded message, because we split on whitespace anyway, but that's no good: the sig is b64 decoded and decrypted and then passed to verify_tx_input, which will fail. So that means makers sending padded sigs (the padding would have to be inside the b64 encoding to be of anti-snoop value) will not work.

I maybe misunderstood what you said: "So you can send padding as a DER encoded signature of all zeros and it will work." - yes sigs would be dropped. I am wondering if you mean - send extra, invalid sigs? That works as obfuscation but does add big amounts of extra data to the messages. i.e. I presume you envisaging !sig !sig ... yes, it works, but a bit ugly.

For background, iirc almost all sigs have length byte 45 or 44 (maybe 46 and 43, not sure of frequency but i think only 2 lengths are common). This is a pretty small info leakage, but anyway, definitely worth doing.

[AdamISZ]

Oh, and the other thing I was thinking was that !ioauth is a thornier problem: sending the list of utxos leaks the number of input utxos a particular maker is contributing, to an eavesdropper that is able to log traffic by participant. I couldn't think of anything better than the (again, fairly) ugly approach of adding a random number of utxos to the list which are invalid. This also might well be backwards-incompatible.

But apart from !ioauth and !sig I don't think anything else leaks info based only on length.

Also I forgot to mention in this thread why this is an issue: libsodium uses a stream cipher (salsa), not a block cipher, so message length is leaked unless you take active steps to prevent it (to be strictly accurate, block ciphers can do that too, just they already have padding to block length built in).