RIP, Dan. I work with a lot of very smart people. So, I've gotten a bit used to it and don't normally find myself in awe of many people's intelligence. Dan was a person that I was absolutely in awe of. The fist time I met him very long ago (almost 20 years), he showed me code he wrote to share movies through abused DNS slaves... building a p2p network like Napser/Gnutella from the technology. No one had ever thought of such a thing. I don't think anyone else in the world knew DNS well enough to be inspired to think of it. He was so kind and friendly to everyone. It was fun to talk with him about tech/security because he had such enthusiasm and excitement... like a little kid on Christmas or a puppy. :) I learned a lot from him. I have nothing but great memories of him. I remember once when someone hacked him. He even took that in good humor and didn't let it bother him.
Possibly. There is very little to no private funding for true privacy products. I think this is one of the reasons that Proton had to initially rely on crowdfunding. Perhaps, this is because so many tech companies are stuck in the AdRev mindset where sharing customer private data is how they make their real money? If you look at the ecosystem, you see many privacy products are actually government supported either directly or indirectly. For example, the Tor Project has directly taken massive amounts of funding from the US Military and you may recall the story of how Microsoft was forced to buy Skype in order to open it up to surveillance or lose massive amounts US DoD software license contracts. Those are just two examples. But, there are really limitless cases. Trust Google? But, Google receives massive DoD/EU contracts. Apple? Same thing. Role your own? But, nearly all standard encryption and hashing algorithms were either developed by or reviewed by government funded academic researchers in the US or EU.
The way I think of the privacy ecosystem is that it makes dragnet surveillance much harder and it provides some protection if the government has specifically targeted you for data collection. So, companies/products like ProtonMail and ProtonVPN are good things. But, creating something that is 100% safe for the individual is impossible (or at best so impractical to be untenable).
This tactic has been used against companies friends of mine have started. I've only seen it used by large 20+ year old 1970s/1980s publicly traded companies, never someone like Tesla. The way it works is basically that you track where your ex-employees go after they leave. If they go to a competitor/disruptor start-up with out deep pockets, sue that competitor over trade secrets. It's nearly impossible to disprove in court. The competitor start-up exhausts its VC/Angel money on legal fees and goes bankrupt. Potential new customers are wary of using their tech because of the lawsuit. It's a lethal combination that ensures that you don't have to out innovate them. Stealing source code is one thing. I certainly understand suing over that. But, suing over stealing ideas about warehousing from a car company? Really? I don't see any justification for that other than a lack of faith in the ability of your own company to compete and innovate.
Full disclosure: I am shorting TSLA stock. I have worked on autonomous vehicles and do not believe Tesla's claims about their technology. I expect Tesla to go bankrupt sometime in the next few years. I'm even more convinced of this now that I see them using company-killer lawsuits against other competing start-ups.
If you are a relatively new company, getting on stable ground, would you appreciate it if someone stole your IP and then proceeded to copy you, and get a huge boost past the part that nearly bankrupted you and left you homeless? That's not very fair to me, either.
Full disclosure: I do agree that there is such a thing as going overboard, but when your top engineers get recruited to a new company doing the same exact thing and take their laptop with them, that's a bit much. Especially when they load up all their drives with documentation before they leave.
Then you are financially motivated to spew lies. Short sellers are probably the scummiest people on the planet, that will do anything to make a quick buck.
Tesla has done this previously a meritless trade secrets theft case against Henry Fisker after he left the company, and later against Aurora innovation, a company cofounded by Sterling Anderson, a former director of Autopilot.
In case anyone that doesn't follow the development of the library closely missed it, the main improvement in this version is the introduction of ECC support. ECC tends to be able to provide equivalent levels of security as traditional "big prime" cryptography (like RSA) with less computationally intensive operations. This is especially important in a library like OpenPGPjs that is primarily meant for in browser based web usage because it should make things, like sending and receiving mail, faster when ECC is used over older PGP public key encryption systems. For people that use ProtonMail's web based crypto on mobile or tablet devices, a switch to ECC would result not just in similar performance improvements but also in lower battery usage.
Currently, ProtonMail uses RSA keys, but this addition of ECC support to their web encryption library may mean that they are about to start switching users to ECC keys. Because using "larger" (when compared with equivalent theoretical strength RSA keys, for example) ECC keys is less resource intensive than using higher security keys in some other forms of cryptosystems (like RSA) it may also be an indication that ProtonMail is preparing to upgrade users to higher security/stronger keys.
Many cryptographers and organizations, including the US Government, have recommended for a long time that people migrate from older "big prime cryptography" based cryptosystems to ECC based cryptosystems for increased security.
>Many cryptographers and organizations, including the US Government, have recommended for a long time that people migrate from older "big prime cryptography" based cryptosystems to ECC based cryptosystems for increased security.
> Many cryptographers and organizations, including the US Government, have recommended for a long time that people migrate from older "big prime cryptography" based cryptosystems to ECC based cryptosystems for increased security.
Personally I'd stay away from NIST recommended curves for long term keys (as used in OpenPGP). Ed25519 looks nice and there is experimental support for it in gnupg but it's not post quantum unfortunately.
> Ed25519 looks nice and there is experimental support for it in gnupg but it's not post quantum unfortunately.
That's not a problem of NIST recommendations. There aren't any post-quantum secure elliptic curve public-key systems. The fundamental computational problem used by ECC public-key cryptography isn't post-quantum secure, so it's not really a matter of curve choice.
The problem with NIST curves (vs ed25519) is the choice of parameters (it is not clear why they have such and such values) and the implementation edge cases. You already know it but maybe someone else will find it interesting: https://safecurves.cr.yp.to/
The comment about post quantum crypto did not relate to ECC directly. I just would like to see some PQ crypto in OpenPGP :)
> In case anyone that doesn't follow the development of the library closely missed it, the main improvement in this version is the introduction of ECC support.
Wow...I'm sort of shocked that wasn't a v1.0 consideration.
> ECC tends to be able to provide equivalent levels of security as traditional "big prime" cryptography (like RSA) with less computationally intensive operations. This is especially important in a library like OpenPGPjs that is primarily meant for in browser based web usage because it should make things, like sending and receiving mail, faster when ECC is used over older PGP public key encryption systems. For people that use ProtonMail's web based crypto on mobile or tablet devices, a switch to ECC would result not just in similar performance improvements but also in lower battery usage.
In particular, elliptic curves have smaller parameters, which allow for smaller keys at the same bit security level. For example, to achieve 128-bit security, an RSA/DLP modulus must be 3072 bits. Elliptic curves achieve the same security level with only 256-bit parameters. They are also faster for most operations, but RSA is still technically faster for signature verification.
> Many cryptographers and organizations, including the US Government, have recommended for a long time that people migrate from older "big prime cryptography" based cryptosystems to ECC based cryptosystems for increased security.
True, but elliptic curve cryptography is just as vulnerable to quantum computers, however long off that problem may be.
> Wow...I'm sort of shocked that wasn't a v1.0 consideration.
Given that you need to pass --expert to gpg 2.1 as of right now to even generate an ECC keypair for PGP use (nor use one on an OpenPGP smartcard or yubikey), I can sort of forgive the lack of ECC in 1.0. I don't think it sees wide usage for PGP keys (some clients don't support it, also).
However, as of the last time I tried Protonmail (about 10 minutes ago to check this is all still true) you can't: revoke/reissue your PGP key, validate outside signatures (either on encrypted messages or signed, plaintext messages) or send pure-PGP mail to users outside of protonmail (there's an encrypt for non-protonmail users option, that sends a link instead). Essentially as another commenter has said, you can't really do PGP with ProtonMail.
I don't use ProtoMail but it sounds like they are "managing" users' private keys!? Am I understanding this correctly? ProtonMail has access to their users' private keys? And they are using web-based encryption, delivered via JavaScript?
Yes and no. To simplify matters, you need not just a quantum computer but such a machine with the right sort of qubits. The right sort of qubits being logical qubits, not physical, many of which are needed for error correction.
It's not clear whether we can currently create a machine with sufficient logical qubits to run Shor's algorithm in a meaningful way.
However, out of an abundance of caution, we're "starting" now (some designs have existed for longer but this (NIST PQC) is the first competition, which focuses minds) so as to have something ready when/if a quantum computer becomes a reality.
A DARPA researcher explained to me that a quantum computer's qbits would have to be 99.9999999999% error-free (that's 12 nines) in order to perform the necessary steps of Shor's quantum factorization algorithm. Current state of the art qbits are 99.9-99.99% error-free. Basically, we have a long way to go.
I wouldn't say no one. There are a number of companies that trust Bitcoin enough to use it in trade for their goods and services. For example, ProtonMail (a secure private e-mail provider) trusts Bitcoin enough to accept it in trade for its services.
So, the same thing that gives the Euro and Gold value (that people will take it trade for goods and services) is one of the components accounting for Bitcoin's valuation. The majority of Bitcoin's value at this point is likely speculation. However some percentage of the value is not derived from currency arbitrage or speculation.
Even if Bitcoin trade participating merchants do not trust the market valuation of Bitcoin enough to be willing to hold Bitcoin for very long after they accept it as part of a transaction (and therefor immediately convert it to USDs) it is still valued by the participating merchant in line with the trade. The same could be said for the value of the electronic ledger recordings created by credit cards. They are generally viewed to have around equivalent value to USDs. But, they are not a currency either.
I would drop Signal for that app, even if I had to pay for it.