But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.
>...pretty much any E2E system is falling under this definition.
The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.
If, say, Signal was completely controlled by the CIA[1] and was thus evil, then having incoherent cryptography as described in the article would be a feature, not a bug. Being able to reject law enforcement requests would produce a false sense of security for the people the CIA was interested in surveilling. Responding effectively to law enforcement requests would reduce the value to the CIA of the ability to secretly backdoor Signal.
This effect was seen in the Apple vs FBI incident described in the article. The public perception of Apple as a brave defender of user privacy was greatly increased due to that dispute. For all we know, the FBI was in on the conspiracy. In return they might receive the fruits of such surveillance with the only limitation that they would have to disguise the source with parallel construction[2].
How about GPG distributed with a Linux distribution like Debian as a counterexample? It would be fairly difficult to backdoor GPG in that case without getting caught. Everything happens in the open both at the GPG level and the Linux distribution level. The binaries are signed by the distribution and are distributed by a bunch of mirrors. An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
The linked article makes the argument that looking at the BSD licensed example code in the RFC that defines Opus would mean that code written based on that understanding would be a derivative work and would have to be BSD licensed. This seems to have something to do with the fact that "clean-room design"[1] is a thing. But as the Wikipedia article points out:
>Clean-room design is usually employed as best practice, but not strictly required by law.
As the article points out, if this was actually true then we could change the licensing on code examples found in RFCs to fix the issue, but there doesn't seem to be any actual issue here. Imagine a world where simply reading some code caused licensing issues...
A signature is not authentication in itself. It is only such if the signing entity is in some way restricting what it is willing to sign. The domain part of the email address in the "From" field is so restricted. The signing MTA will only sign domains that it controls. Otherwise it would suffer a loss of reputation. The user part of the address is not so restricted.
The name part of the email address is also part of the same signature but is not being authenticated either.
It will be interesting to see if Google can be convinced to move away from ARC to something else. Gmail is all about email server reputation these days so they can reliably treat email servers they don't like badly.
>Anyone can put anything in the “From” field of an email.
... and then the article goes on to talk about SPF, DKIM and DMARC which authenticates only the domain part of the "From" field. So just the reputation of the email server, not the entity that sent you the email. If things get as bad with AI generated deception as suggested by the article this wouldn't be good enough, we would have to start signing our emails again. Emails from entities we don't know would have to be treated with a high level of suspicion.
I am not convinced that things will for sure really get that bad. How can a AI figure out the email addresses of our correspondents? They are not magic.
If you specifically mean something that can embody Shor's algorithm, it is fairly clear these days that a fundamental breakthrough is required. So the timeline extends from tomorrow to never.
Gmail is one of the shoddiest of the ultra-cheap email providers. If you use Gmail, a significant number of messages will disappear. They don't go to junk, they just disappear. Gmail will reject messages for obscure technical reasons. They recently decided that they would no longer accept messages signed with 1024 bit RSA DKIM. So, with no public announcement they just turned on the restriction. I found out about this from a random Mastodon poster who wasn't really sure what was going on. The error message returned to the sender gave no indication at all.
Gmail is the email provider for people that like to claim they never got the email. Google has somehow made the most reliable messaging medium, unreliable.
It is obvious that Google simply doesn't care about email. So it makes perfect sense for them to use Gmail to promote something that they do care about.
I guess there is an interesting possibility here. Perhaps the targets were encrypting end to end (that is more or less the default now with XMPP clients). With the TLS over top of everything the attackers would not know that. Perhaps they went to all this trouble for nothing.
>That technology overlaps only partially, at best, with what’s used in quantum processors.
Dunno, how can you say that for sure when we don't actually know how to make a practical quantum processor? The bigger issue is that we are scaling up manufacturing of approaches that have not been made to work.
I remember a meeting where the project manager pointed out that we were due to send some test boards to a customer. I pointed out that we didn't have a design yet. The PM then asked why we couldn't send them some boards anyway. I suggested that since the boards wouldn't work that we could just cut out some green cardboard and add some component shapes with a magic marker thus saving significant time and effort.
It turned out that I was not as funny as I thought I was...
A cryptographic identity is a public key as used in a public key signature scheme. So a particular person is represented by a ridiculously long number. That number can be shortened with some sort of hash to a shorter value to make a key fingerprint, which is a shorter ridiculously long number.
The scheme described in the system seems to use a blockchain to create a shared mapping between a name and a cryptographic identity. So a third party is still in control of that mapping, but there are a lot of third parties and most of them would have to conspire to forge a mapping. Then you could send a message to a name, rather than a number, with confidence that someone in the past picked that name and locked in the mapping between that name and the cryptographic identity.
The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thing. If you query several keyservers you can be reasonably sure that someone mapped a name (and email address) to a particular cryptographic identity sometime in the past. A single server operator can not forge a mapping without the possibility of that forgery being detected.
The thing is, people don't actually want a reliable name to cryptographic identity mapping service for end to end encrypted messaging. They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.
>IBM is developing four custom ASICs — a decoder, a two-qubit gate controller, a single-qubit controller, and an amplifier — designed to handle quantum control at scale, with these circuits expected to converge around 2029 at the point where power consumption becomes manageable at up to 3 megawatts per system.
The current hotness seems to be based on creating pairs of entangled qubits based on what might be realistically achieved with error correction. Shor's requires thousands of entangled qubits (something like 4000 for 2K RSA and 1500 for 256 bit elliptic curves).
So unless someone comes up with a way to break cryptography using pairs of entangled qubits then this probably isn't relevant.
>On superconducting architectures with 10−3 physical error rates...
So still 1-2 orders of magnitude better than what we can achieve.
This is against a 256 bit elliptic curve. For some reason most people are stating the difficulty of using Shor's against 2048 bit RSA. Elliptic curves are easier to break with Shor's. I wonder how much of the optimization came from that fact alone...
That isn't true for either thermal or electrical conductivity. So I don't know what is meant here.