Bitcoin Forum

Bounty:  Me (etotheipi) is offering 20 BTC.  Raize is offering an additional 5 BTC.  

Casascius offered a bet of 20 BTC that it can't be done.   But that requires someone to be willing to pay him 20 BTC if it's not done.  That's a bit steep for me, since I'm not convinced it is doable, but I was willing to give 20 BTC to someone who gave me usable code.

So, in my quest to improve offline wallets, I'd like to finally get started on my ultimate goal of using an audio link between two devices to get the almost-100%-secure link for moving transaction data.  I have bought double-ended audio cables and tested this between online and offline computer, and it does appear to work - I can play music on one computer and record it on the other.  Given that these are analog streams not normally intended for transmitting executable data, I think this is a perfect "side-channel" to exploit for communicating securely.  Also because audio hardware is widely available and supported on all modern OS & HW.

I expect that this would be "easiest" by downloading and adapting some kind of modem firmware, and using it to handle the communication.  My understanding is that the modem software is capable of testing the line quality and setting the communication rate and error correction automatically.  The solution doesn't have to be modem-based, but it should be able to handle 5 MB in under 15 minutes.  The vast majoriy of transfers will be on the order of a few kB, but I don't want a user who actually ends up with 5 MB to transfer to have to wait an hour to do it.

In order to get the bounty, I want python code or something that can be invoked from python (C++ can be SWIG'd in), which will give me the ability to pass data over the audio channel.    The code should have some kind of initialization/handshake routine, and then only allow for sending and receipt of ASCII data.  I basically want it to behave just like a serial port.  Remote code execution on a not-yet-compromised-offline computer should be pretty much nil in this environment.  This software would be set in "listening" mode on the offline side, and simply receive and return (to python) the string that was received.  The calling application would then parse string, request a signature from the user, and then send the signatures back over the audio link (yes, I know I need a second cable for this).

Any person wishing to collect the bounty must also be willing to assign me all rights to use it in the Armory project, free of charge, etc.  This is something I want to eventually integrate into Armory and I'm paying for it because I want to maintain full rights over my own project.

Discussion and improvements are certainly welcome, and partial solutions are also eligible for part of the bounty.

I'll add 5 BTC to this bounty for either modem or audio. Would be nice to see both options, however. It doesn't have to be open source, I just want to see it in Armory.

Have you also considered QR code support (you are welcome to use the CIYAM Safe scripts at no cost)?

You'll know why I passed up QR code the first time you have to deal with transferring 4 MB between systems.   I really wanted to make it work,  but it only work for 95% of transactions without starting to get complicated, and also I didn't like the idea of multiple webcams and screens.  I'm envisioning a mess of wires and a confused user trying to figure out which webcam is supposed to be pointed at which monitor.  By all means,  it should be an excellent solution most of the time,  for most users, but I didn't want to make that the core transfer mechanism for "regular" users.



By the way,  the idea is to use the audio link, no matter what.  I was simply suggesting that software that used to be used for modems might save someone a lot of work,  since they were designed to do this kind of communication over an audio channel.  Building software from scratch would work,  but probably significantly more work. I didn't mean actually creating a solution using physical modems :-)

Thanks for contributing to the bounty! 

Ouch - yes that would be real pain (am only transferring a 1000 or so bytes at the most with my system).


Understood - it is more of a "duct tape" kind of solution (I did play in a few rock bands). :)

Ahh, ok. It seemed to me that a 56k modem connection couldn't handle 5 meg that fast anyway, but maybe if you also ran some sort of 7-zip-like compression API.

ZMODEM rates for a modem connection do about 420K per minute. This might be a little tougher for someone to accomplish without having to rewrite a modem library, though you're correct in assuming that the clarity should be better than a typical modem connection so there is potential for someone to write something as a completely new communications channel.

You'd think I would've figured this out by now... you're right it would be about 10-15 minutes at that speed.  It should be easy to wrap the transfer with compression, and if it takes 10 min for that once-in-a-blue-moon transfer, oh well. 

There is some code on this here: http://awesomegeekblog.blogspot.com/2009/04/file-transfer-over-sound-card.html

EDIT:
Ahh, and a github repo here:
https://github.com/vlofgren/file-transfer-over-soundcard/

From my test of sending music over the audio link and recording it, I thought "hey, I just moved data... I wonder if I can re-encode my data as an audio file and have the standard .wav players do it for me...?"  Obviously, would need a bit of error correction, but playing audio from python is stupid simple, and I'm sure recording is, too.  It would certainly be minimalistic (using the pyaudio libraries already available rather than porting some ancient modem code...)

I thought of it because that project you linked me has a "generate" function which "turns a binary file into raw wave data."  Seems like I could play that wave in a loop until the receiving system declares that it has it.  Unfortunately, I don't think that simplistic solution is fast enough.  If all Bitcoin transactions were 250 bytes, it would be awesome (don't even need the audio cable, just put the speaker next to the mic).  But it looks like we're only talking about 100s of bits per sec, instead of 1000s, and a single 50 kB transaction would take quite a while.

@CIYAM:  just FYI -- the 4 MB comes from the fact that I'm not just transferring the transaction to be signed.  I'm also sending over every supporting transaction that supplies inputs to the transaction being signed.  This is because Satoshi inconveniently didn't include the input value in the TxIn serialization or include it the signing algorithm, and the tx doesn't explicitly specify fee.  So, the offline system has no way to compute the fee for sure without seeing the full transactions pointed to by the OutPoints in the TxIns.  Although it seems like a small hole, it's one that could cause a lot of pain, so I had to "patch" it this way.

Then I had a user complain that sending his tx was failing (for another reason), and when he sent it to me I saw it had 483 inputs.  It was something like 250 kB, with 3.5 MB of supporting transactions.  I'd say it's extreme, but there's actually quite a few people (especially SD players) that have tons of small inputs that will have to be combined if they try to clear out their wallet...

i think this would be interesting to use steganography to put the data into a piece of actual music as some kind of watermark, rather than just play data that sounds like noise.

not that that would have much practical application.

If it were me, I would implement this as RS232 serial comms, and then try to go about seeing if someone wanted to write a generic audio-to-serial device driver that emulated a serial port at the kernel level.  Then the separation of duties in the code is appropriate, and the audio overhead is totally optional.

Having worked with modems extensively, and currently running a business that still supports 1200 baud dialup modems to this day (I wrote 100% of the code for that) I think this is going to be super difficult to get working right and reliably, with decent error detection and correction robust enough to give satisfactory results in varying real-world conditions.

The most recent generation (post-1990) of dialup modems will do things like periodically sweep the entire frequency range of a telephone connection to find out what portions of the audio spectrum are available on a particular call, and cram all of the data in the usable spectrum.  That's the result of years of the innovation of multiple modem companies competing to make the fastest modem - something you're not going to be able to implement starting from scratch.

It's like trying to reinvent the entire 1980's and early 90's worth of modem technology all over again, but with unprecedented new constraints: audio hardware with wide signal ranges built to a loose standard, user-settable volume and equalizer controls, and audio jacks which were never meant to be cross-connected.  And, for it to all be re-invented by one guy, rather than a whole industry.

Audio inputs on computers are rarely meant to be directly connected to the audio outputs of other computers.  In most cases, the audio outputs are at a level for driving headphones, and this level will grossly overdrive any computer audio input, given that a headphone jack is meant to provide power to a pair of headphones, but inputs are meant to talk to microphones or line-level inputs (signals that are weaker by orders of magnitude than headphone output).  The receiver will hear nothing but clipped static.  A user can sort of get away with it for audio applications by turning the output volume down really low, but not if you're asking the user to do something that makes them unable to hear the signal, like not hook up speakers, and that's assuming the user is qualified to know what's the appropriate sound level for a data signal meant to be decoded by a computer.

Then you have to deal with things like ground loops, and crappy unshielded sound cards that pick up all kinds of unwanted noise from CPU that limit your bandwidth to nowhere even approaching 56Kbits/sec on random unpredictable occasions and... suddenly, this project has become more complicated than the whole of Armory itself!

