Topic: [BOUNTY - 25 BTC] Audio/Modem-based communication library - page 4. (Read 11907 times)

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.

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/ 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

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).

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.

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.

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.

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?

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?

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...

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

* 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.

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

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!  

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

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.

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

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.

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.

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

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.

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.

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.)