For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | upofadown's commentsregister

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.

Deliverability issues with which email provider(s)? Often times it turns out the problem is just with Gmail.

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.


They care about reading your emails. At this point that is why gmail exists.

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


The funding isn't going towards some hypothetical future practical quantum processor, it is going towards existing approaches that we know have different technology, manufacturing processes, and most importantly different applications than the Chips Act was targeting. Funding quantum computing research might be a good thing, but it doesn't make us any less dependent on foreign silicon manufacturing for the countless uses of computer chips across existing industry, which was the purpose of the Chips Act.

> ... the US government announced $2 billion in investments in ... a range of startups ... could be make-or-break investments for many companies that are likely years away from a product that could see widespread use. ...

The article doesn't make it sound like this is "going towards existing approaches". I totally get that you may not support these company's approaches to quantum processer design, but we'd be getting rather into the weeds if that's the hair we're splicing.


Hahaha, hilarious. I could also tell a story or two like that.

I have to say, though, I have no idea what the management is thinking when they hire such clueless PMs. Even worse, I have seen clueless product owners who had no idea about the domain we were in. I guess a recent example could be Ive designing the Luce.

Maybe I am just envious. Maybe I just wish I could BS my way through life like these characters do.


There's nothing to envy. They're a hired punching bag to put distance between you and the management.

In most cases, even the PM doesn't know this. They were specifically selected to not think too deeply. Anything you say that is brutally correct and they take the wrong way is received as mean and arrogant. Those incidents give management some ammunition if they ever want to get rid of you.


The issue at hand is what the money is being spent on today.

6x10 here. Even more text. Only readable because each pixel is completely distinct.

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.


> The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thin

> most of them would have to conspire to forge a mapping.

The mapping is recorded in an immutable ledger (bitcoin) so forging is not feasible without breaking Bitcoin's proof of work. its a stronger guarantee than a key server.

> They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person

comparing fingerprints doesn't verify a flesh-and-blood human either. "is this the specific person I mean" problem is still real and separate though.

`grace@key` binding gives you a stable, human-readable identifier you can hand out like an email address, build reputation on, and that anyone can use to verify posts made by you and message you without having to meet you in person. It solves the UX of using public keys as your identity. You can post online with a public key as your id (e.g. nostr) but its harder to build your online identity around it.

you can rotate the key underneath the name. with a bare key it becomes your identity, so rotating means becoming a new person and re-verifying with everyone.

> you are back in the realm of ridiculously long numbers.

not really. the long number is a disposable part, and there's a name above it. You can still exchange "grace@key" in person, and be sure you're talking to "grace@key"


Technically speaking the long numbered problem is solved with QR codes though.

You want to be sure it's a particular person the you need to establish in-person trust.


From the article:

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


The big news for some of us is that Exim has been dropped from ports. Here is a good article about transitioning from Exim to OpenSMTPD:

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


OpenSMTPD was substantially rewritten in 6.4 (2018). It is the best SMTP server for the majority of use cases. Unfortunately, the portable version has been weakly supported, so it's usually only OpenBSD users than learn how great it is.


I'm happy with it. Been running OpenSMTPd for many years at this point, on both OpenBSD and Linux, and I have no complaints.


I've also started using OpenSMTPD on linux machines when I need a simple MTA (which is to say, in almost all cases).


I really like OpenSMTPD; no nonsense and configuration feels rather modern compared to the legacy stuff that's out there.


Surprised exim was dropped from ports. It is not like it was ever in base. I guess the maintainer did not want to anymore.


We don't have to guess. There are several mailing list discussions:

https://marc.info/?l=openbsd-ports&m=177625153728067


The Steel Pulse idea actually sounds sort of possible...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You