Topic: [BOUNTY - 25 BTC] Audio/Modem-based communication library - page 3. (Read 11822 times)
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.
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).
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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:
- http://vimeo.com/45838932
- http://Chirp.io
- http://www.standard.co.uk/news/techandgadgets/reasons-to-be-chirpful-8836200.html
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.
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...
Although it's been a while since this idea was presented, I too think an "animated QR" would be a great idea.
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.
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.
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 it's 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".
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 it's 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.
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".
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".
(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).
$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)
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.
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.
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.
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
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
http://homepages.paradise.net.nz/peterfr2/QAM.htm
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
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...
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
Quote
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.
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...
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, 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.
The code is at https://github.com/notespace/python-scripts/tree/master/python-qam, and you can run it:
Code:
(apt-get install python-pyaudio python-matplotlib)
python send.py (you might need to turn the volume down?)
python receive.py
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.
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
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...
Quote
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.
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. 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.
Jump to: