Breaking Monero Episode 08: Timing attacks

This is a transcript of Breaking Monero series Episode 08: Timing attacks

Published under CC-BY RyoRU

Justin: [00:00:00] Hello and welcome back to breaking Monero. The series is where we critically look at some of Moneros privacy and security limitations in order to inform people about better what these are. We have Sarang back on today also. We’re happy to have you today. Today we’re talking about timing attacks. Now, timing attacks are another very nuanced topic. There’s things that sort of arent get right. So we want to help explain the situation a little bit better for people so that they have a better understanding about what information can be learned about them and then and with some key takeaways that users can use and consider as they’re spending transactions so Sarang can you start us off about some of the considerations about when you are running a node what the sort of limitations are for individuals.

Sarang: [00:00:56] Sure so I mean the idea behind running a node is that you may be relaying transactions from other nodes onto the network which of course is how the network basically learns about transactions. But you yourself may be constructing transactions and sending them yourselves. So timing about when your node is active for example when it is accepting incoming connections and making outgoing connections to other nodes may reveal a little bit of information about the transaction structure. So for example if I have node that’s running 24/7 and has a whole bunch of transactions passing through it it may be more difficult for an adversary to determine which of those transactions I’m simply relaying on and which actually originated from me. But of course if I only come online every so often for a brief period of time send out a transaction or two and then go back offline. That may be an indication to that adversary that the transactions that are being sent out or in fact originated by me. So the timing about when a node is running is something to consider and of course we know that in general the more nodes that are online relay transactions that increases the security of the network anyway.

Justin: [00:01:59] So do you think it’s fair to say that if an adversary was trying to have a high level of knowledge over the network they would try and prioritize or they would look first at nodes that they’ve recently connected to and then have disconnected over a short period of time.

Sarang: [00:02:15] It’s difficult to say what methods an adversary might use but that’s a pretty strong one. So in general if you’re going to be using a node it’s probably best to be running it all the time and allow a lot of transactions to kind of filter through and be relayed in order to ensure that your own transactions are as hidden as possible within that crowd.

Justin: [00:02:33] And it’s worth noting too that this isn’t really a Monero specific recommendation for other security and privacy software like Tor and ITP. They generally recommend that users run the software all the time even if you’re not using it so you should not just run ITP router only when you’re routing on the ITP network. Likewise you should not run a manual and not only if you want to sync and broadcast transactions, you should ideally try run at the time. OK so what about when you’re sitting in with remote nodes Sarang?

Sarang: [00:03:07] Well we were talking a bit about this earlier before the recording about how the structure a little bit different of course. We talked about remote nodes in some of the limitations in the trust that you’re implicitly placing in a remote node and you can act for example with a mobile device that doesn’t have the capability to run one on its own. So one thing to keep in mind is that you know especially if you’re running on say a mobile device whose IP and a parent geo location is going to be changing over time you know if you connect to a remote node for example you request blocks that you haven’t seen yet. So for example if I run Monero wallet on my phone for example that’s connecting to some open remote node that node see these that I request a certain number of blocks and then I maybe go offline and stop connecting to it because I’m done for a while and then from a different location a different IP. I appear to perhaps be a different identity. I might connect to that same remote node again and start requesting the next set of blocks. So if the remote notice keeping track of which entities are requesting which sets of blocks the node might make for your inferences about the if I am in fact that same entity even though you know my phone is connecting from a different IP.

Justin: [00:04:15] Interesting. Thank you Sarang. And so move on a little bit. We get in sort of summarise like when people submit transactions and what people can really do to mitigate this information and there’s a number of basic strategies that we have outlined and they each come with their own drawbacks unfortunately. So you can say that users can send them randomly. You should literally pick a random time over a day. But then maybe you would choose an off peak time with Monero network and maybe the only people sending transactions during that time are usually those that are saying them according to a random parameter. Or perhaps if you set them under certain times when more people are likely to use them it could be a more predictable behavior that you sort of try and observe. So ultimately it’s hard to say which one is really the best. Because you can really develop a heuristic for both of these and we don’t really know which one is more powerful but just know that there’s sort of limitations with both these two different types of strategies and how people approach them and we can look to sort of the zcash turnstyle process to see how they have sought to limit some of the timing to attack metadata as people send funds from a shielded sprout address to a transparent address to a shielded sampling address. That you with their sort of turnstile process. So you try and fit in with the rest of the crowd in a way it was sort of like an interactive process for try and make sure many people are doing it at the same time. And that’s the main point of that is actually to help with timing attacks to help make it so that it’s not obvious that only one entity is transacted over a certain period of time.

