Same Natanael as over there (see the moderator list and my separate mod account is there (it's separated because I don't want to wear the mod hat 24/7))

It's simply a thread about reddit getting worse and asking what the options are. Some of us pointed over here to lemmy.

This specifically is about finding who's coming here from reddit, not getting people to reddit, I don't see the problem

I have to admit I hope Redlib manages to find a way to continue working.

90% of us were that person at one time.

old.reddit only works if I have an account. I'm not creating another account there ever again, ergo, I'm not reading the link.

Great, ao another wave of people who are only going to want to talk about reddit.

Because you must now be logged in to view the content. Spez sucks again.

Why are people suddenly posting reddit links all over the place?

Rogaway’s stream/chain constructions

No, that's interesting. There is also TLS 1.3 and NOISE/WireGuard channel messaging doing similar at the AEAD level (and original age, of course). If you just look at the diff between the original age spec and this proposal, you don't really have to argue at the ground level. But since it's cryptography, one ought to be suspicious.

There are plenty of libraries with age support out there, which can be made compatible in a breeze, and we inherit all the nice header unlock features like SSH pubkey or Yubikey, without changes. Simplicity is key.

PBKDF2 is almost entirely "linear", you can build an efficient pipeline which runs entirely on-chip without needing to reach out to external memory (a very large RAM requirement needs many more state holding gates than the FPGA has available, so it needs to start using external memory). The FPGA can essentially compose a digital conveyor belt for PBKDF2. This isn't as effective for Argon2id which forces it to stop and start and stop and start, etc.

Look up Kolgomorov time bounded complexity. The absolute minimum memory requirement is defined by the compression limit which is bounded by the total entropy in the algorithm. Entropy is defined by the input values (the password, random salt).

But computationally limited attackers often can't wait long enough to solve the compressed variant because CPU time explodes, so they can not reach high degrees of compression. Using a certain amount of minimum RAM is effectively optimal for resource usage if you can't break the underlying cryptographic function in password hashing algorithms.

We don't have an absolute proof what the minimum is, but Argon2id is very solid and there's little reason to believe there's some major hidden shortcut.

Have you looked at Rogaway's stream/chain constructions? They use chained AEAD blocks to do something similar

huh, i think i know understand it better. it works that hashing steps builds on multiple hashing steps together from previous rounds, which increase storage consumption. but i still do not understand, why less storage consumption makes pbkdf2 for example faster to crack in fpga

The forgery attack drops these levels to 2^65, 2^90, and 2^119 for 1024-, 2048-, and 4096-bit keys respectively.

Well that's terrifying, and all the more reason to get off of RSA signatures and onto anything else, probably EdDSA. Even though the article and paper don't address the real-world systems which use padding, the algorithmic safety that underpins RSA is under serious scrutiny. It's hard to see how RSA 4096-bit keys can remain as a first choice, when this type of attack exists and there are credible alternatives, both PQC and not.

The fact of the matter is that for signatures where there isn't an HNDL problem, we still have the issue of being confident in the signature years after signing. Will an RSA-4096 signed blob be acceptable in 20 years? Do we really think RSA will be above reproach by then? Signers in 2026 might do well to at least have a second signature scheme in place to doubly sign their blobs, and to maybe revalidate then doubly re-sign older blobs previously signed with just their RSA keys, to maintain their provenance for decades to come.

Adding more background, Soatok previously looked at libolm (the library specifying the peer to peer racket cryptography) and Megolm (the specification of the group racket cryptography). And the takeaway back in 2024 was that:

The people that developed Olm and Megolm has not proven themselves ready to build a Signal competitor. In [sic] balance, most teams are not qualified to do so.

And back then in 2024:

3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all.

Deprecation policies are a beautiful lie. The impact of a vulnerability in Olm or Megolm is still far-reaching, and should be taken seriously by the Matrix community.

