<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 22, 2014 at 5:50 PM, Andy Isaacson <span dir="ltr"><<a href="mailto:adi@hexapodia.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=adi@hexapodia.org&cc=&bcc=&su=&body=','_blank');return false;">adi@hexapodia.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">If I'm understanding their design correctly, they're taking the user's<br>

</div>
voice and compressing and encrypting it, then encoding the encrypted<br>
data as audio to send to the far side.<br>
<br>
If so, they'll need to define a modulation to transport their encrypted<br>
data stream over a voice channel.  Doing this in a way that will work<br>
reliably over the high latency, multicodec, bizarrely lossy cellphone<br>
network is nontrivial.  Getting it to demoable quality is pretty easy,<br>
getting it to work well when the cell signal is fading in and out will<br>
be lots of fun.</blockquote><div><br></div><div>Another fun engineering challenge for these sorts of compressed/encrypted digital voice systems: avoiding information leakage sidechannels in variable bitrate audio compression:</div>

<div><br></div><div><a href="https://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdf">https://www.infsec.cs.uni-saarland.de/teaching/WS08/Seminar/reports/yes-we-can.pdf</a></div><div><br></div>
<div>
tl;dr: use CBR I suppose? Is this device using CBR, and is that sufficient to mitigate this attack?</div></div>
</div></div>