[guardian-dev] The sound of an encrypted audio stream

[Lee Azzarello]

These are great links, thanks Mr. Doctor.

It seems that my original audio sample was some kind of codec error of
noise, rather than noise. I think it sounds pretty cool. Expect it to
end up in a noise show in Brooklyn sometime!

Also, I'm compelled to comment on Frank's opinion around call
security, life and death. A cryptosystem that leaks any information in
a life or death situation is obviously a BAD IDEA. No one, myself
included would ever recommend a process or system in that case.

But crisis situations of state murder are not the only case for
software security. One reason I've given so much attention to this VBR
issue is to determine the message around "general purpose client
applications". Supporting client choice is an unpopular position. Pop
culture says apps apps apps! An app for each web page! The general
purpose need for privacy is not an issue of life and death and I think
it's responsible to explain the risks of different client applications
for secure communications. In this case, the whole discussion started
when someone in IRC said "An encrypted call with a VBR codec has 100%
plaintext recovery". This is false, and falls under the FUD umbrella.
Since I can't control all client applications in the world, and I
support secure communication AND client choice, I believe it's the
responsible thing to be informed about the different risks associated
with client applications.

I would like to see a build, probably of Linphone since there's iOS
code too, that covers all known risks around streaming media security.
Since the challenges are mostly configuration options, I see this as
something close to Tor Browser, which is Firefox with advanced
configuration.

Regards,
Lee

On Thu, Jul 25, 2013 at 11:47 AM, The Doctor <drwho at virtadpt.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/24/2013 06:11 PM, Tim Prepscius wrote:
>
>> Are you dealing with the packets of a encrypted compressed audio
>> stream? It might be interesting to determine the "randomness" of
>> data? I would think, that if it is not random, there is a
>> problem... ???
>
> There is software out there that will help you make such an analysis:
>
> http://www.phy.duke.edu/~rgb/General/dieharder.php
>
> I have used this a fair amount in some of my older research:
>
> http://www.fourmilab.ch/random/
>
> This article will definitely be of interest because it describes a
> one-liner for converting arbitrary streams of bits into images for
> visual inspection:
>
> http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
>
> - --
> The Doctor [412/724/301/703] [ZS]
> Developer, Project Byzantium: http://project-byzantium.org/
>
> PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
> WWW: https://drwho.virtadpt.net/
>
> Rubbing the electric lamp is not particularly rewarding.  Anyway,
> nothing exciting happens.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHxSHQACgkQO9j/K4B7F8FujwCfVNvg4bi5fuBpv3gdWK/9ODyA
> K/kAniO0fIVDE6b938p0oRGNLXjyX/tT
> =ldHs
> -----END PGP SIGNATURE-----
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info