Tinfoil Chat

[oottela]

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