<div dir="ltr">Ivan, according to <a href="https://www.torproject.org/docs/hidden-services.html.en">https://www.torproject.org/docs/hidden-services.html.en</a> (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?<div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div>Razvan</div><div><br></div><div>--</div><div>Razvan Dragomirescu</div><div>Chief Technology Officer</div><div>Cayenne Graphics SRL</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 17, 2015 at 10:13 PM, Ivan Markin <span dir="ltr"><<a href="mailto:twim@riseup.net" target="_blank">twim@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Razvan Dragomirescu:<br>
<span class="">> Thank you Ivan, I've taken a look but as far as I understand your project<br>
> only signs the HiddenService descriptors from an OpenPGP card. It still<br>
> requires each backend instance to have its own copy of the key (where it<br>
> can be read by an attacker). My goal is to have the HS private key<br>
> exclusively inside the smartcard and only sign/decrypt with it when needed<br>
</span>> but never reveal it.An attacker should not be able to steal the key and<br>
<span class="">> host his own HS at the same address - the address would be effectively tied<br>
> to the smartcard - whoever owns the smartcard can sign HS descriptors and<br>
> decrypt traffic with it, so he or she is the owner of the service.<br>
<br>
</span>Yes, it still requires to have plain keys for decryption of traffic on<br>
backend instances, sure. But you're not right about key "stealing"<br>
(copying). An address of a HS is calculated from key which is signing<br>
descriptors. This key resides on a smartcard. It's already<br>
"the-address-would-be-effectively-tied-to-the-smartcard" situation there.<br>
<br>
I do not see any reason to decrypt traffic on a smartcard; in case if an<br>
attacker can copy your backend key there is no need to decrypt anything<br>
- they already have an access to the content on your instance. Also<br>
backend instances' keys are disposable - you can change them seamlessly.<br>
<br>
P.S. Notice about bandwidth issue when you're decrypting all of the<br>
traffic on a smartcard (half-duplex, etc.).<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Ivan Markin<br>
/"\<br>
\ /       ASCII Ribbon Campaign<br>
 X    against HTML email & Microsoft<br>
/ \  attachments! <a href="http://arc.pasp.de/" rel="noreferrer" target="_blank">http://arc.pasp.de/</a><br>
<br>
</div></div><br>_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br></blockquote></div><br></div>