The name part of the email address is also part of the same signature but is not being authenticated either.

https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...

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.

... 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.

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.

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...

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.

Comments URL: https://news.ycombinator.com/item?id=48199855

Points: 1

# Comments: 0

https://nxdomain.no/~peter/time_for_opensmtpd.html

I tried using OpenSMTPD a long time ago, shortly after it came out, but things were not stable enough. I guess it is time to give it another go...

>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...

I doubt that there is an implementation left that does 3DES by default.

It would be nice to update the standard to make AES required to be available for decryption. I really wish that the most recent standard update attempt had restricted their scope to such uncontroversial changes before going to war over the controversial changes.

Your example mentions 3DES. 3DES is secure. The reason it is not recommended is because 128 bit block lengths allow longer file/message lengths than 3DES can accommodate on one key. At any rate, RFC-4880 permits the use of AES and that is what is normally used.

Fortunately we can use the existing standard (RFC-4880) in a way that is completely secure. Remember, we are talking about the standard that was in effect when the Snowden leak revealed that PGP is on a very short list of things the NSA has no access to. There is no reason to think that has changed since then.

Not that there is anything wrong with SHA1 fingerprints in practice. The sort of collisions that SHA1 is susceptible to are not an issue in this particular application. With SHA256 fingerprints people would still be using 64 bit key IDs, just like they are doing now.