Interesting; I'm scanning the code now, but won't pretend to be an expert. First thing, your HMAC code is possibly vulnerable to a timing attack: https://github.com/maqp/tfc/blob/master/Rx.py ..using direct string/byte comparisons for HMACs can be vulnerable as most languages will shortcut on the first mismatch. In your case, using this attack might require the means to craft a message that matches a certain hash, but maybe someone who knows more could use this to recover key material? The way to avoid this is a comparison function whose time does not depend on the likeness or unlikeness of the compared values, for example by xoring the strings or characters. Second issue is the use of LibPurple at all. It's widely considered to be a security trainwreck, and given its poor reputation *and* the total disinclination of the libpurple devs to bother with security concerns at all, it's easy to imagine anything up to remote code execution in libpurple compromising the whole system. So, your tinfoil hat could be as secure as anything, but relying on libpurple may undermine the entire exercise. Using a different transport may be more valuable. Finally, you're using a custom HWRNG, and reading with custom C code to a file. Firstly, why is this a C function, when you could probably achieve it in Python? But, more importantly, why not use the system call to deliver this entropy to /dev/urandom, and use that? The mixing code for /dev/urandom has received pretty good review, far more than your code can hope for, so the more you rely on /dev/urandom IMO the better. There's a Linux system call to mix entropy into the system pool, and your HWRNG would be well served to use that if you ask me. And, you could probably access that call using ctypes from Python without requiring your end users to compile C. The less compilation required, the more likely you are to get user buy-in. On 08/06/14 03:33, oottela wrote:

I'd like to share a project I came up with back in spring 2012 and begun working after the Snowden leaks started.

Highlights are

-OTP encryption for perfect secrecy -OTP encrypted Keccak HMACs to prevent undetectable message tampering -HW TRNG to generate truly random keys (Von Neumann whitened) -HW Data diodes to provide immunity against message exfiltration attacks originating from network.

Source code and links to whitepaper and manual are available from

https://github.com/maqp/tfc/

Regards, Markus

-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com