Didn’t look into it yet.
Just got mentioned on Twitter.
https://twitter.com/InfoSecZ/status/1174325406088015873
Any opinions?
1 Like
Hmm, I guess it makes sense in face of remote exploitation. It depends on the capabilities of the attacker:
- If the attacker can break out of Qubes VMs, then the user needs to use two separate systems that are protected by a physical network protection unit like the author suggests.
- If the attacker can attack the network stack but can not break out of VMs, then this is already being protected by the current Qubes setup using NetVM / firewall-VM etc… (Side node further down)
- If the attacker can attack on the application layer while receiving the message and key handling is happening inside the AppVM, this would be a problem. The usual Qubes solution would be something like a separate “PGP VM” for encrypting and decrypting messages, which is not suitable for real-time messaging and comes with an additional problem (see the next bullet point)
- If the attacker can attack on the application layer while decrypting the message, this would also affect the aforementioned “PGP VM” and could let the attacker change the key used for encrypting messages.
In the last two cases, since we are assuming that the attacker can not break out of Qubes VMs, we could make a dual-VM setup similar to the design the author proposes using firewall rules. This is what “J B” suggested. This would not have physical security guarantees though.
On a side note, regarding breaking out of VMs: If we assume that the attacker has a network stack exploit for Linux, doesn’t this mean that he can also infect other VMs that are connected via Qubes internal routing? I’m not fully informed about how that is implemented, but if the firewall that checks access itself is running on Linux, then the firewall VM would be vulnerable to the same lower-level network stack exploit. (I’m sure I’m missing something here, but it comes to mind when thinking about the need of physical network protection units like developed by the author of TFC)
1 Like
-
Made by an academic with prior privacy contributions: Markus Ottela
-
Very interesting architecture. The diode isolation design is beyond cool sounds like an app designed for an classified network. We should ask if it’s possible to tweak it for “less secure” isolation supporting out hypervisor disaggregation to support our OS.
-
Perhaps suggest PQ ciphers.
-
Uses its own crypto in addition to Tor’s and also applies padding to obfuscate data size.
1 Like
Hey, I found your thread so I hope it’s OK if I answer/comment 
TFC has for the past two versions supported isolation with Qubes Xen hypervisor. The default configuration doesn’t use Whonix workstation but Debian standalone VMs. I’m wondering if there are any benefits to e.g. using Whonix workstation as the standalone Networked AppVM instead of Debian10. The Network interface of the Debian AppVM can be set as the Whonix gateway, so everything should be possible to Torify.
I will definitely look into that once the NIST competition ends, and a suitable key exchange algorithm with robust implementation is created. For now, post-quantum security can be achieved with the password-protected PSKs users can exchange via sneakernet. Obviously that isn’t a solution to people living across long distances, but just to let you know, the option is there.
Once standardized, the public key length will determine if endpoint secure post-quantum key exchange is reasonably practical. After all, it needs to be imported manually. E.g. in the McEliece system there’s 500kB long public keys. Base58 has 73% efficiency so you’d have to type ~685,000 characters by hand. This isn’t feasible. On the other hand, NTRU uses 2kB long public keys, this is very tedious but doable by the users: It’s slow but never slower than e.g. a plane trip to deliver the PSK.
If the post-quantum algorithm isn’t practical between TCBs, it will be established as a middle encryption layer (between TCB-to-TCB encryption and Onion-Service-to-Client TLS-like encryption) between the Relay Programs. This prevents CT-only attacks and requires endpoint compromise to recover the post-quantum session keys. This should provide forward secrecy at least until the point the endpoint is compromised, Most likely it will provide post-quantum security for all future messages, if the adversary doesn’t compromise the endpoint to break the initial session where TCB-to-TCB X448 public keys were exchanged.
I’m saying this just to let you know the ideal way to implement it is still an open UX research problem. But again, it’s coming in one form or another once the algorithm is standardized and the implementation is robust enough.
Uses its own crypto in addition to Tor’s
This was one of the problems the Ricochet audit identified. With v3 Onions within e.g. Cwtch.im, additional layer of ciphers isn’t adding too much in terms of bit-strength, but the key exfiltration security requires a separate layer of encryption. This has gone through several iterations and I’m more than happy with the current suite: it offers Spinal Tap grade security and there’s no protocol negotiation which means there’s no downgrade attacks. Having no strings attached and no validation to comply with, it’s been a pleasure to put not-yet NIST-approved Curve448 to use like all proper cypherpunks should.
“It’s own crypto” has a slightly negative connotation so to ease any concerns I’ll just note that the cipher implementations are from respected libraries created mostly by the original designers. PyNaCl provides bindings for libsodium that in turn is a wrapper for NaCl, made by djb. The X448 bindings in pyca/cryptography library are for the OpenSSL library, and that code was authored by Mike Hamburg himself (the designer of the Curve448). Finally, the argon2_cffi provides bindings for the reference implementation by the Argon2 authors. The Python code tests the application-level API with official test vectors to detect any obvious implementation errors on higher levels.
Let me know if you have any questions!
2 Likes
Thanks for the lengthy reply and reaching out. Nice to see the project still active.
You’re right, I meant it as “an extra layer” rather than something rolled up in your basement.
Have you considered joining forces with cwtch and/or Briar? In the past few years, there were onion based chat projects that got many people excited only to disappear. I really wish one of the projects gathers enough momentum with UX and mobile support that it becomes a popular and self sustaining project where we can point users to.
1 Like
Back when TFC was just a plugin that used Pidgin as the transport mechanism of ciphertexts I reached to John Brooks (the Ricochet developer) and SJL (the Cwtch developer) about a feature that would allow IPC with other applications but understandably both were too busy. Micah Lee from The Intercept was very kind and pointed me towards Stem, and I’ve since tried to help Lee et. al. with OnionShare, that has much more similar stack (Tor + Stem + Flask). I haven’t talked to Briar developers.
TFC is for now in maintenance only, meaning I’m mostly skimming the code for vulnerabilities, and updating dependencies on ~monthly basis. The best part about the project is majority of security comes from the hardware architecture so it’s extremely unlikely any vulnerability would result to key / plaintext exfiltration, even if I never updated it in the future. So the app can handle the slower maintenance. Anyway, don’t expect the system to disappear at any time, I’ve put far too much effort to it over the past eight years to just let it die.
1 Like