By the time you start to write the troubleshooting guide for this, and try to teach your user how to figure out what line level his inputs and outputs are so his two machines can talk, you'll reluctantly fold this audio idea and go with something like RS232.

tl;dr: I'll bet you 20 BTC this plain isn't going to work even remotely as well as RS232 will - 20BTC you can add to the bounty just in case it does!

Isn't 80% of your criticism solved by using modem firmware/software to handle all the transmission/spectrum issues?  I know it's complicated, and I know that it was all figured out in order to achieve 56Kbps, so that's why my original post suggested using old modem stuff.  Perhaps I underestimated the effort level of starting from scratch compared to the modem option.  But I think you're understating the fact that an audio connection like this should be an almost identical environment to what modems were designed for and modems did solve this problem.

As for the connectors... What about an attenuating cable (http://www.radioshack.com/product/index.jsp?productId=2103841)?  It seems they're designed for this...   

If you can get a hold of some modem software/firmware source code that can be retrofitted to work on audio signals from the wave audio feed of your choice instead of the hardware it was designed to talk to, I will consider this remarkable in and of itself.  Most of those are kept as proprietary as possible.

You won't get 56kbps by imitating a modem, since you can't get 56kbps peer-to-peer even with a real modem.  Achieving 56kbps is done by very carefully exploiting properties of the telephone lines they'd be used on.  For starters, achieving 56kbps is possible only under the most ideal of conditions, and in one direction only: from the ISP to the customer, and the ISP must have special head-end equipment that outputs the audio data in digital form directly onto a T1 or ISDN or similar line in order for it to even be possible, so as to cut out the loss going from analog to digital.

The modems themselves can push no greater than 33.6kbps to another modem, no matter how pure the connection.  The protocol simply doesn't allow for it.  And this is in the best case.

The attenuating cable you've mentioned as an example would be a nightmare.  There's no way to know how much attenuation is the right amount.  And just by looking at the cable, I can see a clear problem: it's meant for mono voice recording.  Rather than having a 3-point connector (ground, right audio, left audio), it has a two-point connector (ground and signal).  Plug this baby into a stereo jack, and you literally short the right channel to ground (compare it with a normal headphone jack and you'll see why - the right channel is the middle connection point, and the ground sleeve is shorter).  Your typical user is never going to know this without being taught.

Wasn't the original purpose of this idea to make it convenient for the user?  If the user's got to go to Radio Shack to get an unusual cable to do this communication, then he ought to just pick up a null-modem serial cable, and know with 100% certainty it's going to work.

You might be able to get some ideas from ADTPro:

http://adtpro.sourceforge.net/

It's a program for getting downloaded software transferred to an Apple II. It has several transfer modes to choose from according to what peripherals the destination machine has available; one mode is to run an audio cable from the line-out jack on your newer computer to the cassette-in jack on a II, II+, or IIe (or cassette-out to line-in if you need to go the other way). You can probably get a higher data rate between two newer computers than what ADTPro can manage when one end of the link is being driven by a 1-MHz 6502, but it should be a start.

Well, I was planning to have links to all the correct stuff, and offer a real "offline bundle" for those that donate a certain amount (basically, sending them a set of the cables they need ready-to-go).

The problem with the serial cable is that if they do it wrong, their wallet is exposed to everyone.  They end up with less security than they thought they did, and the false sense of security be worse than not having had the option to begin with (they would've relied on something slightly less optimally secure, but with less user error).

On the other hand, if they do the audio wrong... no one gets to spend the offline coins.  Well, the authorized user will...eventually (even if they have to switch to some other method).  You point out that they could blow up hardware... okay that's a valid risk to take into account here.  

You are clearly more knowledgeable on this stuff than I am.  You seem to think this idea is DOA.  I didn't think it was so crazy, but that's why I put up what I thought was a fairly significant bounty (I'm sure some grad student out there would like the challenge and make some money).

@salfter:

Thanks for that link.  I'll look into it. 

You could use one of the protocols adapted for packet Ham Radio - there is already a lot of code and they are proven in noisy environments. Whoa I found this page and it would be sweet if we could encode Bitcoin transactions into this:

http://wb8nut.com/resources/olivia-1000-32.wav (http://wb8nut.com/resources/olivia-1000-32.wav)

(from WB8NUT's Digital Modes Information Page (http://wb8nut.com/digital/))

These are meant to fit in a very small bandwidth, though, of a few hundred - 1000 Hz. For short transactions it would probably work!!!

You probably wouldn't get more than about 8KHz in real life unless you were directly connected, forcing a max transfer rate of only a few kbits/sec. Directly connected would probably mean modem speeds depending on the ADC. Remember audio in PCs and phones rolls off at 22 kHz.


Not quite correct - remember it is still a digital codec on both sides, so no matter what you will still have the chance to introduce bugs. Even if the hacking now involves some serious sound equipment.

Yeah, looking at this more closely seems to indicate that RS-422 or RS-485 is going to be your best bet for very quick transfer rates. That means a null modem of some sort. And then they'd need to drop some serious cash on a USB converter. Come to think of it, I think the 56k modem option might actually end up being cheaper for them in the long run. Your risk then is possible unknown exploits in ZMODEM or XMODEM or KERMIT or whatever transfer mechanism you end up using. Like casascius says, maybe you could have the transfer mostly take place via null modem and then optionally do some sort of verification of it via audio?

Also, just because this stuff is decades old doesn't mean someone might not try to compromise it, your risk with custom code might actually end up being greater because it only has security through obscurity. I think I'd be willing to have a semi-airgapped connection via a modem though, because I could just only connect when I knew I wanted to send coin and feel relatively secure. I still like this idea, whatever you decide I'll honor the bounty I've posted.

Having done serial comms for a very long time I don't think this is a serious issue.  I think at one point you expressed the fear that someone could unknowingly leave a getty process running on their serial port, making it a conduit where someone on the other side of the "moat" who breaches the security on one end could use the serial connection to log into the machine.

I don't see this as a realistic risk - first off, it's easily detectable by your application, you should have no problem finding out if any other processes have your desired port open.  Second, assuming you didn't detect it, the constant error message traffic generated by the getty as it complains about all the data it sees would clearly disrupt the communication so bad that the operator would notice something was wrong right away, and third there's many other obstacles, not the least of which is having to hack the owner's password through an interface that is already very hardened against brute force hacking, never minding the fact it's already slow.


I have no doubt that someone could put together a proof of concept and get some data to go through their two computers' audio link.  But I think it's totally unrealistic to expect this to be reliable and more practical for even expert users as compared to RS232.  I think I am saving you lots of time and frustration by just saying don't mess with it.

Meh, but if you're going to go the cable route, why not just a USB to USB transfer cable (http://www.monoprice.com/products/product.asp?c_id=103&cp_id=10303&cs_id=1030305&p_id=8488&seq=1&format=2)? Then you get mega bandwidth and better compatibility than with serial.

I personally have my bet on NFC. :)

RS-422 and RS-485 are far superior to RS-232, but also far less common, and far more expensive.  The only drawback to RS232 is you get ground loop problems if you want to run it at high speed at a distance of hundreds or thousands of feet.  In practice, nobody does this.

Most computers either have RS232 built in, or it can be added trivially with USB.


$1.99
http://www.ebay.com/itm/New-USB-2-0-to-RS232-Serial-9-Pin-9P-DB9-Adapter-Converter-/281027829591?pt=US_Parallel_Serial_PS_2_Cables_Adapters&hash=item416e905f57


Realistically, ZMODEM/XMODEM/KERMIT aren't going to be used for this.  They are totally the wrong tool for the job.

Let me clarify that.  XMODEM is closest in function to what will probably get used.  XMODEM is a ridiculously simple protocol.  Here is the entire protocol: send a packet of up to 256 bytes with a simple addition checksum, and if the checksum didn't match, send CTRL-U to ask for a repeat, and if it the checksum matched, send CTRL-F to ask for the next packet.  End of file is signalled with CTRL-Z.  There is no room for vulnerability in that, it could be implemented directly in the application itself, hopefully using a hash algorithm as a checksum instead of simple addition.



A modem in the MOST LITERAL SENSE emulates a null modem cable while it is connected to another modem.  Think of it as a null modem cable that just happens to understand a command to pick up the phone and dial a call.

You can literally program a modem to blindly answer any incoming call and connect to whoever is on the other end, and then plug the modem into a serial device (e.g. a printer) that was meant for direct connection to a computer, not modem.  You can dial into it and start printing.  It's that simple.

That USB to USB transfer ultimately emulates either a network connection or a serial connection.  The computer thinks it's one or the other.

Oh, I've seen ones that need specific drivers on both sides for only doing file transfers, making it more complex than USB-network or USB-serial. Still more devices have USB ports than serial ports (sadly.)

The required rate would need to be about 0.33 Mbps. For comparison: a perfect stereo CD-quality audio over S/PDIF or TOSLINK is about 1.41 Mbps. For another comparison: standard serial ports support up to 115200 bps (0.11 Mbps).

So this isn't impossible, but will be somewhat hard to achieve.

Telephone modem code base will not be immediately useable because it is designed for 8-bit nonlinear quantization, sampled at 8 kHz and a single pair of wires for both directions.

The typical audio line-in/line-out ports would support 48kHz sampling, 16-bit linear quantization and a separate wires for each direction.

Maybe this board is read by a telecommunication student who may have SDSL modem source code handy and be willing to downrate such a code to 20kHz audio band and is not bound by 3rd party licensing requirements.

Two possible ways forward:

1) try to integrate some amateur radio code like http://en.wikipedia.org/wiki/WSJT_(Amateur_radio_software) . There are several people here who could advise you how to modify it to take advantage of wider bandwidth, much better signal/noise ratio and no multipath/echo.

2) see if you can write on your own a code to generate a 10kHz sine wave and a code to receive it properly at -3dB with AGC (automatic gain control). If you manage that then again this board has enough people familiar with amateur radio to advise you how to implement simple QAM channel (Quadrature-Amplitude Modulation). It shouldn't be that hard to reach somewhere between 1/10 and 1/3 of the bandwidth you originally asked for.