So the fact that a key confusion vulnerability exists in the latest Megolm specification -- nevermind whether it's actually translates to a vuln in the main Element client's vodozemac Rust implementation -- is damning and reiterates Soatok's earlier takeaway.

I want Matrix to succeed, to add to the list of reliable E2EE software that currently has just one real entrant (Signal). But project management is failing Matrix right now, and it's showing through these sorts of technical mishaps. The demand and will to develop a bona fide, federated E2EE competitor is there, but the actual implementation is not.

And it's not clear that things will get better anytime soon. The timeline matters, because a number of people genuinely cannot use Signal and need an alternative. But Matrix either isn't it, or it's failing to deliver on the federation aspect that was meant to be its distinguishing strength. This is a Matrix problem at large, not just a problem for Element interoperability, and not just a problem for older non-Element clients. The Matrix project owns the spec and they alone need to do something about it from the top.

As a counterpoint (but one which admittedly doesn't include the complexity of cryptography), ActivityPub is a protocol specification that laid down the ground rules and many compatible software stacks implement it with fairly good interoperability. You reading this very post proves that point. If there was, say, a flaw in moderation capability using the protocol, it wouldn't make sense to blame the Lemmy client, or kbin software, or the default Android Mastodon client. No, the responsibility has to befall the protocol itself, because it affects everyone, even if some instances aren't yet impacted.

is this actually trustable? did someone test? can we generate a database for testing?

You can freely ignore any quantum utility claims until around 2035 in my opinion.

Oops lol. Quantum computing records and "supremacy" results keeps getting replicated on classical computers.

Let me save you the click bait title: it's about the fourth cryptographic puzzle in front of the CIA HQ, being bought up by a cryptocurrency venture capital firm. https://en.wikipedia.org/wiki/Kryptos

I recognize the term "cryptographic alacrity" to specifically include the deprecation of unsafe cryptography, to distinguish from "agility" that could may or may not deprecate old cryptography, thus allowing for fallback attacks to truly ancient cryptography. So yes, I think we're on the same page as to where the utility lays.

The value in cryptographic agility comes entirely from the ability to deprecate insecure algorithms, it does not come from the ability to add new algorithms because we can always do that with a version bump anyway.

Also, on the note of interfaces, KEM constructions can not be swapped in for most generic ECC key exchange functions due to different requirements on message round-trips.

The paper PDF by the IBM researchers: https://arxiv.org/pdf/2606.13445v1

From just the abstract, I'm a bit alarmed that the researchers believe that "cryptographic agility" is reducible to a software engineering problem, rather than a complex function of regulatory (eg PCI-DSS), governmental (eg FIPS), and availability (eg hardware acceleration/support and robust implementations) considerations.

But even before all of those stakeholders get involved, is cryptographic agility still an operational objective? Sure, there's the matter of transitioning to PQ crypto, for scenarios where HNDL is a serious concern over the time horizon of whatever's at stake. But is that perceived as a one-time event, or is the idea that all future upgrades should be abstracted?

I find the latter a bit difficult to credibly believe, as the last major attempt at cryptographic agility was so thoroughly bungled that JWT alg:none has a website to highlight the problem.

Agility is only useful if it's actually moving forward: if instead it's an excuse to stand in place, then it's worse than nothing. Best I can tell, this paper seems to deal with abstraction of specific implementations of cryptographic libraries. So this would be akin to not binding directly to OpenSSL vs BearSSL, but having the ability to swap one out for the other.

In that more narrow sense, a lateral move like that is probably fine to abstract. But I can't see how this would fair well if used to shoehorn newer cryptography into applications that either are firmly dependent or are brittle in other, in-abstractable ways.

Please find a better source than this, like the original announcement maybe

/signed, one of the moderators

As long as you're using up to date TLS protocols and algorithms, it's great for encryption in transit but isn't going to do anything (out of the box at least) for encryption of data at rest, but if you just disable chat logging on the server that's not really an issue. Clients can still store insecure copies of chats, but that's an issue with every secure messenger.