Justin: [00:06:06] So, Sarang what question a lot of people have with Monero wallets and it’s kind of a you user experience drawback is that we limit people to have at least 10 confirmations for their transactions before they’re able to send another one. Why does Monero do this. What were the real benefits from this?

Sarang: [00:06:25] Well you know the idea one of the ideas behind this is that you know we’ve talked before kind of way back when we talked a bit about forks in the network that the network in the chain will tend to kind of fork itself in very small and kind of limited ways just because different miners may come up with different blocks around the same time and kind of create these little teeny little tributary style forks. But eventually those kind of just get rolled into one solid chain. So you know on one hand you know we want to make sure that users have enough confirmations to ensure that the outputs that they’re sending you know are on are on the main chain. And how many blocks does that take. Well you know statistically we know that the more blocks you wait the more likely it is that you are in fact on the main chain. And you know the longest kind of reorganizations of chains that we’ve seen are maybe on the order of 20 blocks. These are extremely rare. It’s more likely that you know the number we set something like 10 blocks ensures that you know you’re very very likely on the main chain without kind of degrading the user experience too much. And of course you talk about you know other benefits that we get to this as well .

Justin: [00:07:28] You’re on top of that too. Like you don’t want to generate transactions with decoys that were generated at a chain that doesn’t exist anymore. That’s unfortunate because either the transaction might not be properly verified. Actually that’s a good question Sarang with a transaction just not be verified or would it be verified with information that would be false.

Sarang: [00:07:49] We would have to be with information that is relative to that nodes knowledge of the chain.

Justin: [00:07:55] OK. So interest. OK. So you couldn’t send a transaction using a decoy in one chain and then used it to be included on another.

Sarang: [00:08:05] And again like this is this is one of the things that you know eventually a small tributary forks ..wants..go away eventually as you know a solid single main longer chain is established over time. So yeah you know in general it’s good. It’s good to wait. You know it’s it’s not really a consensus thing it’s a wallet thing but it’s there for good reason. You know it’s also worth noting too that you know the way we talked earlier about the way that we select decoys and there’s all sorts of considerations with that some of which are very subtle but it’s worth noting that you know the decoy selection algorithm that in some sense takes some kinds of timing into account also does in fact account for this .

Sarang: [00:08:40] So if you’re doing the default behavior you know in that sense the output selection is taking it into account.

Justin: [00:08:49] Yeah I think so to summarize the sort of the 10 confirmation window for people is to make sure that their transactions get broadcast on the correct chain. And then there’s they’re seen it actually happens and then it’s also to say that. The selection it’s to account for latency issues with the selection algorithm too where not everyone would necessarily see everything except for a certain period of time. So we can make sure that the whole network really has visibility over this transaction before you just start to try and send. Does that does that summarize it pretty well?

Sarang: [00:09:25] To make a long story longer. Sure.

Justin: [00:09:28] Perfect. All right. So what about some of the like. The connections between IP addresses and talking. We’re gonna have a separate episode entirely on IP addresses go much more detail there. But what about the persons that are related specifically to like the incremental advantage a timing can provide for an adversary.

Sarang: [00:09:50] Well you know I mean so an adversary who is looking for it and connecting to you and is aware of your IP address of course we know there’s some things involving geo location of IP addresses. There’s also information about timing caused by you know what. What transactions are coming out of that what time is that node active. You can make a lot of inferences based on activity for example based on things like time zone which can give you inferences about location. So there’s there’s a lot of like little pieces of metadata that are kind of floating around there. You know if if for example you can make an inference about a user’s time zone you might make an inference about you know when they’re likely to be asleep and therefore probably not active sending any transactions on the network. You know all of this gives us some little heuristic information about when you see transactions what you know about when that user is likely to send transactions at their own. And again this goes back to the whole idea of can I infer that a transaction that I see coming out of a node is just being relayed on from somebody else. Or in fact originated from that node. Of course the idea ideally is that you don’t want that to be determinable. So you want to ensure that all transactions appear like they are equally likely to come from you or just from someone else I’m sure that you know if you think about it hard enough you can come up with a whole lot of different heuristics that an adversary might try to use based on your IP and different forms of timing time zone and location and all of that.

Justin: [00:11:10] Are there any last comments you want to add on timing metadata before we move on to this sort of actionable information for people?

