Tinfoil Chat

[Cathal Garvey]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140609/f27999ea/attachment-0002.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140609/f27999ea/attachment-0002.sig>