In my humble opinion the most work will be related to integration, not actual DSP. Things like: which of the several standards of audio drivers to use; how to detect available drivers; how to control output volume to avoid distortion; how to control input volume to avoid both noise and distortion. And last but not least: how to disable various sound effects, pseudo-3D audio, super-bass, etc.

S/PDIF / TOSLINK: This would be another avenue that I didn't think of, with the only real deal breaker is that support for it isn't ubiquitous - but not rare either.  You couldn't depend on two arbitrarily chosen computers having support for it to recommend it as "the" solution.

S/PDIF / TOSLINK, being a digital audio link, would work just fine for digital information, and is often used for one-off data transfer applications.  As an example, I have an audio receiver whose firmware you can flash by downloading a WAV file containing the firmware, burning it to CD, and playing it through a CD player into the S/PDIF input while holding down some magic keys.  Because no analog conversion occurs anywhere along the process, it works.  (Of course, there must not be any kind of modification to the data along the way.  For example, the CD player can't have its own volume control, and the CD burning software can't resample the audio in any way - they tell you "don't burn with Windows Media Player or it won't work" for this very reason).

TOSLINK is completely another story for another reason.  TOSLINK is essentially the same signal but over a low-grade fiber optic cable - would definitely add a serious "cool" factor to the air gap, even if someone had to pay for hardware to add it (and there'd have to be two fiber "cables", one per direction).  In fact, so cool that it would be worthy as a way for companies to say "Yeah, our wallet is optically isolated from the internet", even if they laid out a couple hundred bucks in the process to get it.

As 2112 mentioned, TOSLINK definitely has the bandwidth to sustain the kind of transfer needed for this application.  You probably can't expect bit-for-bit copy between computers (the sending computer will be recoding the audio to implement any volume or EQ controls), but you can expect a high degree of usable bandwidth without having to deal with things like losing part of your spectrum to noise or having to deal with detecting and rejecting noise.

Regardless, it's still probably best implemented as an application that primarily talks to a serial port, with the TOSLINK functionality provided in the form of a driver or program that does the audio transformation in a separate process and provides the data link in the form of a pipe or a fake serial port so the application itself isn't concerned with the physical layer.

Here's old tech, that can work over about any fidelity including phone as long as there aren't wholesale dropouts:

http://en.wikipedia.org/wiki/Kansas_City_standard

It uses two tones: one cycle of 1200hz = 0 bit, two cycles of 2400hz = 1 bit. This is 1200 baud, so it's going to be good for things like an audio address exchange, not for 10MB of data. One could use different frequencies for full duplex signaling (ie the receiver could send "ready to receive your transmission" or "error, retransmit" messages with 1700/3400hz audio). Sounds like this: basicode.wav (http://commodore-gg.hobby.nl/basicode.wav).

Here is an encoder/decoder written in Forth for the original 300 baud version: http://www.netbay.com.au/~dxforth/#kcs
Here's one in perl: http://www.cse.dmu.ac.uk/~mward/martin/software/index.html#CUTS

This is very easy to program for sending data. Just make a LUT of the two waveforms, and dump the data out as a 12KHz sampling rate wav.

For reading the data, you will need a simple fft able to discriminate which is the dominant tone and a transition-following clocker.

For actually coding, one would look at simple coding like RLL, with words encapsulated with ECC or sequence numbers. Data could be packetized into IP MTU-sized packages.

One must remember how slow even the height of v.90 modem tech was - it would take 20 minutes just to download this web page (http://bitcoincharts.com/bitcoin/txlist/).

Hold your phone up to your computer speakers to transfer data...

why not a stupid old serial cable? why the sound stuff? sound stuff is much vulnerable, as it can be listened to.

My original concern was that most linux systems still have tty logins enabled by default over serial.  Given that most users' username/passwd will be the same as one of the ones in their firefox/chrome saved passwords file, this could actually be the cause of many people losing coins.  Lots of people will do the minimum amount of work to just hook up the serial cable and use it if it "works".  Meanwhile, an attacker may be able to waltz onto the offline computer and have their way with it, while the user sits snugly on their couch thinking there's nothing that could go wrong.

But Casascius rightfully pointed out that many of these SNAFU conditions are detectible.  A user may not want to read even a simple set of instructions to set it up properly, but if I can actually disable offline Armory until the problem is fixed, then it makes it much more feasible.  I'll be thinking about that, and doing some research on what it would take to detect and close this attack vector.

Also, audio "listening" is not the problem.  None of the data being transferred is secret.  It's just transaction data that will end up in the blockchain, anyway.  And even if it was, 99.9%+ of the threat vector is not threats in the same room* (if the threat has physical access to your system, you're probably already screwed).  It's from having to link the offline computer to the internet (indirectly) and exposing it to the entire world of hackers and viruses.

*EDIT:  I shouldn't generalize:  I'm sure there are applications/scenarios where physical threats are a concern -- but the vast majority of users are not them, and the ones that do care know they need some kind of extra security measures.

No. and one needs exclusive access to the port, for things to work as expected.

By the way, one the other reasons I was so set on audio, was because I also wanted to enable smartphones to be used as the offline signing devices.  Take an old smartphone, disable WiFi, remove the SIM card, and then only connect it via audio.  That seemed to be a nice bonus to the audio solution (despite having to buy some adapters).

Now, casascius is doing a good job of persuading me that the challenges of audio are too great, and the risks of serial ports can be mitigated.  I'll be doing more research, but my question then becomes:  is there any hope for the smartphones?  Obviously, you can move the microSD card around, but that's what I'm trying to avoid in this thread/bounty.  What other options are there besides QR codes?

Or is there a way to make QR codes work for real?  If I have to move 1 MB, could I perhaps create a tagged list of 50 QR codes and play them in a video (looped), and let the other device just keep watching until it picks up all of them?  This is less of a problem than I originally mentioned to CIYAM, because you only need one webcam/wire, and there's no confusion about which device to point where (obviously, you can't point a smartphone's camera at itself).

There's gotta be a better way!  

yeah, i was going to suggest animated QR codes. but every demo i've seen so far has a really slow frame rate.

* Data to move   5   MB
* Data to move   5242880   bits
* Max audio date rate   9600   bits pr sec
* Time to transfer data   546,1   sec
* Time to transfer data   9,1   min

Add some error correction and stuff we are talking 15 min to move 5 MB.

It is not practical to transfer using audio.

Would this help?

http://www.slideshare.net/Sudar/transfering-data-using-audio-signal-in-android

http://mobileembeddedsystems.blogspot.com.es/2010/03/data-transfer-over-audio-port.html

Yeah, I recanted that statement in a later post, I guess I should update the top post.  If I do go with the audio solution, the rare 5 MB will just require patience on the part of the user...

Modems are so slow, because by standard, telephone signals are cut off after 3400(4000) hertz. And you can use only 7200-8000 hertz quantization. This is mono signal, and because of bad cables you can use no so many bits per quant.
33.6 uses 2400 hertz and 14 bit
56 uses 8000 hertz and 7+1 bit

With common audio cards you have 44100hz*16bit*2ch=1411kbps.
Theoretical maximum is about 160 Mb per 2 minutes.

Whole industry was involved because people wanted to get a maximum theoretical wire utilization. With this task all following bits are harder then previous.
We need only 160/5 = 3% from the theoretical bandwidth for done this task. This is a way simpler than 33.6 on a crappy telephone line.
We can use 97% from the theoretical bandwidth for code correction. Are we really should worried about all this stuff with so huge reserve?

What platform/s would this need to support in order to collect the bounty?

[EDIT]

"only allow for sending and receipt of ASCII data"

Why no binary?

It needs to support all platforms (since the goal is to get it to work in a platform-agnostic way).  Python, as usual, is pretty good about handling the platform-dependent details, and gives you a uniform interface to the audio objects.  I suppose to be supported on Android, it would need a custom java implementation, but that can be dealt with after the original implementation is demonstrated.

This needs to be accessible from python.  If it's a C++ implementation ,I can use swig to access it from python like I do a lot of other things.  But my guess is that you would want to do it in Python, and SWIG-in libraries that will do quick encoding/decoding for you ...?  (i.e. python handles the interface to the audio devices, but hands off all the data to a fast C++ backend for doing encoding/decoding).

I'm not entirely clear about the best way, but it definitely needs to be supported on Windows, Linux and Mac... under the assumption that the audio devices are already configured correctly.

I would recommend doing some research, but don't go too crazy with it yet.  Report back any revelations you have before actually trying to implement it -- if this looks like it's going to terrible (like difficult hardware support, requires complicated algorithms for handling various line qualities, has problems with feedback, etc... then we should probably think about another way).

On the other hand, there's nothing wrong with developing a pseudo-serial connection over audio.  Technically, this doesn't have to be bitcoin- or armory-specific.  As casascius suggested, perhaps the thing to is for me to write the communication assuming that there is a serial-like interface, and then it could operate over serial ports, IR, TOSLINK, or audio, as long as there's a "pipe" for it.

Just to be clear, before I'd consider any effort a success for the purpose of my "bet" offer statement, I'd require that one successfully implement an audio-based bidirectional data interface that exceeds the utility of an RS232 port and that is not significantly more difficult to set up than a null modem connection.

Typical max of RS232 ports on computers is 11.5 kilobytes per second, with an error rate that is substantially zero.  This would have to be achieved or exceeded, with a zero error rate.  (RS232 can go higher, but 11.5 KBytes/second is the typical max that the hardware is commonly configured with as shipped on PCs, a capability that can be assumed to exist on pretty much every PC with a serial port, and therefore the value I will use).

I'm not offering to pay 20 BTC for a demonstration that someone could get some data over a sound card - since I have no doubt it's possible.  Also, my statement that I'd be willing to "bet" is not a public bounty, but a private offer that I made to etotheipi and is technically contingent on him accepting it and being willing to pay me 20 BTC in case of failure... a restriction I would probably relax in the face of overwhelming evidence I was wrong.

Fair enough.  You're right I was a little hasty in adding you to the bounty.  I should remove that.  Honestly, I wasn't sure this was going to work, and the original bounty was intended give some incentive for someone to try.  I am not confident enough that this is so doable as to bet 20 BTC in the event that I was wrong -- I was simply willing to pay if it led me to something usable.

But to be fair, to say it works better than RS232 is a bit extreme.  The point of this exercise was to demonstrate that there is a reasonable alternative to RS232 -- one that is effectively isolated other existing modes of transfer (and thus have infrastructure/autorun stuff to assist with it that might be a security vulnerability).  My goal was not to have it perform faster.  It just has to transmit at least the same order-of-magnitude of data reliably (1/3 or more?), since that would enable me to implement the capability.

You are saying "I bet no one can create a better xfer protocol on audio than RS232."  That's not my goal.  My goal is "create an alternative that has similar performance."

But I'm not willing to bet 20 BTC that it's strictly possible, I was only offering 20 BTC for a working solution (with probably partial bounty for someone demonstrating that it can't).  But I don't want to add another 20 BTC to the failure case.

Actually I am getting closer to this possibility already...

Think of a "kindle like" device that has an "animation" capability built in but *zero* internet capability (I have one and it was cheap and was able to store QR codes with around 1K on each image that could be read by a webcam with no problem - and yes it's just a starting point - am sure it could be vamped up).

:)

Not even sure how I came across this thread.... interesting, so, I'll throw in my two cents.

Data over audio really isn't all that complicated folks.  It's been done many many times.

Modem stuff obviously is not the best to emulate, since everything about it is designed for use on POT lines, which have very limited frequency response.

For example, there is an open source fax patch for Asterisk that emulates a fax modem over VoIP. (http://www.zoiper.com/foip/ (http://www.zoiper.com/foip/) for those interested)  But its limited to ~14.4kbps max I believe.

PC sound cards and smart phone sound cards and the like are much higher quality in most cases.  Granted, you probably would need a decent effort to get decent speeds, still, but, it's certainly not impossible. I'd say 64kbit/sec (4MB in ~8 min) would be reasonably easy to achieve even with mono audio, and even with single direction comm.  Granted that this would work best as a two way link (speaker and mic on each device).

I've actually considered using audio data transfer for another project, but, never got around to making the code.  And I'll never write something like this for python, so, not going to be much help here anyways.

Just pointing out that it's possible!

-wk

Well anything in C++ would work, as it's trivial for me to pull it into python.  I just thought that python would be "easier" since it creates a nice platform-independent interface to the audio devices.  But if you created a C++ implementation that works for one platform, I'm sure it can be adapted it to my needs.

OK, you got me really interested in this, but I haven't done any DSP stuff in a long time... So tonight I coded up an extremely rough 16-QAM modulator/demodulator (& in python too!) Right now it just writes to and reads back the samples in a file, but pyaudio is already working on the speakers side so you can hear the data. Currently I'm in the mid 1980s, at 4 kbits/second. It wouldn't work at all in the real world though, maybe kinda through a cable. But the proof of concept is there.

The code is at https://github.com/notespace/python-scripts/tree/master/python-qam (https://github.com/notespace/python-scripts/tree/master/python-qam), and you can run it:
And it should show a nice diagram of the received constellation.

I'll release it under AGPL-3, just like Armory. There is still a ton of work to do to make it robust of course, and huge amounts of cleanup; not to mention choosing some standard data rates and implementing handshaking for real bidirectional comms. We'll see if I get any time to work on it. :P

Great!  I'm excited to see someone taking a serious shot at this, and hopefully something will come out of it.  Admittedly, Casascius has significantly lowered my expectations, so any positive progress seems all that much exciting :)

By the way, if you are going to not put it into public domain, please do realize that part of the reason I'm doing this as a bounty is in exchange for giving me unrestricted rights to the code to use in Armory.  Armory is AGPLv3, but if I ever decided to do some kind of closed-source add-on (or, say, corporate version), I don't want to have to get approval from other copyright holders who have less than 1% contribution (no offense).  Therefore, if you are going to put it under a license and still want the bounty, I request some kind of verifiable statement of transfer (GPG email is probably fine). 

We'll deal with it when there's bounty-ready code to transfer, but I just wanted to throw that out there so that there's no surprised.  A 20 BTC bounty is a lot (for me) but that's why I'm offering it.

Yes, I think that casascius's goals might be a bit too far off. If a usable Bitcoin transaction transfer system over audio comes out of it that's plenty cool though...

Right, I forgot about that and totally agree. IMO, public domain is a bit too out there for something that could be useful. Is something like MIT OK? I would also be willing to go the copyright transfer route as well if that is clearer for future use.

He's injecting a healthy dose of skepticism based on extensive previous experience.  I don't think it's as crazy as he makes it out to be, but he's rightfully pointed out a lot of issues that we will run into.  I am definitely much better prepared for having nothing come out of this, though.   Artificially-lowered expectations always make for a better experience when it does work :)


MIT license is fine.  I don't mind giving attribution for others' work that I'm using, but I just don't want my project to end up tethered to a bunch of other strangers on the internet that had tiny contributions compared to the entire project (no offense to all those strangers :)).

I should probably set a reasonable goal for the bounty so there is some checkout criteria, though I will be flexible if someone is close.

(1) It should work with "standard" audio cables (or attenuated).  I don't want users to have to buy expensive stuff... but buying something is okay.  I'm guessing that $20 or less would be ideal, but if it's in the $50 range it might have to do (and it looked like USB-to-Serial adapters were going to cost in the $30 range, maybe casascius can chime in about how to do it cheaper).
(2) The solution should achieve at least 1/3 the rate of RS232 on one audio channel (I'm assuming that a reasonable baud rate for RS232 is 115.2k, so this solution should get about 36k).  If it can optionally expand to two channels, that would be great but I expect most platforms to support one.
(3) Final baud rate should be what you get after all the error correction. 
(4) The solution would preferably auto-calibrate itself: most importantly it would probably have some mechanism for determining an appropriate output level (which is an interesting problem when neither side knows if the other side can hear them yet...)

We can negotiate the remaining terms of the bounty a bit later... it's late!

---

@Casascius

One other thing I meant to ask you that I hadn't resolved yet about RS232:  even if I succeed as detecting and forcing the user to disable TTY logins, is there a way to determine if any other processes are listening on the channel?  Beyond simply turning off OS auto-operations, it wouldn't surprise me if there were older applications that try to "help out" by listening and auto-processing serial information...

This guy has gotten 400kbps over sound card (and then through radio) with broadband QAM64. Closed source but demo versions/Linux available - you might be able to work out some license or have him open source the codec code for the size of the bounty; it might be more than he's made asking for PayPal:

http://homepages.paradise.net.nz/peterfr2/QAM.htm

http://homepages.paradise.net.nz/peterfr2/QAM.ht3.gif

Here's someone else that's coded up PSK over audio carrier, not awesome but public domain source code:
http://awesomegeekblog.blogspot.com/2009/04/file-transfer-over-sound-card-ii-phase.html
https://github.com/vlofgren/file-transfer-over-soundcard

You've won your 20BTC bet anyway.


And some posers (the public domain code above can do what they show, set to near-ultrasonic carrier frequency):
http://youtu.be/cJDi7Ik_X6w

The latter two links I kind of gave out earlier in this thread (they do max 100 or slightly more baud), but the QAM thing is definitely getting closer to something that could work.

Hey etotheipi!

Microsoft Research is copying your ideas. Check this out:

http://mobile.slashdot.org/story/13/08/15/1431251/ms-researchers-develop-acoustic-data-transfer-system-for-phones

I'm posting this here to show the doubters that this wasn't unworkable idea. It was just somewhat difficult to implement. It clearly is competitive to NFC as far as technology goes. It may not be competitive marketing-wise.

$30? You can definitely get them cheaper than that. I have three, one was given to me free by someone who was throwing it away because it stopped working.. broken wire in the USB cable, easy fix with a soldering iron but the cable is about 6" shorter now. The other two cost me less than $5 each brand new on ebay.

All three work great with every OS I've ever used them on (Windows XP and 7, Ubuntu, and both Mac OS Classic and OSX Tiger on an ancient G3 iMac I still fire up from time to time), total cost for all three was less than $10 including shipping. I'm using the the free/repaired one right now to run an HP LaserJet that's probably more ancient than the old iMac (did I mention that I enjoy repairing and reusing old computer hardware? lol)

This is an interesting project for the geek factor, but I think there are other, more attractive air-gap solutions.

Perhaps a better solution would be an animated QR code with a smartphone as a go-between. Hold the phone up to computer A and record a fast-animated QR-style code. The phone then relays this to computer B, and records its response. The phone itself could manage the communication and act as a master-key.

Anyway, a printed cold wallet and QR scanner are my current solutions, and they work fine. I've never really seen the point of dedicating an "offline computer".

I've become a big fan of the QR-video idea...partly because I have an extensive image-processing background.  I used to not like any video-based solution because I'm envisioning a mess of webcams and confused users trying to figure out which camera to point where, etc.  But if it's smartphone + laptop, it becomes a heck of a lot more usable. 

I just wanted to reiterate. Even though the price of BTC has drastically changed, I'm still willing to honor the 5 BTC bounty on this.

If the 25 BTC is still standing, I'd like to take a shot at this. I'm considering building a lib from the grounds up in C++ with OpenAL.

Although it's been a while since this idea was presented, I too think an "animated QR" would be a great idea.

Raize has offered to send the 5 BTC to me for Armory development.  So what I think I will do is keep the bounty open, and switch from {Me: 20BTC, Raize: 5BTC} to {Me: 25BTC, Raize: 0}.  That way ATI gets the 5 BTC to use for development if the bounty is never claimed, but it's still available to someone like goatpig who still wants to take a shot at it.  I think everyone wins.

I think this is a really cool solution, and I'm still happy to pay a $3k bounty for it.  It's an excellent option.  Though I do think the animated QR codes might be more reliable in the long run, and there might be an already-packaged solution out that we could license...

Chirp doesn't have an API yet, but it might be the technology you are looking for.  Clients are available for Android and iOS, but it isn't open source:

https://i.imgur.com/7t0EhAa.jpg

 - http://vimeo.com/45838932
 - http://Chirp.io
 - http://www.standard.co.uk/news/techandgadgets/reasons-to-be-chirpful-8836200.html

Let me get this clear, is this bounty for an open air audio data channel or a wired one? I only intent to develop one that works by plugging both computers sound cards to each over with a couple of double ended wires

I think we determined that over-the-air wasn't going to work.  If it did it would strictly be a bonus -- I intend to use/require the double-ended audio cables.

2 wires may not be necessary in some cases. I can reassign audio sockets on my sound card and this has been the case since quite a while with the advent of Realtek sound cards integrated to mobos. This is no priority of mine but I definitely intent to look into it.

It would allow for 2 ways simplex data transactions over a single line, and I think it will be feasible with most audio hardware. From my experience with MCUs, pins that are connected to the PWM output or the DAC can also be used as ADC, even on ancient 8 bit MCUs. It's only a matter of driver at this point. It would require some system calls which will result in portability nightmares but it's a viable long term goal.

I don't think the over the air data link is unfeasible, however it would be yet another nightmare to setup and way too much work when one can simply plug in a double ended wire across a couple PCs. All portable devices I've seen (tablets, smart phones, mp3 players, even portable gaming consoles) have an audio input and output port, so this approach fits long term, wide range portability as well. That and over the air would be considerably slower. I think people would prefer to take the 2 minutes it takes to plug a couple wires with an extra 5 minutes of transfers over instant setup and 30 minutes worth of audio torture.

Keep in mind that for desktops, the user will probably have to get some kind of audio splitter so they don't have to keep unplugging their speakers every time they want to do this.  Or at least an extender so that the cable is easily accessible from their desk chair.

It's not the most-convenient method, but it's still damned cool and damned secure.  And should be pretty portable.  I just wonder if it's going to turn into more of a research project in the end... where it will always work almost well enough, or just good enough under the right conditions, but reach asymptotic mediocrity ... meh.  I'll still pay to find out :)

I'd like the bounty to be for a usable proof-of-concept in at least one OS.  Once we have a prototype that can move at least a few kB per sec, then we will have something that can be used by someone and we can try to evaluate what it will take to get what we need out of it.  At that point, we may switch to some kind of hourly rate.  After all, I'm not a big fan of bounties for long, drawn-out activities.  But "prototype that moves a few kB/sec in at least one OS across a regular double-ended 3.5mm audio jack" is a pretty clear checkout criteria. 

Yes, this sounds good to me. You're going to have a better idea of what meets your requirements anyway. I just wanted to see such a thing done.


Agreed. Also, I would prefer something that can't be easily eavesdropped/recorded for analysis later (assuming third and second parties are occasionally allowed into the room where the Armory offline client is stored). At least with a direct audio link this isn't even a factor. I realize there are Tempest-like ways of catching interference even with a direct audio link, but those can be mitigated both electronically and physically(a quality van-Eck-phreaking device isn't going to be easily hidden on one's person).

Thanks.

By the way, there is no security issues with the transfer unless you are concerned about privacy, which probably isn't worth an TEMPEST attack itself.   The data moving between the devices is simply an unsigned transaction (online to offline) and a signed transaction (offline to online), which eventually ends up in the blockchain anyway.   So just like with the USB keys, there's nothing useful to an attacker besides learning that you have access to some given addresses and where you are sending money.  But if they're crazy enough to use such an attack they probably got your watching-wallet anyway.

So I'm not too concerned about that.  If someone is going to TEMPEST the room, they would better off trying to probe the buses on the device circuitboards. And if that's what's driving you, you can always get yourself a Faraday Tent (http://www.hollandshielding.com/158-EMI_RFI_shielded_Faraday_tent-en.htm)
 :)

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.

