The security industry is full of "ex-NSA hotshots". Having worked at NSA is hardly a powerful hook for an article. For starters: only a tiny minority of those working in tech at NSA are experts on encryption.
... and given that Ackerly was first in IAD working on cross-domain solutions and then SNIP, I doubt he is an expert on encryption.
What do you think of Virtru? I was hoping you would comment on this article since you're an actual crypto expert.
Encryption-by-plugin seems less bad than encryption-by-javascript, but their entire business model depends on us trusting Virtru for key escrow. This doesn't seem any better than trusting Apple for iMessage or Google for Gmail. Am I missing anything?
Edit: I guess a malicious attacker would need to take two steps for the information. One for the encryption key hosted at Virtru, then a second step to actually capture the emailed message.
I trust an expert in cross-domain over an expert on encryption any day. Having done cross-domain design, I know you have to look at the system holistically from the hardware up and at every interface (eg protocol). Most flaws in crypto are implementation and protocol issues. So you want someone whose regularly coding and hacking systems to build that rather than people looking at math all day. He can hire a real cryptographer to review and improve his algorithms as his business brings in revenue. Implementation and interfaces, though, are where risks are and his strength.
The key escrow bothers me, too, though. It requires key escrow without a HSM (far as I know) and under U.S. jurisdiction. Plus, a high assurance system resistant to nation-states is time-consuming to put together. Their development speed, client support, and price indicate they're using a low assurance process with mainstream components. So, their escrow is at risk to both a court order and hackers. Not to mention malicious insiders.
I need more details that I can't find in their FAQ[1] and it's not all open source yet[2]. My main question is about metadata which you cannot really protect that well w/ how SMTP works. The second question would be how different this is from PGP/Mailvelope[3] and where the keys are stored for a user (i.e. the "trusting" you are talking about).
I think the details they give support that description well. He'd probably be a trip at a Makerspace or something. Relevant to this product, it's saying he can probably code up something pretty good based on that track-record and initial reviews support that. However, making a secure system or product requires a lot of expertise that most in NSA don't have because NSA largely got rid of that expertise like everyone else. IAD mostly just does the reviews of high security stuff with contractors having the few people that build it. An example of their high assurance work is the Inline Media Encryptor. They're usually pushing garbage like VMWare mods and SELinux, though, presumably to weaken us. So, I agree with you that "ex-NSA" means little to nothing without lots of extra context. We got that context in this article, though.
Solving secure email in a strong way takes incredible expertise in the email standards, common ways their implemented (prevent breaking stuff), OS interfaces, language, some cryptography, and protocol design. Every strong, usable product w/ legacy compatibility has a whole team backing it with a track record in these. They're also expensive. So, I have my doubts any time I see something like "these few people will solve secure email, on every device, and for only $48 a year." Unlikely lol...
A good understanding of how email protocols work, their risks, and why certain tradeoffs are made in practice. It helps inform the designer of how to best secure them without breaking stuff. Just using 3rd party libraries or throwing shit together hoping for the best isn't safe in high-security engineering.
I'm not sure about "incredible expertise", but to illustrate with some - rather basic - points that I've seen people miss:
- mailbombs exist
- you can generate input that takes a lot of memory and/or CPU to process for almost any real-world parser - DoS is usually trivial (and compromise is within reach of advanced adversaries)
- you really want to limit the depth to which you parse MIME, doubly so if the parser is recursive
- decoding headers is really hard even if you just decode everything to UTF-8
- just because something claims to be text/plain doesn't mean that it's actually 7-bit, actually the character set it claims to be, doesn't contain any "interesting" Unicode characters, etc etc etc.
- receivers can and do MIME-sniff
- UTF-8 is actually pretty damn scary (rendering an arbitrary bytestring as UTF-8... should be safe, but there is at least one Linux graphics toolkit that will just not show the textfield if you include any application-specific characters, and rendering combined characters has had bugs in the past)
- ...
I assume you're familiar with the above; I just mean to point out that securely handling e-mail is hard.
I have a way with bumbling choice of words haha. How about "plenty of expertise" instead?
I was familiar with some of that but not others. Thanks for the list both for the extra details I learned and so people new to this will see some of the gotchas. Curious, has anyone put together a comprehensive treatment of most of the issues and solutions that you know of?
Standard Mail Guard [1] and GEMSOS [2] (esp crypto seals) informed my approach. I just applied what I could of that (minus MLS) to build a proxy that just wrapped them up and sent them through a guard. Still had to deal with headers, transport was way easier, and left most to the client. The best example I know in commercial space that does it similarly (probably better) is Nexor [3]. Especially with Sentinel. Such architectures let designers make many tradeoffs in security vs performance vs compatibility. Simplistic example: security stuff in dedicate process might let me use safer language, better verification tools, MAC policy, compiler obfuscations, etc. Wouldn't be as easy if operating within the client's privileges or language.
I'm not aware of any comprehensive list, although I must admit that I haven't looked very closely. I am somewhat familiar with the concept of a mail guard, yes. ;-)
Oh shit: you work at Fox. You might be familiar with a few worthwhile concepts haha. Always good to run into others in the high-security field as there's so few these days. I did contract work that built into other's stuff but now days mostly do high-security R&D, recommendations, and evangelism. I give Fox a mention here and there on forums because they seem to know what they're doing with talented people. Hard to be sure with black boxes but seeing physical separation and a trusted path on RedFox was a good sign. Esp given most security devices don't have it. ;) Btw, is the trusted path the UART or done on GPIO's?
Note: I keep my designs and essays on Schneier's blog, etc just to get them out there in hopes of public benefit. I'll send you some of them if you want so long as I get credit for that part of whatever you or Fox does with them. Usually all I ask for although paid consulting is a bonus I don't turn down. ;)
I couldn't possibly comment on the RedFox - pretty much everything that's not on the website is classified or at least need-to-know, and I haven't kept very careful track of what's on the web.
I've looked at your work before, but I'd be happy to receive some more. Two points, though: (a) I'm incredibly busy right now, so don't expect a prompt response, and (b) we don't talk a lot about what we do, so don't expect to see a lot of credits in (open) print. (My apologies for both!)
Congratulations to the Virtru team for your success! I remember in 2012 when 2 of the guys were working on a cryptographic binding contract and left to join this startup.
It was a very interesting story to read. Glad they managed to build something that's is potentially strong while easy to use. That's difficult to bootstrap. Unfortunately, it's so difficult to design good cryptosystems, protocols, etc. that I can't trust the product until it gets strong, peer review from a diverse audience. Both the level of screw-ups in the field and massive investments in subversion by nation-states means a tool like this needs to be fully open-source plus local, build option. Note that they can do open-source w/ proprietary license.
The escrow is also a problem. There's the risk of hackers, malicious insiders, courts in regular legal system, and the court in the secret legal system. If you do escrow, it needs to run on the most secure and tamper-resistant systems you can throw at it w/ 3rd parties verifying this. Given above risks, it's better if they don't do escrow and instead switch to a private/public key model. Bernstein et al have given us some really fast and secure software for that, too. They just auto-generate the key-pairs locally & handle the public key management instead. Would be a nice improvement.
16 comments
[ 2.7 ms ] story [ 41.6 ms ] threadWhat do you think of Virtru? I was hoping you would comment on this article since you're an actual crypto expert.
Encryption-by-plugin seems less bad than encryption-by-javascript, but their entire business model depends on us trusting Virtru for key escrow. This doesn't seem any better than trusting Apple for iMessage or Google for Gmail. Am I missing anything?
Edit: I guess a malicious attacker would need to take two steps for the information. One for the encryption key hosted at Virtru, then a second step to actually capture the emailed message.
The key escrow bothers me, too, though. It requires key escrow without a HSM (far as I know) and under U.S. jurisdiction. Plus, a high assurance system resistant to nation-states is time-consuming to put together. Their development speed, client support, and price indicate they're using a low assurance process with mainstream components. So, their escrow is at risk to both a court order and hackers. Not to mention malicious insiders.
I'll pass...
1 - https://www.virtru.com/faq/ 2 - https://www.virtru.com/blog/virtrus-open-source-strategy/ 3 - https://www.mailvelope.com/
Solving secure email in a strong way takes incredible expertise in the email standards, common ways their implemented (prevent breaking stuff), OS interfaces, language, some cryptography, and protocol design. Every strong, usable product w/ legacy compatibility has a whole team backing it with a track record in these. They're also expensive. So, I have my doubts any time I see something like "these few people will solve secure email, on every device, and for only $48 a year." Unlikely lol...
- mailbombs exist - you can generate input that takes a lot of memory and/or CPU to process for almost any real-world parser - DoS is usually trivial (and compromise is within reach of advanced adversaries) - you really want to limit the depth to which you parse MIME, doubly so if the parser is recursive - decoding headers is really hard even if you just decode everything to UTF-8 - just because something claims to be text/plain doesn't mean that it's actually 7-bit, actually the character set it claims to be, doesn't contain any "interesting" Unicode characters, etc etc etc. - receivers can and do MIME-sniff - UTF-8 is actually pretty damn scary (rendering an arbitrary bytestring as UTF-8... should be safe, but there is at least one Linux graphics toolkit that will just not show the textfield if you include any application-specific characters, and rendering combined characters has had bugs in the past) - ...
I assume you're familiar with the above; I just mean to point out that securely handling e-mail is hard.
I was familiar with some of that but not others. Thanks for the list both for the extra details I learned and so people new to this will see some of the gotchas. Curious, has anyone put together a comprehensive treatment of most of the issues and solutions that you know of?
Standard Mail Guard [1] and GEMSOS [2] (esp crypto seals) informed my approach. I just applied what I could of that (minus MLS) to build a proxy that just wrapped them up and sent them through a guard. Still had to deal with headers, transport was way easier, and left most to the client. The best example I know in commercial space that does it similarly (probably better) is Nexor [3]. Especially with Sentinel. Such architectures let designers make many tradeoffs in security vs performance vs compatibility. Simplistic example: security stuff in dedicate process might let me use safer language, better verification tools, MAC policy, compiler obfuscations, etc. Wouldn't be as easy if operating within the client's privileges or language.
[1] https://cryptosmith.files.wordpress.com/2014/10/mailguard.pd...
[2] http://aesec.com/
[3] https://www.nexor.com/sixa-technology
(Note: I don't endorse it's assurance/code so much as architecture and strategy. EAL4+ is not high assurance lol. It's probably not cheap, either.)
Note: I keep my designs and essays on Schneier's blog, etc just to get them out there in hopes of public benefit. I'll send you some of them if you want so long as I get credit for that part of whatever you or Fox does with them. Usually all I ask for although paid consulting is a bonus I don't turn down. ;)
I've looked at your work before, but I'd be happy to receive some more. Two points, though: (a) I'm incredibly busy right now, so don't expect a prompt response, and (b) we don't talk a lot about what we do, so don't expect to see a lot of credits in (open) print. (My apologies for both!)
The escrow is also a problem. There's the risk of hackers, malicious insiders, courts in regular legal system, and the court in the secret legal system. If you do escrow, it needs to run on the most secure and tamper-resistant systems you can throw at it w/ 3rd parties verifying this. Given above risks, it's better if they don't do escrow and instead switch to a private/public key model. Bernstein et al have given us some really fast and secure software for that, too. They just auto-generate the key-pairs locally & handle the public key management instead. Would be a nice improvement.