Quote from: Falkvinge on February 21, 2014, 04:52:56 PM

Hmm, good point. However, in the general case, a display cycling some 1-8 QR codes must surely be sufficient? I just aimed my phone camera at this QR code on Wikipedia, with some 1800 bytes, and it nailed it without blinking. I can't tell how many percent of transactions would be smaller than 6-7 kilobytes, but I imagine it would be the overwhelming majority.

So while there may be cases where this mode of communication is not available, is that a reason to exclude it from the 95%-98% of typical cases?

The problem is, when the time that you fall outside that 95%, you have to resort to another solution (such as USBs), which compromises the whole thing. We really need 100% in order to be useful.

Quote from: Falkvinge on February 21, 2014, 04:52:56 PM

Is that really the case? The communication would be one-way, there's no need for ACKs as the receiving computer can read the sending screen until all codes have been read. No need for a two-way protocol. There's an operator there, after all, who is alerted to when the data transfer is complete in some way.

It's bi-directional. We need to transfer transaction data to the online computer, sign, then transfer the signatures off (though right now Armory expects the whole tx to be transferred off, but it wouldn't be difficult to change that). Nonetheless, if you have a lot of inputs on the signed transaction, transferring 20+ signatures will require multiple QR codes. We really need bi-directional video. And if it's two computers with two webcams, it can get confusing quickly, and lots of messy wires. Again, it's not that it's not doable, it's that it's not a clean solution.

On the other hand, having two laptops facing each other might actually work, since the cameras are built-in.

Quote from: Falkvinge on February 21, 2014, 04:52:56 PM

Quote

However, we have more resources on our team now... we may be able to prioritize it. Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure. But it's not ready yet.

An audio channel is a clear improvement over a USB key, but still hijackable as a side channel in the dire case malware has found its way onto the computers: all operating systems I know of allow for multiplexing several simultaneous applications to/from audio. However, in the same vein, webcam access and screen real estate is exclusive to one application, giving an advantage to the operator knowing that Armory has exclusive control of the communications channel?

I would argue that audio is not really hijackable -- there is basically zilch remote-code execution potential, assuming the offline computer is not compromised. We have to make that assumption because all bets are off, otherwise. There's a countless number of ways to get the keys off the offline computer if you assume arbitrary code execution there.

On the other hand, assuming that only the online computer is compromised, there is nothing you can send over an audio channel that would induce code execution -- except for what Armory implements (or if you have some kind of voice recognition software running...?!). Armory can make that band very narrow, and it will require direct audio cable connection, not just being in the same room. We think it's an awesome solution, and will work well with mobile phones as well...

But it might be a while before we get that implemented. We'll see how our priorities look after 0.91-beta is released.