Razvan Dragomirescu:
Ivan, according to https://www.torproject.org/docs/hidden-services.html.en (maybe I misunderstood it), at Step 4, the client sends an _encrypted_ packet to the hidden service, so the hidden service needs to be able to decrypt that packet. So the key on the card needs to be used both for signing the HS registration and for decrypting the packets during the initial handshake, isn't this correct?
Not exactly. The trick is that keys are not the same. For more details have a look at the specifications [1]. There is a "permanent key" ("holds the name", signs descriptors) and an "onion key" [2] for each Introduction Point to communicate with the HS. So the "nameholder" key ("permanent") is used only for signing descriptor with a list of IPs and corresponding keys.
As far as I could tell, there is no way to tell Tor to use a smartcard in any phase of the protocol, your OnionBalance tool simply handles the registration by itself (outside of Tor).
Yes, there is no support for SCs in little-t-tor itself. What OB is doing is just a combining some IPs (from backend instances) into frontend instance descriptor, signing it and then publishing it via tor.
btw, OnionBalace is not my project [3].
Regarding bandwidth, this is for an Internet of Things project, there's very little data going back and forth, I only plan to use the Tor network because it's a very good way of establishing point to point circuits in a decentralized manner. The alternative would be to use something like PubNub or Amazon's new IoT service, but those would depend on PubNub/Amazon.
As I said before it may not fit your purpose. :) I still don't think that decrypting via SC is necessary. If somebody already knows your backend keys then certainly they know any of your data on this machine. Maybe I missed something.
[1] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n63 [2] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n364 [3] https://github.com/donnchac/onionbalance