Sarang: [00:11:17] Know just just that you know some of the things are fairly specific to Monero. For example the way that we have to select decoys and therefore have to account for certain timing things you know a lot of these other things are a lot more general to kind of the way that networks are generally set up the way that routing happens. You know the way that the way that you in general transactions are broadcast in a way that might not be specific to Monero but might be common to other assets like Bitcoin and litecoin for example. But just that you know in general the goal with a lot of these things is to ensure that you are basically hidden in a crowd and don’t stand out and what you’re doing. And of course there’s different kind of mitigations and solutions that folks are trying to come up with to mitigate this. For example kind of like network level solutions like Tor and ITP and other things you might have heard of two different kinds of routing solutions. Now there’s different proposals on how to change the way that your node connects to and routes transactions in order to make sure that an adversary observing the whole network is less likely to be able to determine any information. So you know like many things and like many things involving network theory there’s a lot of different layers that we can act at. But you know Monero as always tries very hard to apply and iterated layered approach to its privacy. And we continue to iterate on that’s kind of at the routing and network layer as well.

Sarang: [00:12:31] I’ll be it may be more slowly than we’d like yeah.

Justin: [00:12:34] Really is it some sort of topic these conversations because it’s not we don’t just need to learn from Monero history it really can we can really pull from any peer network to learn more. So for this actionable information we have some few basic steps for people. The first and most obvious one is if you can’t run your own full node and when you’re running it keep it running 24/7 right. Make sure it’s always connected don’t only run it and sync it when you’re trying to send transactions. You should ideally be contributing all the time. You’re constantly sending information back and forth you’re sending transactions on to other nodes that you don’t even send. And as a result it just helps you ultimately with your or your security but also one thing that sort of that I think is pretty interesting is if you run an open node sort of like a Monero world style node you use that other people connect to your node for in order to send transactions through you, that can actually help your privacy by making it so that many other people are sending transactions through your node not just you. So in addition to all the other normal propagation data that’s being sent from your node you’re also getting brand new information from other people. That’s coming from your node for the first time. So if an adversary is observing your node they might think they will struggle to differentiate transactions that you send out compared to transactions that other people sent out so I think that’s pretty interesting. Yeah. What do you think about sort of like transaction delay?

Sarang: [00:14:16] Yeah I mean I think that that’s something that can help. I mean it can be helpful as well. Right. some some people and other projects as well might might advocate the idea of delaying when a transaction is sent out relative to when the transaction is actually constructed. we’re made on your device and that could be helpful. that’s if any anything that you can do to ensure that any patterns in your transaction behavior are in some sense kind of randomized is generally a good thing you know to what extent you should do that randomization over what time period. You know I would say that that’s kind of up for debate and might depend on other factors involving patterns in network activity.

Sarang: [00:14:52] But in general if you can do it it’s probably it’s probably worth your while.

Justin: [00:14:58] So Sarang ultimately we spent some time talking about timing attacks. Is this really a consideration that most people really need to concern themselves with?

Sarang: [00:15:07] You know like a lot of other things I think it really depends on your particular threats and risk model. You know a lot of it might depend on whether or not you’re operating through VPN or other kinds of anonymity networks whether or not you are concerned about adversaries observing your network activity in particular or kind of the global network activity across the entire Monero network. It could have to do with how well connected you happen to be to the Internet and to and to other peers on the network which might depend on the level of trust you placed in your ISP or a kind of Internet backbone around you. I know that for most people what we’re what we try to do and I guess what we’re trying to do going forward is ensure that the way that we develop the way that the software routes connect to other nodes on the network and even other things like network level network layer solutions ideally try to kind of make some of this transparent to the user. You know I would say that it’s probably not something that a lot of people think about very often and frankly a lot of people are probably privileged enough to not have to maybe worry about this for their particular use cases but this is something that does concern you then some of these mitigations are something that you probably want to consider when you’re using Monero or for that matter just doing general network connectivity at all.

Justin: [00:16:23] All right. Any final comments you want to have on this topic?

Sarang: [00:16:27] It’s it’s very it’s very subtle and for every mitigation that you come up with for some kind of timing analysis there’s probably another heuristic that’s a very very determined or different adversary might use and that’s not to say that you should kind of come up with kind of fall into an analysis paralysis trap of saying well there will always be new heuristics so why use this at all. As always we. This is kind of a cat and mouse game for which we try to iterate maybe sometimes more slowly than we’d like but we do still iterate and improve on it.

Justin: [00:16:58] OK thank you Sarang. Thanks again for everyone who watched. This has been “Breaking Monero”. We will catch you next time.