I see no reason to spend any effort on securing the channel, beyond making sure that the offline device is getting data from the correct online device (no injection).  But given the SNR of a direct audio cable, I'm not concerned about that either.  This is purely a bandwidth issue.

Compression would be great, except I wouldn't count on it to help very much, since the transactions are mostly hashes which aren't compressible.  I would guess you'd get no more than 5%-10% compression.  So again, the real bottleneck here is how many bits-per-second you can reliably push over the audio channel.

5-10% would pay for the packet headers and CRC overheads, I'd be fine with that. Snappy is overly way too easy to implement to just pass on that.

Regarding bit rate, I just setup a second PC in my room. Expect some results in a week or 2, depending on my schedule.

Quick Update:

OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.

PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.

If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.

Attribution is fine.  Adding their logo and acknowledgment to our website would probably be fine, too, if we actually integrate the solution into Armory.  If that's easiest for you, do it. 

Sounds good. I will build the lib with ASIO and perform tests with and without. If it turns out to be significant in speed and/or portability, I will keep it.

I remember reading about this idea a long time ago and talking about it on IRC, and I love it. I'll toss a BTC to whoever gets this done!

Hi all,

I have been working during the last weeks on an audio modem library in Python: https://bitbucket.org/romanz/amodem
EDIT: moved to GitHub: https://github.com/romanz/amodem (https://github.com/romanz/amodem).

