To summarise the general classess of side channels mentioned in Wikipedia: Power analysis should be tackled with running the TCBs on batteries. I introduced the issue of electromagnetic and acoustic leaks but it's a very complex issue and I'm not an expert dealing with them. The RxM is the only device attacker can introduce faulty data to compute on. However, no feedback is available due to the implementation thus unless pre-compromised, the hardware should not have back channel. TFC does it's best effort to overwrite and verify overwriting after key material has been used. Each of these is mentioned in white paper. More work is needed to create high-assurance physical/close proximity security but again, user is informed about the issues and the main threat is automated remote exploitation. The purpose of Pidgin is to transmit the messages. To simplify, TFC is a plugin for Pidgin that automates you doing encryption in a secure environment and typing the ciphertext to OTR encrypted Pidgin window with your keyboard. It also automates decryption of ciphertexts you receive when OTR-plugin of Pidgin decrypts the outer layer of message. So for TFC the encryption is SSL( OTR( OTP(Message)||MAC )) and for TFC-CEV you replace OTP(Message)||MAC with AES_GCM(Twofish(Salsa20(Keccak(Message)))). The pages 9 and 10 of whitepaper explains this in more detail. Please let me know if there's anything that needs to be clarified. On 04.02.2015 17:51, stef wrote:
On Wed, Feb 04, 2015 at 11:58:17AM +0100, rysiek wrote:
Dnia środa, 4 lutego 2015 06:39:48 Markus Ottela pisze: http://www.cs.helsinki.fi/u/oottela/tfc.pdf i think i have to add an 8th rule: vendor applies rules against own product. ;)
but seriously, the hw design with the diodes is pretty cool, however maybe i missed it but i couldnt find much focus on sidechans. also what i don't get is why pidgin, if you have the communication end behind the diodes, then what exactly does pidgin provide? but i was only skimming the doc.