Most interesting e2e projects have abandoned email, specifically SMTP, as a secure messaging platform. I would look outside SMTP-based solutions if I were to start using a different project (assuming doing so is an option... I hope it is!).
A big problem is that a lot of this is driven less by people who have a genuine need for encrypted communication and more by people who want one on principle. And the latter tend to include the people who are more likely to try The Next New Thing.
And it also makes sense. A lot of these services are from companies that need to make money. And there isn't much money in the journalists and dissidents who don't have a bespoke solution.
Signal is nice, and I use it. But it's an instant messaging system. Email has different use cases.
I think what we're going to need is a new, non-SMTP protocol, which preserves all of the good things about email, while providing e2e encryption and (pseudonymous) identity assurance. I don't know enough to be involved in designing that protocol, though, other than saying what I want to see as an end-user.
pond has interesting properties, I think the next generation mail will have to implement some of those ideas.
and Signal/WhatsApp comes to replace (and kill) xmpp, not email. Another issue is the generational shift away from email, that is only for Spam and Work, more and more everytime...
Cross-platform (Chrome web-apps don't count), Federated, Distributed, to name a few. The reason email is so entrenched is probably because of these reasons entirely. Being able to send a message from any provider to any provider certainly helped spread adoption easily.
There are protocol properties, and client properties. I think some of both are important.
### Protocol
* Easily federated
* Identifiers can be memorable/meaningful (unlike phone numbers) while still being globally unique (thanks to federation)
* Device independent (not tied to a phone number, can generally use the same account on different devices)
* Can contact people you don't know/haven't met (this is possible with Signal, but they'd have to publicly share their personal cell phone number, which is a no-go).
### Client
* Optimized for longer-form, less immediate messaging (folders, drafts, rich text)
* MIME attachments (Signal supports only a limited number of predefined types of attachments)
I feel like you could probably layer an email-equivalent on top of Matrix, but I'm not 100% sure about that.
The author of the article mentions Signal as well, but how do you handle communication from a laptop or desktop computer and/or with people who don't own an Android or IOS smartphone?
Signal does have a desktop application. I believe you can also register a Signal account using a phone number from a service like Twilio. I'm not 100% sure that will work with Signal desktop though.
Signal in a chrome app can pair to signal on android/IOS. But I don't believe you can use chrome only. The chrome app just waits for you to pair with a phone and can't send/receive messages until you do so.
Praetorian | Security Engineer | Austin, Texas | REMOTE (For principal and staff positions)
Praetorian is different. We are a collective of highly-technical engineers focused on helping our clients solve their most difficult security problems. Rather than break things over and over, our goal is to have an actual impact in making the world a better place. 100% privately owned and self-funded, we are focused on doing the right thing over short term profits. Where other companies pay lip service to vision statements and principles, we are unwaveringly guided by our core values, which are:
* Put the client first - Everything else will work out.
* Enjoy the work you do - Passion eats education and experience for breakfast.
* Be humble - True significance is only achieved as a team.
* Embrace the wobble - There is existential urgency to our work. We need to move and adapt quickly.
* Walk with a swagger - Relish the new challenge.
* Default to open - The right decision is in the data. Share all of it.
* Orient to action - Do not wait to be directed. Engage.
* Performance matters - We are a small company intent on doing big things. Every individual effort counts.
* Stop evil - Our mission is to make the world a safer and more secure place.
* Make craters - Our time on this earth is short. Leave an impact.
Although small, we are growing rapidly, with 50% YOY growth for the past three years. That growth is based on fantastic clients and their support. Our annual net promoter score is consistently over 80%. By comparison, Apple is typically in the mid 70s, and Amazon is usually in the high 60s.
We are looking for experienced engineers that share our values. We offer our staff a generous benefits package, including:
I think a password manager (minus some of the scary bits like browser plugins) is a much better option than a mental password generation scheme. Maybe some folks can handle this but I think this is a non-ideal general recommendation.
I think you're missing the implication in the original comment, that the NSA has put a backdoor into NIST and the Russian equivalent has put a backdoor into GOST, but neither can use the other's backdoor.
I cannot tell you how silly this is. If you're using GOST, you're no longer building NIST-compliant crypto. If you're using NIST, you're no longer building GOST-compliant crypto. For Christ's sake, just stop using standardized crypto if you're worried about backdoors like this. Use an eSTREAM portfolio cipher for bulk crypto, use Blake2 as your hash, and use Curve448 for key agreement and signatures.
You can just use the Noise protocol framework to accomplish this, which was designed to use all of these components.
It's still NIST compliant crypto on the outside regardless of the inner contents. Assuming NIST(GOST(plaintext)), NIST would be terribly broken if using GOST ciphertext as the payload weakened the security.
It's crypto 101 that, given a ciphertext without the key, an algorithm's correct input should be indistinguishable from random input of the same length.
I'm shocked that you think the plaintext contents would have an affect on whether or not something is NIST compliant.
I don't follow this objection even a little bit, but I'm also not very motivated to try, so: no need to clarify. I'm just going to reiterate.
I am making a very simple point. If you don't trust NIST standards because you think they're backdoored, but won't run Russian standards because you think they might be too, the answer isn't to compose the two flawed standards.
Instead: just use a crypto stack composed of well-reviewed, well-regarded components that are neither NIST nor GOST standards.
Nobody in the world thinks Curve25519 is backdoored, or that Chapoly is, or that Blake2 is.
In fact: this is what I think you should do anyways. Maybe, just maybe, you should keep using AES because it will be more performant --- but the cycles/byte cost of bulk encryption is so low that I'm skeptical that this matters. Otherwise: avoid crypto standards like NIST and GOST. Standards processes produce crypto that is at best ungainly and at worst actively harmful. Standards are evil.
I am, of course, addressing this advice to the very, very limited subset of engineers who should be working with crypto directly. Everyone else should just use Nacl.
If you think standard A is good except for a potential backdoor with the key held by entity X and you think standard B is good except for a potential backdoor held by entity Y and you assume entity X and entity Y do not cooperate, then composing A and B is completely reasonable.
It's the same thing as having 3 computers vote on the space shuttle control signals. You could follow your argument and claim, "If the software has a bug in it that would produce output different from the other 2, then don't use it!" The problem is that we don't know if there is an issue or not, so we go the safer route with multiple implementations.
You also did not address the main issue I have with your comment. You made this assertion: "If you're using GOST, you're no longer building NIST-compliant crypto.", which implies that the contents of the plaintext determine if the crypto is NIST compliant. This is completely false.
It's like claiming that uploading an AES encrypted file over an HTTPS connection is less secure than uploading via HTTP.
Considering only the secure channel problem and not the entire systems problem (which might motivate encrypting clientside in anticipation of the file being stored), encrypting before sending on a secure channel is indeed pointless, which is the reason you'll find very few soundly designed cryptosystems that do this.
The point is again simple: there are far better options to untrustworthy standards than composing them in the hopes of mitigating their flaws. It's for the same reason that we used to use hash combiners to handle MD5 and SHA1, but now we use HKDF over SHA-2.
>which is the reason you'll find very few soundly designed cryptosystems that do this.
Nearly every secure system I've dealt with (in the military side) encrypted at the network layer (VPN) and they sent encrypted files over that channel.
Yes, because (as I just said), encrypting files mitigates systems problems outside the scope of the secure channel problem. A secure channel doesn't help you if the bag of bits you send down it ends up persisted on an exported, unencrypted filesystem.
That doesn't mean that redundant clientside encryption of files is a sensible feature for a secure channel to have.
As far as I know almost all browser security warnings are overridable. The only one that comes to mind that does not have a click-through option is when a HSTS-enabled site fails a validation check.
My understanding is that you can't know that nothing bad is actively happening with the connection since SHA-1 is no longer a strong hash, so it's basically (hand-wave) no different from an HTTP connection.
So why don't they present any warning on HTTP connections?
It's not "basically no different" from an HTTP connection, it's strictly better than an HTTP connection, but not as good as a cert made with a more modern hash. (For that matter the same argument applies to self-signed certificates: you're still keeping a third party from snooping on the phishing attempt the MITM is giving you, which is itself a Good Thing.)
All major browsers are moving towards this. Starting with the tiny icons changing colors they are beginning to make HTTP as insecure. Yes, it's very slow but at least they have started moving.
I just went digging through the about:config options and couldn't find a way to force SHA-1 off. Why are they gradually rolling this out to beta users if they've purposely downloaded the Developer Edition?
This is a common theme in this thread but I'll re-state it here:
Web browsers cannot reliably distinguish between a configuration mistake and an attack.
For this reason, I think hard HPKP fails are a good thing. For those who opt-in to HPKP, this is a risk one takes in exchange for greater control over certificate validation.
I do not think your analogy applies here. Finding 8 critical-risk bugs in a project from an audit is bad news. It is highly suggestive that the codebase is riddled with flaws.
that's interesting. I'm running a 2 year old Xperia Z3 and it never occurred to me that my CPU might be the issue, but SC seems to handle audio quality just fine
Praetorian | Austin, Texas | REMOTE (For principal and staff positions)
Praetorian is different. We are a collective of highly-technical engineers focused on helping our clients solve their most difficult security problems. Rather than break things over and over, our goal is to have an actual impact in making the world a better place. 100% privately owned and self-funded, we are focused on doing the right thing over short term profits. Where other companies pay lip service to vision statements and principles, we are unwaveringly guided by our core values, which are:
* Put the client first - Everything else will work out.
* Enjoy the work you do - Passion eats education and experience for breakfast.
* Be humble - True significance is only achieved as a team.
* Embrace the wobble - There is existential urgency to our work. We need to move and adapt quickly.
* Walk with a swagger - Relish the new challenge.
* Default to open - The right decision is in the data. Share all of it.
* Orient to action - Do not wait to be directed. Engage.
* Performance matters - We are a small company intent on doing big things. Every individual effort counts.
* Stop evil - Our mission is to make the world a safer and more secure place.
* Make craters - Our time on this earth is short. Leave an impact.
Although small, we are growing rapidly, with 50% YOY growth for the past three years. That growth is based on fantastic clients and their support. Our annual net promoter score is consistently over 80%. By comparison, Apple is typically in the mid 70s, and Amazon is usually in the high 60s.
We are looking for experienced engineers that share our values. We offer our staff a generous benefits package, including:
* Competitive salaries
* Quarterly bonuses, 4% 401k matching, stock options
* Health insurance, and options for vision, dental, ADD, Short term disability, and life
* 20% Bench time for research, tool development, or training
* Flexible vacation policy
* Low travel requirements. Seriously. No more than 20% for those in network security and nearly 0% for those in application security.
* Company contributions to training and conferences
* Opportunities for rapid growth and advancement based on merit.
This one seemed interesting so I gave it a bit of effort. The ad is well written and pulls the right levers. Well done on that front.
I'm a bit disappointed in the challenges page. The copy on the site tries to emphasize how difficult they are and that anyone who passes the challenges would be considered a serious candidate. While they were fun challenges, they're way too easy.
I completed multiple challenges then sent along my information. As soon as they saw a resume that didn't include much experience in the security domain, I was basically ignored.
Recommendations for Praetorian:
If you want the challenges to mean anything, make them more significant so that completion would actually be a strong positive signal for the candidate rather than a BS-detector. If someone passes your challenges, you should be begging them to work for you, not the other way around.
Cut back a bit on the elitist rhetoric, it is a bit of a turn-off. I think it will attract more mediocrity and scare away some great talent.
Final word: the challenges are fun for anyone and if you like that kind of thing, you will enjoy beating them.
I am bummed that you got the impression that you felt ignored for not having security expertise. I am not certain when you applied but I know our focus lately has been on senior engineers so that likely contributed to our response. Regardless, if we didn't do a good job relaying that information to you that is not good and I personally apologize (it was likely my fault as I handle a good chunk of the initial responses to applicants).
Thanks for the feedback though. It is appreciated.
I'm not sure about Microsoft, but Google supports several other 2FA mechanisms in addition to SMS.