back
4 comments
I've been working on a similar tool: https://github.com/ggerganov/kbd-audio (see the 'keytap' tool). Not sure how well it works yet, as I have made tests only with my setup. There is a live page that anyone can experiment with.
This is incredible work. Very well done! Have you posted this to Show HN yet?
Thanks! I haven't posted it yet, as I want to test how reliable is the approach. I know it does not work with non-mechanical keyboards at all (most likely because the key sounds are quiet) and I have tested it only with my mechanical keyboard.
Then I must apologize as I've already posted it to Twitter where it's getting a lot of really positive reactions: https://mobile.twitter.com/feross/status/1068038193868460032

It worked pretty well on my keyboard! Let me know if you'd prefer me to delete the tweet.

Wow! Thanks so much!

Please, don't delete the tweet. Hopefully I can collect feedback. Thanks again!

What kind of keyboard do you have?
That work is great. A related paper on earlier work where traffic analysis on skype was being done and where the researchers were able to extract individual phonemes and then reconstruct speech that way. It's one of my favorite papers. It's titled "Phonotactic Reconstruction of Encrypted VoIP Conversations" and you can find it here: http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf
Voice is in a way the easy case, because we know the antidote. Constant Bitrate (CBR) mode of an audio codec consumes the same amount of bandwidth regardless of what is transmitted, which is inefficient but secure. As I understand it Signal's voice chat is Opus in CBR mode.

Other scenarios are trickier and may need custom work. For example Encrypted SNI currently requires a host to pick a maximum name length, the encrypted name may be any of those names configured on the host, and is padded to that length so that an adversary can't guess which name from the length.

Because we don't have a general solution, TLS 1.3 defines an zero overhead optional padding, you can add extra bytes of padding to any TLS message but neither TLS itself, nor the HTTPS binding defines a "good" way to use this padding to shield users from analysis of content based on size because there is no general solution known.

I haven't been able to recreate this work from the repos. I emailed them too, about a year ago, with no response.

Have you had any success? If so, would you be willing to share?

It sounded too good to be true, then I found the caveat: a neural net must be trained on a specific keyboard. Still pretty cool, though.