31–40 of 46 posts
Earlier quoted context omitted.
Expired certificate is probably the least egregious security error, especially for a homepage. No data is lost or stolen. Customers won't like it, you may lose sales, etc, but your data security is fine.
It's a sign of either laziness, incompetence, or lost interest, and none of those things are good.
Earlier quoted context omitted.
Aren't there multiple operating quantum computers right now? Isn't this a very imminent problem?
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" n…
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.
What is the threat model for PGP in JS? Like, is there an Alice, Bob, Carol, Eve story under which PGP in JS makes sense? The canonical example that IMO doesn't make sense is when Alice and Bob want to communicate privately using Eve as an webmail provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of OpenPGPjs in a tag on EveMail.com, because then they're trusti…
One user story is that Alice uses Eve's webmail, and Bob uses PGP and mutt on his laptop. Before Eve's webmail supported PGP in JS, Bob had to send his emails to Alice unencrypted (and unsigned), which meant his mail provider could read the plaintext (even if he trusted that mail provider to always require a TLS connection when sending to Eve's servers). From Alice's point of view, she is just using webmail as she al…
If Carol or Chuck can spoof Eves "identity" they can spoof Bobs identity. This can be done in a multitude of technical or social ways.
Is it better to have this than nothing? The problem is that you have to trust your whole infrastructure if you want to do this kind of client side encrypting.
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…
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.
What is the threat model for PGP in JS? Like, is there an Alice, Bob, Carol, Eve story under which PGP in JS makes sense? The canonical example that IMO doesn't make sense is when Alice and Bob want to communicate privately using Eve as an webmail provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of OpenPGPjs in a tag on EveMail.com, because then they're trusti…
One would of course still need a protection against key logging etc. (eventually the web extension has relevant matter only in a pop-up?)
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…
> 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…
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.
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…
Not what I've heard.
https://threatpost.com/nsas-divorce-from-ecc-causing-crypto-...
Earlier quoted context omitted.
> 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…
> 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 comment about post quantum crypto did not relate to ECC directly. I just would like to see some PQ crypto in OpenPGP :)
Earlier quoted context omitted.
One user story is that Alice uses Eve's webmail, and Bob uses PGP and mutt on his laptop. Before Eve's webmail supported PGP in JS, Bob had to send his emails to Alice unencrypted (and unsigned), which meant his mail provider could read the plaintext (even if he trusted that mail provider to always require a TLS connection when sending to Eve's servers). From Alice's point of view, she is just using webmail as she al…
> [Alice knows] no one (other than Eve) can spoof Bob's identity If Carol or Chuck can spoof Eves "identity" they can spoof Bobs identity. This can be done in a multitude of technical or social ways. Is it better to have this than nothing? The problem is that you have to trust your whole infrastructure if you want to do this kind of client side encrypting.