I am using a simple headset, whose speaker is connected to the transmitting PC and the microphone is connected to the receiving PC.
Then, I bring the speaker and the microphone close together and use the PC's sound cards to perform the communication.

The sender is modulating data.send binary file using send.py script into 32kHz audio file (tx.int16), which is played using aplay Linux utility.
The receiver is using arecord Linux utility to record the audio file into rx.int16 32kHz audio file, which is demodulated by recv.py script into data.recv binary file.
The process requires a single manual calibration step in order to find the maximal volume for the speaker, so that it won't saturate the microphone.

The modem's bitrate is currently 8kbps - so it should not have a problem sending a simple transaction in O(seconds).
Moreover, I am sure it can be optimized by using better modulation, error correction and better audio equipment.

Currently, the documentation is quite lacking, but today was the first time I successfully transmitted 1KB of random binary data between 2 PCs, so I am quite excited :)
The recorded audio file is currently stored at rx.int16 - and can be demodulated by running:

I would be happy to continue developing this library, in order to integrate it with popular Bitcoin wallets, aiming to support air-gapped transaction signing.

Comments are welcome :)

Whilst what you have done does sound quite impressive - did you not consider just using QR codes instead?

(much more reliable and simpler compared to using audio)

Am pretty sure even etotheipi has changed his mind about QR codes.

