Hi Cathal. Thanks for your review! The RxM that does the MAC verification doesn't leak data to network connected computer so attacker would have to have line of sight to display of RxM and through trial and error send tampered packets until one doesn't show the warning about tampering. By then user should have pretty good idea about what is going on. Recovering key material shouldn't be a problem since key is not reused in signing of new messages. The implementation however has now been changed while fixing more critical vulnerability with hash function input size. Regarding second issue, LibPurple does not contribute to privacy of messages in any way. The only thing the computer that LibPurple is running on handles is OTP encrypted data. OTP keys and plaintext messages never touch that computer and malicious functionality of that computer can not possibly request the actual keys from waterfall secured TxM or RxM. The whitepaper explains why the system is secure even if attacker gains root access to computer where Pidgin is running. I did not write the program that samples entropy via GPIO. Programs written in C generally work faster so I didn't feel the need to redo the part. Also, the installer takes care of compiling. I've done some testing and according to Ent /dev/urandom is more random (7.999995 bits / byte ) source than the TRNG (7.997587 bits / byte). However I'm somewhat concerned about seeding, pseudo randomness and effect of modern hwrng devices - can seeding of urandom be compromised by /dev/hwrng input from processor with dopant trojan even if mixing entropy from functional TRNG is done. I'll have to read about the issue before I'll change the implementation. After all, with the TRNG there should be no auto-correlation if sampling speed is slow enough, and no bias when Von Neumann correction is used, despite what statistical tests say. Also, I'll look into the ctypes library and see about the difference in sampling speed. As user has access to source I suppose compiling doesn't endanger the security in any notable way. On 09.06.2014 12:28, Cathal Garvey wrote:

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