6 ms·

Could this ex-NSA hotshot protect your email from hacking?

31 points by conorgil145 11y ago

atorralb 11y ago
nope, probably a sellout or controlled opossition
tptacek 11y ago
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.
- linkregister 11y ago
  ... 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.
  - nickpsecurity 11y ago
    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'll pass...
  - kodablah 11y ago
    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). 1 - https://www.virtru.com/faq/ https://www.virtru.com/faq/ 2 - https://www.virtru.com/blog/virtrus-open-source-strategy/ https://www.virtru.com/blog/virtrus-open-source-strategy/ 3 - https://www.mailvelope.com/ https://www.mailvelope.com/
    - linkregister 11y ago
      Virtru escrows the keys, at least that's how I interpret this diagram: https://www.virtru.com/technology/ https://www.virtru.com/technology/
- nickpsecurity 11y ago
  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...
  - tptacek 11y ago
    "Incredible expertise in the email standards"?
    - nickpsecurity 11y ago
      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.
    - JoachimSchipper 11y ago
      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.
linkregister 11y ago
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.
nickpsecurity 11y ago
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.

31 points by conorgil145 11y ago

nope, probably a sellout or controlled opossition

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.

linkregister 11y ago
... 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.
- nickpsecurity 11y ago
  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'll pass...
- kodablah 11y ago
  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). 1 - https://www.virtru.com/faq/ https://www.virtru.com/faq/ 2 - https://www.virtru.com/blog/virtrus-open-source-strategy/ https://www.virtru.com/blog/virtrus-open-source-strategy/ 3 - https://www.mailvelope.com/ https://www.mailvelope.com/
  - linkregister 11y ago
    Virtru escrows the keys, at least that's how I interpret this diagram: https://www.virtru.com/technology/ https://www.virtru.com/technology/
nickpsecurity 11y ago
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...
- tptacek 11y ago
  "Incredible expertise in the email standards"?
  - nickpsecurity 11y ago
    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.
  - JoachimSchipper 11y ago
    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.

linkregister 11y ago

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.

nickpsecurity 11y ago

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.