Thanks for the compliment :)

I chose not to use QR codes, since my PC and laptop have no camera...

No, I haven't changed my mind about QR codes.  They're a non-starter, because the data transmission sizes are 1-2 orders of magnitude smaller than what is needed to handle standard transaction sizes.  Yes, it will handle 98% of transactions for some usage patterns, but only 5% of transactions for other wallet usage patterns.  It really needs to be 100% for all usage patterns.

OTOH, QR-video would work.  But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.

I actually already split up GPG private key into 2 QR codes for the CIYAM Safe so I do understand the size issues but I really don't think it is very hard to work with multiple QR codes.

I guess having something that identified "how many images are coming" could be more handy though (as a header with the receiver then able to verify they have got everything).

Some more technical details:
I am using 4 carrier frequencies (8, 9, 10 and 11 kHz), which are modulated using QPSK-4 (yielding 2 bits per symbol).
Each symbol duration is 1ms, so the bitrate of the modem is 8[kbps] = 2[bit/symbol] * 1000[symbol/second] * 4 (carriers).

The symbols' constellations are shown here: https://i.imgur.com/JAbGkIt.png (https://i.imgur.com/JAbGkIt.png). They can be plotted using:
Note that the noise is higher on lower frequencies, probably due to "pink noise" (http://en.wikipedia.org/wiki/Pink_noise (http://en.wikipedia.org/wiki/Pink_noise)).

The received signal waveform and spectrogram are given here: https://i.imgur.com/JMuRbAZ.png (https://i.imgur.com/JMuRbAZ.png).
They can be plotted using (after matplotlib package is installed):

By the way, is the BTC bounty still open? :)

I still have the coin to pay this. I don't think I ever got around to sending my bounty to etotheipi (we talked about me just donating, but he wanted to wait because I think goatpig was working on a solution), but assuming you can get it to meet the specifications, that sounds good. I think etotheipi's original bounty was for 5MB to be transferable within 15 minutes, however, and it looks like yours can do about 900KB in the same time frame?

In any event, I'll need some time to pull the bounty out of cold storage, I set aside some coin for doing this a long time ago and spent it when we hit $1k, but I can pull some more out of colder storage if needs be, ultimately I'm letting etothipi have the final say on a solution being viable, though, because what I really want is something like this to be built into Armory for cold storage purposes.

I do believe he said something about a partial bounty for code leading to a solution, too.

Good news, every one :)

I have used today a proper audio cable (instead of a headset) to connect between my PC's audio output and input, so the noise went down dramatically.
This way I was able to achieve 36kbps (after ECC) to successfully transmit 64kB.

Note that there is an overhead of ~2 seconds for the training sequence of the modem, so the effective transfer time is ~15 seconds.


The constellations are here: https://i.imgur.com/7kRtJb9.png (https://i.imgur.com/7kRtJb9.png)

Using 36kpbs MODEM throughput, we can transmit 5MB = 40Mb in ~1111 seconds = 18.5 minutes.

Awesome!  Those are very encouraging results.  I am busily working on the Armory 0.92 release, but after that I will have some time to see if I can reproduce your results locally.   If so, I think you deserve a bounty!    I encourage anyone else subscribed to this thread to collaborate with roman.z and see if you can get his solution working and verify that it works.  I pay out once I can use the solution to move a 2MB file between two laptops reliably, as long as the performance is somewhat close to what you just described.

