What will happen, is TAO operative sees connection of Jericochat server from XKEYSCORE, sighs and clicks on a button. The next time user of Jericochat browses to youtube.com, QUANTUMSQUIRREL will automatically prented it's the youtube server, it'll forge the TLS cert with key obtained from server / produce a fake cert signed by key obtained from Google CA. It'll then do a deep packet Injection with TURBINE, and inject a transparent exploit that uses a known / 0-day vulnerability of user's browser, and with that, it'll inject UNITEDRAKE to the computer. UNITEDRAKE's plugin SALVAGERABBIT will exfiltrate the OTP-keyfile and it's a game over.
This is likely true for any encryption protocol that the TLAs have difficulty cracking (or it's more time consuming and expensive for them to crack). Therefore it's cheaper and more effective to just plant malware on the machine and capture plaintext as it's being typed at the source. I think TFC does have a good solution in this area with the one-way Transmitter and Receiver modules with the keys and plaintext being prevented from exfiltration. It would be nice if TFC was commercialized and made into a product though. Not a lot of people have the time or inclination to build a TFC setup which will hinder adoption. If you could miniaturize it into a phone/tablet like device, without closed baseband, including screen and keyboard that would be excellent. Then people can use it as a dedicated secure messaging device.
Even TFC I don't think is bulletproof. If the TLA detects a TFC packet fingerprint in XKEYSCORE they can always exploit their privileged network position and use their systems like QUANTUMINSERT to reroute the packets to a FOXACID server, or just drop them completely, preventing two parties from communicating securely altogether. There's not much you can do when that happens. That's why I think it's critical to obfuscate/hide the protocol meta data as much as possible so these automated detection and interference systems never work. In future versions of Jericho I have some plans to make the TLA's jobs practically impossible. You should consider implementing some of these as well:
Encrypt one-time pads before transit on portable media using a cascade stream cipher with independent keys e.g. Skein-512 XOR Keccak-512 XOR Plaintext. The keys themselves can be protected by 40 char+ password, key file and slow PBKDF. The key file can be a long salt for the PBKDF and hidden separately.
Encrypt and authenticate the one-time pads as they reside on the end points using the same method. Don't discount the TLAs getting malware or cameras in via physical infiltration at your house if they detect you're using such protocols.
Encryption of the client-server protocol using the same cascade stream cipher and MAC. The server and clients can have pre shared keys and decrypt/decode the packet to decide which user it's meant to go to. The server responds with the same encryption. Therefore all a TLA sees is a socket being opened up on a user chosen port, then an IV + ciphertext concatenated together in Base64 being sent across the internet to some IP address. They have no idea who the packet is for, what chat group it's for or what encryption protocol is being used exactly. The server acts as an encrypted switchboard. Only the users of the server have the key to communicate with the server. It's important to disguise any meta data which could allow TURBULENCE, TURMOIL and TUMULT to distinguish it from other regular traffic and feed it into XKEYSCORE. So if you're prepending "TFC_" to the beginning of the ciphertext then that's a pretty significant clue. Even subtle protocol details which make it unique from other regular traffic helps them. If they don't know exactly what protocol you're using then it's much harder to target you with an automatic exploit and exfiltrate keys.
Send fake messages at random intervals. The other client will know they are fake and can ignore them automatically. Traffic analysis meta data (how often and when users are communicating) is almost as important as the contents.
Use anonymous proxies like Tor so all traffic goes over the anonymity network. Even the server could be running on a Tor hidden server. This prevents the TLA from knowing where users are and who exactly is communicating. That way it is also harder to target the user with specific exploits, or physical surveillance.
Single use devices. The machine with the OTP chat is not used for other activities e.g. general web surfing. This prevents TLAs serving up malware from YouTube etc.