13

Are there any security concerns with sharing a Monero daemon with a roommate to send or receive transactions?

If we each person has their own wallet, encrypted with a very strong password what are the risks of sharing the same computer and bitmonerod program?

  • I think he would be able to make it appear like he sent you Monero when he in fact didn't, but I'm not sure. – PyRulez Aug 15 '16 at 1:08
12

You are asking two different things here:

  • what are the risks in using the same daemon

They're typically small, and mostly either privacy leaks or denial of service.

Obviously, whoever runs the daemon may either withhold new blocks, and try to inject fake blocks. The wallet will not check PoW, etc. A daemon who knows the user's standard address could make a transaction to that address, not relay it to the network as a whole, mine it, and make it seem the user was paid.

Privacy leaks exist, and most of them can be plugged by not using --trusted-daemon (however, if you're connecting to a node on the local machine, the daemon is assumed trusted. If you're on the same machine, you have bigger problems anyway, see below).

First, when sending a transaction, the wallet will request random outputs from the daemon to use in a ring signature. This means that, when the wallet sends the transaction, the daemon will see the outputs it sent earlier, plus another one. That must be the real output, which the wallet already knew about. This is fixed in the rct branch: the wallet then decides which outputs to get, and include its own there, so the daemon cannot tell which is which.

When refreshing the wallet, a block containing one more more outputs for that wallet will cause a request to the daemon for more information about this transaction. This tells the daemon that this transaction has at least one outout for the wallet. This is fixed in the rct banch, where this information is sent with all blocks in the first place, so the daemon cannot tell which transaction pay the wallet.

When sending a transaction, the wallet will ask the daemon for the number of outputs of given size exist on the blockchain, to know what amounts are compatible with the requested mixin. This tells the daemon the set of amounts for which the wallet has one more more outputs. If using an untrusted daemon, this will be skipped (the wallet will ask for all outputs, not just the ones it has; it's fairly slow, but privacy preserving).

In any case, the daemon never gets anywhere the wallet's private keys, whether spend or view.

Last, if the wallet connects to an untrusted daemon, then the daemon may try to attack the wallet through an buffer overflow or other bug. Hopefully there aren't any, but then most software hopes so too.

  • what are the risks in using the same machine

That's a lot riskier. Hardware access to the machine means you can install hardware keyloggers. Assuming you each use different accounts, a kernel exploit could allow software keyloggers too. Then you get passwords to the account and the wallet (the former being not even needed if you have a kernel exploit).

8

There's really no secret data managed by bitmonerod. The privacy risk is that someone examining the logs of the daemon could see which transactions your wallets have sent.

5

The risk is minimal, and the Monero software architecture lends itself towards having a single daemon in a household or office. If you're running a reasonably current version (eg. compiling from the git repository) then you'll see the --trusted-daemon option, which is off by default. This obscures the data you receive from the daemon to minimise the risk of it knowing, for instance, which outputs used in a ring signature are yours.

  • Is simple wallet sort of like a light client? – PyRulez Aug 15 '16 at 12:04
  • It can be used as a light client if you use a remote node. – dEBRUYNE Aug 15 '16 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.