Overachiever's goal:  can you find the right cables to move data back and forth between a smartphone or tablet?  How difficult would it be to demonstrate that you get sufficient performance?  I like the idea of taking a tx on your phone to the safe-deposit box, plugging in a 2-way cable between the phone and computer, and letting them do their thing.  Or two smartphones -- one online one offline.  Granted, android dev is a little out of scope for this bounty, but if we can at least propose a feasible path to getting there and expect that its performance will be acceptable, I think this solution will be 110% complete!



 

Hello roman.z,etothepi and other people.

I am mostly a webdeveloper by trade, but I tinker a lot with audio as well (amongst other things, creating 100% code-generated song covers known as 'Bytebeat (http://tinyurl.com/predfate2lq)'), and might aspire to become a full-fledged synthesizer developer or something of the likes in the future.



This truly is a very interesting idea. I would give it a shot myself, if it were not that roman.z was already doing such great work already; I don't want to make a competition about this and rather think that it's better to collaborate.

Some thoughts I stumbled upon while thinking about from your solution:
-Are you using mono or stereo audio cables right now? From the source cpde it seems to me you're not. Most computers have a built-in stereo input/output, and this would mean that you can effectively double the amount of carrier waves, and thus double the speed.
-You might want to look into QAM instead of using QPSK/8PSK, which basically adds amplitude-shift-keying on top of the phase-key shifting, greatly enhancing the amount of constellations (and thus the amount of data throughput)


Have a nice day,

~W-M

Thanks a lot :)
I will work to improve the APIs, the usability and the documentation of the tools.
May be I'll even prepare an "HOWTO" video, to demonstrate the usage of the modem.

Regarding smartphone<->PC communication: it's indeed an interesting problem. I'll think on it...

Smartphone <--> Smartphone, too.  The nice thing about the audio solution is that there's no reason it wouldn't work, you just need the right cables.  And of course an Android version of the audio xfer :)

Hi W-M,

Thanks for the compliments!

Your comments are both correct:
- I will find a stereo cable and test it with my PC<->laptop setup.
- I will use now QAM-16, and maybe even QAM-64 if the SNR will be high enough.

Best regards,
  Roman.

Hi all,

Audio modem library v1.0 is ready! :)
I've moved it to GitHub, under https://github.com/romanz/amodem.

The README file (https://github.com/romanz/amodem/blob/master/README.md) is now more detailed, and contains calibration and usage demos.
There are even screencasts for the demos:

• calibration: http://youtu.be/iCg1tepGz10
• usage: http://youtu.be/94yS3IZmtho

The data from my test is at: https://www.dropbox.com/sh/2yai1xmntdqlwf1/AACvfzasKEHK0zVxdzI4jF7pa

A few more details about the version:
The modem is using OFDM over an audio cable with the following parameters:

    Sampling rate: 32 kHz
    BAUD rate: 1 kHz
    Symbol modulation: 64-QAM
    Carriers: (1,2,3,4,5,6,7,8) kHz

This way, modem achieves 6[bit/symbol]*8[symbol/baud]*1000[baud] = 48kpbs bitrate = 6.0 kB/s.
A simple framing with Reed-Solomon ECC is used, with (255,245) rate = ~4% overhead.
(it should take a bit less than 3 minutes for 1MB to be transmitted)

I would be happy if more people will try and test this library.
Questions, remarks and suggestions are welcome!

It should be possible to automate this step.

Both sides start with the volume low and slowly ramp up until they establish communication with each other, then keep ramping up until they stop getting positive replies from the other side.

You are right, but this would require simulatenous bi-directional connection between the online and the offline computers, requiring two audio cables.
Since I have got only one audio cable, I am calibrating the sender manually. :)

Since the deployed solution is going to need to send data in both directions, you should probably just consider simultaneous bidirectional communication to be part of the requirements.

64-QAM audio. Nice:)

I'm late to the party, but really like where this concept is heading to!


Yes, I totally agree, a generic, modular solution would be sweet.
Both devices use a (virtual or physical) RS232 port, where users can decide what they put in between the two systems.

I would then not use an audio layer on top of that, but an optical:
- a green LED for sending data from online to offline, shining onto a phototransistor connected to the offline system
- a red LED for sending data from offline to online, shining onto a phototransistor connected to the online system

They flicker happily away, should be pretty fast too, and I immediately see when and how long they transmit data, and in what direction too!

Other users might prefer the audio link. Or a plain direct RS232 cable.

What do you guys think?

Ente

Thank you roman.z for contributing another soft modem to the world. They're pretty cool!

At first I thought this wasn't a good fit for bitcoin tx signing and was having the same "why not use RS-232" thought of others.

The one downside to using this is that it introduces yet another bus layer. Anyone using this should wonder if there is a security flaw in the decoder where a malicious encoder could break away from the bus layer and actually screw up the decoder software sufficiently to take over its execution environment. At least this can be audited for with this being a soft modem.

Ideal setup is probably to use RS-232 with the signing side RS-232 UART implemented in silicon (such as a super I/O chip), not by a firmware. Chances are that if the internet side of this is messing with the bus layer (if it were software defined and not a hardware UART) that it can't break past the signing side being hardware defined for the bus.

That way all security audit focus can shift to the data layer to make sure no malicious break-outs can happen there. Regardless of the link type, the quality of this layer of software will be the most important thing.

But, I appreciate that many people don't have the option of having a hardware UART on the signing side, so this is awesome.

Particularly because USB is not so very awesome:
http://www.wired.com/2014/07/usb-security/ (http://www.wired.com/2014/07/usb-security/)

Malicious firmwares on USB devices can do all kinds of nasty things to the host computer -- you don't want a compromised USB RS-232 adapter to be connected to your signing computer.

Let's go through some scenarios:
If you trust your RS-232 USB adapter for the your signing computer at the time of purchase, and if you can protect its integrity thereafter, consider two sub-cases:
 * Your internet side computer has a silicon defined UART -- there is probably no way it can mess with the bus layer aside from changing configured speeds and such and probably can not compromise the firmware of the software defined UART in the signing side RS-232 USB adapter

 * Your internet side computer has a software defined UART as well and can thus mess with things at the bus layer -- I'm going to say it is possible but unlikely that it could use that level of access to compromise the signing side USB device on the other end of the cable. There would have to be a security bug in the signing side USB firmware. Downside here is that these firmwares are mostly proprietary and thus costly to audit.


There very well may be situations where the continued integrity of the adapter can not be assured but the integrity of the signing computer can be (not simply by guarding it, but ensuring anyone who reaches it can't mess with it by using a TPM to ensure firmware and boot process integrity with the rest of the disk encrypted, fancy unique security seals on the case and regular internal inspections).

Write your fan fiction here folks where someone gets over the fence, drugs the dog, drugs the guard, hacks the walkie-talkie watchdog feature, hacks the security cameras sending video feed out by celluar to keep showing silent night, temporarily disables one alarm system with watchdog with fake watchdog, weaves through lasers of other alarm system that can't be disabled, cracks the safe, finds the USB adapter with the unique case, pops it open, desolders microcontroler that lacks flash memory (firmware uploaded on connect by computer), replaces with microcontroler that has malicious firmware flashed on, gets out of there by jetpack on the roof..... exchanges tumbled bitcoins for beachfront property in Caribbean...

I would always consider every single aspect of the online system to be compromised.
So the offline part better be good! :-)

As we inherently trust the offline system, we don't need silicon there. As we don't trust the online system, we couldn't trust the silicon there, as someone might have found a way to make it behave differently than expected.
For me, the border between "trusted" and "untrusted" is in the middle of the link (audio, cable, qr-code, LEDs), so I'm not sure any silicon would be worth it.
If the silicon is flashable, it's insecure.
If the silicon is "hard wired", it's custom and very expensive.
..I think.

Ente

This sounds very interesting!

