[messaging] WaveCrypt

[Justin King-Lacroix]

On 10 April 2016 at 10:27, Mihai Ionut <c.ionutmihai1 at gmail.com> wrote:

> Hi, I am a 21 years old software engineer from Bucharest, Romania
> passionate about programming, robotics, cryptography and Artificial
> intelligence.
> For the past two months I've worked on a new encryption application based
> on sounds. It allows users to encrypt their files (AES) using an audio
> input.
>

There's a lot of coolness in this idea. You might want to read up on the
use of sound card inputs as sources of entropy for random number generators.


> The users have three options : they can generate their own  WaveKey, they
> can use an exiting audio file (your favorite song from 1990's stored on a
> CD) or to use an online audio source - now I'm only focused on YouTube. You
> simply visit an YouTube video, select the time sequence, generate you
> WaveKey and encrypt your file. After that the key self-destructs.
>

While the idea isn't a bad one in principle, it means you now need to treat
the relevant YouTube link / song name with the same care as a cryptographic
key.
Also, YouTube knows your key.


> Of course I've taken into account the obvious attacks - like the ones
> regarding recording when the users create their WaveKeys (I've worked on a
> custom printed circuit board with an integrated microphone and a small
> storage USB drive) or, in the case of the YouTube source your search
> history (We have Sandboxie and I'm pretty sure I can strike a deal with
> them).
>

What you haven't considered is that everyone on the network who can observe
your YouTube search history now potentially knows your key. Sandboxie only
prevents your browser from keeping its history on your hard disk; any
traces you leave on the network -- such as in YouTube's access logs (you
weren't logged in as yourself when you viewed it, right?) -- are, by
nature, not eraseable in this fashion.

On the flip side, generating your own WaveKey also seems problematic: on
the one hand, you want to filter as much noise as possible out of the audio
coming into your application, so the key generation is repeatable ie you
can sing the same song into the same mic again on a different day and
decrypt your files. On the other, you're throwing away a lot of entropy
that way, potentially making it easier to just brute-force the key.

If you solve this problem using a USB drive (or similar) connected to a
microphone to store the 'authoritative' copy of the recording, and reuse
that, we're now back to the usual key-management problem, only your key is
an unwieldy sound recording.


This idea is cool. However, I believe these issues need to be fixed or
mitigated before it can be put to practical use.

</$0.02>

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160413/5bac4115/attachment.html>