upofadown

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

Note that that OEM would still have to deal with the minefield of patents created by the John Deere's of the world. I once worked for a company that had to work around an electronic circuit patent to detect a pulse. That was it, that was all it did. But if you used a standard differentiator circuit to detect the pulse created by a optical sensor watching for falling seeds you would violate the patent.

So a prerequisite might involve fixing the patent system...

The idea seems to be that there will some sort of cascading effect if we can somehow create physical qubits with sufficient noise performance. It's this "threshold" we keep hearing about. Once we exceed threshold there is a possibility that we can use error correction to expand everything without limit.

This assumes that there will not be other problems that arise. I suspect that "error correcting" thousands of qubits entangled with one another will be one of those problems.

Putting on my user hat...

"OK. Signal has forward secrecy. So messages are gone after I receive them. Great!"

Oh, you didn't turn on disappearing messages? Oh, right, then forensic tools like Cellebrite can get them. You have to turn on disappearing messages. The default is off.

Oh, you did turn on disappearing messages? We send the messages in notifications. So the OS can keep them. Turns out Apple was doing that. There is an option you can turn on to prevent that. It is off by default.

"I'll just delete the entire app!" No, sorry, the OS still has your messages...

At what point does the usability get so bad that we can blame the messaging system?

This same app had a usability issue that turned into a security issue just last year:

End to End Encrypted Messaging in the News: An Editorial Usability Case Study (my article)

https://articles.59.ca/doku.php?id=em:sg

They are an entity separate from Mozilla:

* https://blog.thunderbird.net/2020/01/thunderbirds-new-home/

Seems to be some misunderstanding of what bike bells are for here...

A bell is helpful in a situation where a pedestrian is not aware of an approaching bike. The bell informs the pedestrian of two things:

1. That there is an approaching bike.

2. Roughly were the bike is approaching from.

The hope is that the pedestrian will then behave in a predictable way to allow a safe pass by the bike. In almost all cases the pedestrian will be able to simply continue doing what they were doing before they heard the bell.

If a pedestrian can not hear bike bells, for whatever reason, that is not a problem. They can just stay consistent with the centreline of the path/road/way. They then have a responsibility to shoulder check when shifting from side to side.

So this is the exciting paper:

* https://arxiv.org/pdf/2603.28627

The new thing here seems to be the use of the neutral atom technique. Supposedly we are up to 96 entangled qubits for a second or two based on neutral atoms.

Shouldn't that be enough capability to factor 15 using Shor's?