Hi everyone,

I'm working on a hardware wallet for Bitcoin and I am trying to understand the way subliminal channels work for ECDSA signatures and how to prove to our users that we are not leaking their private keys.

I can't say I understand all of the math involved, but here's what I gathered (mostly from http://www.emsec.rub.de/media/crypto/attachments/files/2011/03/subliminal_channels.pdf ).

1. There is a broadband subliminal channel that works by choosing a non-random k value in the signature generation algorithm. However, this method requires that the recipient know the private key (and that's exactly what it would be meant to leak). So I think this one is ruled out.

2. There are two other narrowband channels (1 bit) - not much to worry about since they would take 256 signatures to fully reveal the private key.

3. There is a third narrowband channel that can transmit messages of up to 140 bits or so without requiring the receiver to know the private key, so this one could be used to leak the private key. However, if I understand it correctly, recovering the message would require significant effort on the receiver. According to this paper https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CDsQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.11.122%26rep%3Drep1%26type%3Dpdf&ei=_wTBUbaVOM3htQbOzYHoBg&usg=AFQjCNGSNhhwAwY7UULuPYTUUtk7yImtTg , at least 2.71*2^x input values must be tried in order to recover x bits of data. This would make it completely useless for sending a 256-bit private key, provided that the key is truly random. It would be similar to bruteforcing the private key.

So could anyone with a better understanding of ECDSA let me know if I'm missing something? If the private key is random (and I can ensure that by allowing the user to provide random input into the generation process), should my users worry about the implementation leaking their private keys through any of the means above?

Thank you,
Razvan