upofadown

...and conductive, rivaling copper.

That isn't true for either thermal or electrical conductivity. So I don't know what is meant here.

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

[1] https://en.wikipedia.org/wiki/Crypto_AG

[2] https://en.wikipedia.org/wiki/Parallel_construction

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.

SpaceX plans to send one million more satellites into orbit, for space-based data centres, ...

I think we should wait to see how the first satellite data centre works out. It seems fairly unlikely that it could be practical. It seems kind of nuts...

Reflect Orbital, a US start-up, aims to launch a constellation of very large mirror-like satellites to provide sunlight at night, with reflected beams that span at least five kilometres on Earth's surface.

Straight up nuts with no practical value, even if it did work out.

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

[1] https://en.wikipedia.org/wiki/Clean-room_design

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.

The article makes a reference to the failed ARC (Authenticated Received Chain) proposal which was intended to help DKIM not break email forwarding:

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.

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.

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.

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

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.

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

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

Checking the required hardware noise performance:

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

There are no preferences available for symmetrical encryption. GnuPG for example does AES for symmetrical encryption by default. Is it violating RFC-4880? I think things get philosophical here.

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.

I stated that it was possible to use RFC-4880 in a way that is completely secure, not that every possible use is completely secure.

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.

PGP covers the case where data is encrypted and might stick around in that state for a long time. Decades. So backwards compatibility is essential.

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.

Yes. Both standards proposals have SHA256 fingerprints.

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.

For something like PGP, any performance difference wouldn't matter. There is one message and the key agreement is done once. As long as things are fast enough to be imperceptible to the user we are fine.

It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters. FWIW, here is the LibrePGP proposal:

* https://datatracker.ietf.org/doc/draft-koch-librepgp/

Observing the OpenPGP schism mess I think I have gained some insight as to why some RFCs become so bloated. For example it has been recently pointed out that there are 60 RFCs for TLS (with 31 drafts in progress)[1]. The RFC process seems to be more optimal during the design phase. Once we have an established standard there should to be some way to force those that propose changes/extensions to provide appropriately strong justifications for those changes/extensions. Right now it is a popularity contest and there will always be more people out there in favour of changes/extensions than those willing to endlessly fight against those changes/extensions. Because cryptography is so specialized and obscure, the users tend to get left out of the discussion.

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary.

Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard.

So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.

Encryption would have been baked in from the start, rather than waiting for PGP, S/MIME, and TLS to add them later.

This comment intrigued me so I did a tiny bit of research. It appears that X.400 uses S/MIME for encryption (see RFC-3854). Alternatively something called STANAG 4406 which provides some sort of centralized control of who sees what for military applications.

Neither seems to be "baked in from the start".

Yeah, you only get out something like 30% more energy than you put in[1]. So this isn't so much about how great solar is but is more about how bad corn ethanol is...

[1] https://en.wikipedia.org/wiki/Ethanol_fuel_energy_balance