MoneroResearch.info |
Resource type: Journal Article DOI: 10.1109/ACCESS.2021.3060285 BibTeX citation key: Guo2021 View all bibliographic details |
Categories: Monero-focused Creators: Guo, Shi, Xu, Yin Collection: IEEE Access |
Views: 145/3461
|
Attachments MRCC_A_Practical_Covert_Channel_Over_Monero_With_Provable_Security.pdf [27/1446] | URLs https://ieeexplore ... t/document/9356584 |
Abstract |
Covert channels are designed to protect the communication relationship of the sender and receiver. Traditional covert channels have become insecure due to the continuous improvement of traffic analysis techniques. In this context, there is an urgent need to identify new approaches for covert channels. Blockchain is an emerging technique with characteristics of user anonymity, a flooding propagation mechanism, and tamper resistance, which make it a compelling platform for covert channels. Previous approaches applied Bitcoin as the underlying blockchain, and its pseudoanonymity may expose the communication relationship. Moreover, the reliance of these approaches on prenegotiated labels to identify transactions containing covert messages further reduced their concealment. In this work, we present a practical and secure covert channel over Monero. Compared to Bitcoin, Monero's full anonymity efficiently protects the relationship between the sender and receiver. Moreover, no labels are employed to identify special transactions. The receiver filters and extracts the covert message using his private key. In this study, we make a complete assessment of the robustness, reliability, and anti-traceability of our protocol, as these properties are regarded as desirable for a covert channel. We also formalize the definition of security for covert channels through a transaction distinguishing experiment. A rigorous proof shows that our protocol meets this definition and is secure to use. Finally, we make a detailed comparison between our protocol and the existing blockchain-based covert channels.
|
Notes |
This provides 1 bit per ring member per input. For a Monero transaction with two inputs, post the upcoming hardfork, this provides 32 bits per TX, or 4 bytes. It'd take 8 transactions to scale this to a single hash. While you can use multiple bits per ring member, it'd require notable deviations from the randomly selected distribution. It'd be +- ~792 outputs, from the index intended to be selected, just to get 32-bytes for such a 2-input transaction (which also passes requirements on the sender's keys, though those can be bypassed by bruteforcing a salt).
With Seraphis, +- 8 outputs (on average) would allow finding a given 5 bit combination with a brute force being just 16 salts (on average) for the actual key to have the necessary pattern. This would be usable for 80-bytes per input, if it has 128 members in its ring. Added by: kayabaNerve Last edited by: kayabaNerve |