I think that given two sound cards with optical input/output (such as http://www.dx.com/p/external-5-1-channel-usb-2-0-sound-card-optical-audio-adapter-black-41289),
it may be possible to use the digital audio interface as a uni-directional data stream...

The single problem is the additional cost (if existing sound card has no such interfaces), and maybe potential security implication (if USB sound card is used).

Thanks for the compliments!
It was indeed fun :)

I'd like you to post links to the chip data sheets and computer I/O products that are the examples of two UART classes that you've just defined.

Otherwise I'm going to call baloney.

Edit: forgot to quote the full message into my collection.

2112, you're right to call baloney.

A real hardware UART (http://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter) is a standard feature in microcontrolers. (for example (http://www.atmel.com/images/atmel-2486-8-bit-avr-microcontroller-atmega8_l_datasheet.pdf))

I would be hard pressed to find a microcontroller datasheet that didn't have one. Even if I did, such a datasheet wouldn't necessarily go out of its way to explain that I the programmer of said micro could achieve the same functionality in software by bit banging (http://en.wikipedia.org/wiki/Bit_banging) general purpose IO pins. It would more likely be documented in a data sheet if such functionality were specifically included in firmware.

There are two commercial products I know of that had no UART and had RS-232 bit banged on general purpose (user) io pins, the low cost VIC-20 (http://en.wikipedia.org/wiki/Commodore_VIC-20) and Commodore 64 (http://en.wikipedia.org/wiki/Commodore_64). I think support for this was included in the firmwares.

With UARTs being ubiquitous and with bit banging being very inefficient, I would say there is next to no chance that any USB RS-232 adapter does that. I was wrong to raise it as a possibility. It's safe to assume they all have a hardware UART on the RS-232 side of them.

You only need to worry about the USB side of the signing machine. On reflection, that Wired article may have over-hyped the dangers. USB devices can't just arbitrarily read/write any system memory can they? I think a malicious USB device has to be more sneaky.

Actually I had a much simpler way in mind:
a serial cable coming from both the online and offline computer, meeting in a transparent box. There, they have LEDs and phototransistors hooked up. Much like an optocoppler. Now the two computers can effectively speak to each other over RS-232. The difference is that I can visually see there is data communication, how much, how long, and in what direction (via different colored LEDs in both directions).

How Armory speaks to the onboard RS-232 port, or to a USB-to-RS232 adapter is just software. And exactly this dynamic, modular software layer I was proposing! :-)

Ente

This idea is gold, while I was reading this several ideas came to mind regarding ways to use this technology to benefit us all.

Good luck!

I'm not worried at the moment.

- USB has no evelated rights per se. Whatever you stick in, runs with user rights. No matter if legit or fake keyboard or cam or flash. Only with holes in the USB stack itself this isn't true any more, but then that's a whole different problem.

- Firewire, pcmcia-cards, pci* and the like have *real* access. Like, a firewire device can read and manipulate all content in RAM without asking the OS or the CPU or them even noticing. I deactivated Firewire years ago in bios.

- Every USB device needs a custom evil firmware. There never will be malware which can just infect all USB devices it can get hold of. Many devices will be "immune" because their firmware can't be rewritten reasonably, or because the firmware flash memory is already full with the original firmware, no space for evil enhancements. At worst, malware might know and try to re-flash a few of the most common devices. All "sandisk" drives for example. This probably will kill more devices than turn them evil.

- We are, hopefully, not connecting random USB devices to our airgapped system. My initial plan was one USB stick, going back and forth from online to offline system. So *exactly this* device would have to be reflashed, and then this evil device must somehow gain control of the offline system.

- There are "USB switcher" thingies. Connect two computers and one device, and you can switch that device back and forth between those computers. Via button or software. I don't think someone could reflash a USB stick which isn't connected to my (infected online) computer when there is that "USB switcher" in between. Not 100% sure of course.


The bottom line is that we need to get data back and forth between the online and offline system. So it's not *offline* in the strict sense.
Because of how Bitcoin, Armory and transactions work, we can't predict how much data there will need to be transferred, and that data isn't human-readable to check directly.
So, no matter how clever the setup, in the end the user can only tell that, and how much data there is transmitted, and in what direction.

And that's why now, scrapping my initial USB and "USB-switcher" plan, I like that "red and green blinking serial cable" idea.

Ente

Haven't seen it mentioned yet, so I thought I'd let you know that I've successfully transmitted a tx to sign back and forth today using minimodem: http://www.whence.com/minimodem/
https://github.com/kamalmostafa/minimodem

As was mentioned, it took a while, but still quicker than USB back and forth :)  

It works for both mic / speaker as well as straight 3.5mm jack cable.

Alsa gave a lot better results than Pulseaudio.

Hi etotheipi,

I've tested the quality of the "Smartphone -> PC" connection, by playing an WAV file (containing modulated audio at 48 kbps) from a Nexus 5, and recorded it from a PC microphone jack - using a standard 3.5" male-to-male cable. I've successfully demodulated a single 16kB file transmission, containing random binary data.

For the opposite direction, I need a special cable that allows me to connect to the microphone of the smartphone, so I've ordered the following cable, that seems to be fit for the job: http://www.aliexpress.com/snapshot/6288177801.html (http://www.aliexpress.com/snapshot/6288177801.html).
I will report my results when I get the cable :)


Regarding "Smartphone <-> Smartphone":
I think that it may be done easier by some kind of "QR-video" solution, since both of the smartphones should have a camera, and they are quite easy to operate (as compared to desktop screens and webcams). In addition, since we need to achieve ~6kB/s rate, we can use the larger versions of QR codes with quite low fps value. For example the largest version (#40 = 177x177) can contain 2,953 bytes = requiring 2 QR codes per second to achieve the required rate (see http://www.qrcode.com/en/about/version.html (http://www.qrcode.com/en/about/version.html) for details). The Android application itself will probably look very much like this one: http://stephendnicholas.com/archives/310 (http://stephendnicholas.com/archives/310) (which quite cool IMHO).

BTW, I've took some time to improve the audio modem library a bit:

• a few optimizations so decoding can run "in parallel", while the audio is being recorded.
• unit test suite with good code coverage (integrated with https://travis-ci.org/romanz/amodem (https://travis-ci.org/romanz/amodem) and https://coveralls.io/r/romanz/amodem (https://coveralls.io/r/romanz/amodem))
• better (and easier) command line interface for sending and receiving data.
• make the library code to be PEP8 compatible.
• add support for Python 3.
• calibration process now checks all frequencies that are used for transmission.
• improve equalization process, with better handling of signal distortions.
• I am using a hexagonal constellation grid (instead of standard QAM), to improve SNR for existing bit rate -> thus decreasing error probablity

See https://github.com/romanz/amodem (https://github.com/romanz/amodem) for details.

Good work, Roman!

Well, those transactions can get surprisingly big. That's why some people gave up on QR codes. Connecting something would be more convenient, and audio would be universal, as all devices which can do tx stuff should have some audio (or USB) connectivity.

Of course some people won't like connecting a cable at all, as this feels much less air-gapped.

Well, I personally am waiting anxiously for the addon functionality. Actually for me this will be more exciting than the new wallet format and everything else. Then we can modularize, and get some work off the shoulders of the Armory devs, and users can choose even more fine-grained between security and features.

As soon as we have addons, I'll get me blinking light based tx transmission. So I see when and how much data is transmitted in what direction. And I can have some air between the LED and receiver ;-)

Ente

I have been thoroughly distracted and I totally lost track of this effort.  However, I believe that the stated goals have been achieved, and certainly roman.z has put together an awesome tool.  Looking through the code I see it is very clean, commented and includes unit tests.  

Amusingly, after all of Roman's effort, Newar found the minimodem library which somehow evaded detection in this thread for many months (years?).   I think it's a slower-but-sufficient solution for linux-to-linux communication.  For this, I think Newar deserves an "Honorable mention" of 1 BTC.

Therefore, I will split the bounty 24 BTC to Roman and 1 BTC Newar.

Wow, unexpected!

1NBZszNS8opnNK1kCW9hoMUJa8aWbBXCyC

Thanks!