Sign in

René Mayrhofer :verified: 🇺🇦 🇵🇸

@rene-mobile.infosec.exchange.ap.brid.gy
14 followers 0 following 47 posts

Prof. for networks and security at #JKULinz, formerly leading Android platform security at #Google. This account will mostly carry IT security stuff, but […] 🌉 bridged from ⁂ infosec.exchange/@rene_mobile, follow @ap.brid.gy to interact

PostsRepliesMedia
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Dan Wallach @dwallach.discuss.systems.ap.brid.gy · 14h
This is an epic hardware supply chain attack. People who buy $300 crypto wallets are generally the kinds of people whose cryptocurrency you want to steal.
infosec.exchange
017
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 12/10/2026
Watching the next few months will tell you which companies care about actual technology, which are just riding the marketing hype train, and which are pure Trump sycophants. #AI #SI #ML #TrumpRegime
Distracted boy meme: AI looking at SI, with ML being outraged
002
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 11/10/2026
Oh God, this is getting even worse: apparently the "source" of the claim that AI might have broken classical cryptography is the fact that some numbers are skipped in the OpenAI math dump. You know, that same dump that doesn't even have formal verification on more than half of the results and […]
infosec.exchange
Original post on infosec.exchange
010
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Prof. Sam Lawler @sundogplanets.mastodon.social.ap.brid.gy · 09/10/2026
This paper title is 🔥🔥🔥 "Systematic non-compliance of satellite megaconstellations with IAU brightness limits" arxiv.org/pdf/2610.10834 Congrats to the Global Meteor Network team on a great paper demonstrating how bad SpaceX and other satellite operators are on following through on […]
mastodon.social
Original post on mastodon.social
043
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 08/10/2026
My LG TV has finally been shame-banned to be on the IoT VLAN instead of the normal LAN. It meant some additional (now very specific) firewall rules, although my #OPNsense UDP Broadcast Relay config already takes care of mDNS/Chromecast/etc. It is now also explicitly banned from bypassing my […]
infosec.exchange
Original post on infosec.exchange
306
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
daniel:// stenberg:// @bagder.mastodon.social.ap.brid.gy · 08/10/2026
"The people holding up the internet" A good-looking but somewhat depressing exposé about the people holding up current digital infrastructure as a hobby. sheets.works/data-viz/holding-up-th…
sheets.works
The people holding up the internet
Four billion phones ask one text file what time it is. One lecturer keeps it in his spare time. We counted the rest.
255179
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 07/10/2026
And I just love the unofficial French reaction quoted by The Guardian: "A diplomatic source at #France’s foreign ministry said “there’s absolutely no reason for us to change our commitments” when it came to supporting the conference." “We stick to supporting #CivilSociety. It’s not just […]
eupolicy.social
Original post on eupolicy.social
047
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 07/10/2026
After #RightsCon26 it's the second time this year that authoritarian government's attack and (attempt to) shut down a #CivilSociety conference and it's another massive warning shot for Europe. Excellent reporting about the #Disinfo2026 scandal from The Guardian […]
eupolicy.social
Original post on eupolicy.social
108
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
ploum @ploum.mamot.fr.ap.brid.gy · 06/10/2026
A software always runs on a computer. A software always do what its creator wants it to do. If the software doesn’t do what its creator wanted, it is a mistake from the coder, a bug. If the software runs without the consent of the computer’s owner, it is a malware/virus. Stopping a software […]
mamot.fr
Original post on mamot.fr
2340
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
daniel:// stenberg:// @bagder.mastodon.social.ap.brid.gy · 05/10/2026
"Google freezes open-source bug bounty program amid flood of invalid AI slop submissions" […]
mastodon.social
Original post on mastodon.social
2925
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
John Kristoff @jtk.infosec.exchange.ap.brid.gy · 02/10/2026
Oh, and this just happened to be published today: blog.arxiv.org/2026/10/01/updated-r…
blog.arxiv.org
ArXiv's Updated Rate Limit Policy
Comments
013
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Daniel Lakeland @dlakelan.mastodon.sdf.org.ap.brid.gy · 01/10/2026
Fediverse, the social media system for 40+ year old people who built the world wide web and regret it.
20128453
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
M.S. Bellows, Jr. @msbellows.c.im.ap.brid.gy · 24/09/2026
I'm so old, I remember when software that spread into the wild and infiltrated other people's computers and did harmful things to them that the users didn't ask it to was called "malware" instead of "AI" and the people that spread it were prosecuted instead of given billions in venture capital […]
c.im
Original post on c.im
12017
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 28/09/2026
fnl.mit.edu/how-we-learned-to-stop-… "The tiresomely old-school cost of supporting scholarship and pedagogy is so dull compared to the exciting opportunity of an Ambient.ai contract that will empower the tracking potential of our 500 new surveillance […]
infosec.exchange
Original post on infosec.exchange
010
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 28/09/2026
How long will it take for #OpenAI to be charged with attacking other computing systems? If individuals were being found out doing all these things, they would likely already have been under intense investigation or been arrested.
004
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Alberto Cottica @alberto-cottica.mastodon.green.ap.brid.gy · 25/09/2026
This is very interesting: preliminary estimates of the costs of the 2026 heat waves in #Belgium are at or above 1% of GDP. One estimate says it will offset the entire predicted economic growth for 2026. So, the powers that be refuse to take #climateAction because it would jeopardize "growth" […]
mastodon.green
Original post on mastodon.green
102
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 22/09/2026
No shit Sherlock. #AI
Politico Pro article title "Rogue Al warnings are mostly ‘marketing,’ top
European Al CEO says"

Text snippet: "AMSTERDAM — The flurry of incidents in which Al agents went rogue and hacked other companies, and subsequent warnings of Al getting out of control, should be taken with a pinch of salt, a leading European Al boss told POLITICO. “I think a lot of it is marketing, to overemphasize the proposed capabilities,” Max Junestrand, co-founder and CEO of Legora, an American-Swedish firm that develops collaborative Al tools for lawyers, said in an interview when asked about this summer’s Al hacking incidents."
127
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
rAIner Agentic Quantum Rehak @rainer-rehak.mastodon.bits-und-baeume.org.ap.brid.gy · 19/09/2026
‘Doom Loop’: OpenAI and Microsoft Admits #LLMs Are Destroying the Web and Built on Theft "Executives working on #AI at #Microsoft and #OpenAI admitted what its critics have been saying all along: Large language models are predatory pieces of technology that have been built on what a Microsoft […]
mastodon.bits-und-baeume.org
Original post on mastodon.bits-und-baeume.org
0019
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 19/09/2026
The real dangers of #AI: "The [AI-generated intelligence] report, according to one of the sources, was “entirely false.” But it also “almost started a war,” the source said." Why the heck do you employ expert intelligence analysts if you then rely on bullshit chatbots for assessing military […]
eupolicy.social
Original post on eupolicy.social
000
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Simon Zerafa @simonzerafa.infosec.exchange.ap.brid.gy · 16/09/2026
Google and CISA warned that an actively exploited zero-day vulnerability (CVE-2026-58704) affecting Pixel cellular modems. This allows attackers to silently bypass permission checks and escalate privileges with no user interaction! It was quickly added to CISA's Known Exploited Vulnerabilities […]
infosec.exchange
Original post on infosec.exchange
013
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Theodora Ward @theodoraward.wandering.shop.ap.brid.gy · 12/09/2026
if i rig up a random number generator to a bomb, program it to generate a number between 1 and 20 every five minutes, set the bomb to go off if i roll a 20, begin the random number generator, then leave the room, i am liable for when the bomb goes off. the fact that a deeply stupid […]
wandering.shop
Original post on wandering.shop
5759
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Arjen P. de Vries Timmers 🕊️ @arjen.idf.social.ap.brid.gy · 12/09/2026
Informative blogpost by Cory Doctorow that not only explains clearly how talk about "rogue AI agents" that "operate in swarms" is nothing more than promo fiction for Big Tech, but also details how LLMs "simply" solve those tasks from the "Exploit Gym" benchmark by reproducing (and adapting) […]
idf.social
Original post on idf.social
125
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
heise online @heiseonline.flipboard.com.ap.brid.gy · 12/09/2026
Salto rückwärts: Apple möchte KI-Modelle doch mit Nutzerdaten trainieren www.heise.de/news/Salto-rueckwaerts… Gepostet in Heise Security @heise-security-heiseonline
heise.de
Salto rückwärts: Apple möchte KI-Modelle doch mit Nutzerdaten trainieren
Apples Versprechen war simpel: Persönliche Daten von iPhone-Nutzern fließen niemals in das Training von KI-Modellen ein. Damit ist es jetzt vorbei.
003
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 10/09/2026
The slides from our #GDC session on #revocation of digital credentials in Geneva are public: docs.google.com/presentation/d/1V2E… While not fully polished, they have pointers to a lot of the different aspects we have been discussing, and I'd be […]
infosec.exchange
Original post on infosec.exchange
010
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
abadidea @0xabad1dea.infosec.exchange.ap.brid.gy · 09/09/2026
Project Glasswing: Claiming to have found 26 thousand real vulnerabilities but only 0.8% of them have resulted in a real fix in a real project after five months is dire. They blame it on the human independent review bottleneck, but human experts being paid for their time definitely have a […]
infosec.exchange
Original post on infosec.exchange
11610
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 09/09/2026
#AI is going great: "Corporations are working with the US #military to develop AI for #surveillance, target acquisition, and autonomous mission execution." "#OpenAI employees are being directly embedded into military command structures to support the deployment of AI on-site." […]
eupolicy.social
Original post on eupolicy.social
011
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
daniel:// stenberg:// @bagder.mastodon.social.ap.brid.gy · 05/09/2026
I know lots of you have asked what Aisle does differently than Mythos etc to find security problems in #curl, the kernel etc, and here's an article that tries to address that. www.zdnet.com/innovation/aisle-ai-v…
zdnet.com
This AI tool found 6 Curl vulnerabilities Mythos and Codex missed – even Greg KH is impressed
Technology Digital HUD Circles Design ### ZDNET’s key takeaways * Aisle finds bugs that AI coding programs can’t. * The best Linux maintainers are impressed. * You should consider Aisle to help find bugs. * * * You may not have heard of Aisle, an AI-native vulnerability-management startup, but some of the best open-source maintainers know it well and really like it. Why? Because Aisle finds real bugs that other, far better-known AI coding programs, such as Anthropic’s Mythos and OpenAI’s Codex, don’t. **Also:OpenAI’s agents exploited a patched Linux bug in Hugging Face incident: 6 steps to take ASAP** For example, Aisle recently said its security analysis system uncovered six previously unknown vulnerabilities in Curl that the open-source project’s maintainers accepted and assigned Common Vulnerabilities and Exposures (CVE) numbers. The findings arrived shortly after Curl founder Daniel Stenberg wrote on Mastodon that Mythos, OpenAI Codex Security, and ZeroPath had found no additional vulnerabilities in the widely deployed, open-source networking file-transfer project. Aisle, meanwhile, found 29. Aisle achieves this success not because it uses expensive frontier models, but because, the company states, “even small models can recognize a vulnerability when handed the right snippet of code with leading context.” We “tested whether cheap models with enough throughput can surface real bugs without that hand-holding. The answer was yes: adequately intelligent models, deployed systematically across an entire codebase, can surface real bugs without hand-scoped snippets.” Stenberg was fine with Aisle’s discoveries. Unlike in the past, when AI programs discovered bogus vulnerabilities and produced mountains of AI slop reports, they now find real security holes. As Stenberg put it, we’re now in the “high quality chaos era.” Still, as Stenberg commented on Mastodon, “I am grateful that all the most powerful AI engines all scan #curl to find flaws. Finding them means we can fix them. Sometimes it just demands coming up to the surface for a few deep breaths before we dive again.” ## Linux maintainers are impressed Trending Now After the vibe-coding rush comes the debugging hangover 09/02/2026 The most exciting AI wearable at CES 2026 might not be smart glasses after all 01/02/2026 OpenAI’s new Astra model is finally here – why safety experts are worried 09/03/2026 It’s not just Curl, though, that’s reaping the benefits of Aisle. As Greg Kroah-Hartman, the maintainer of the Linux stable kernel, put it, “I’m seeing the same for Linux as well. No idea what Aisle is doing differently, but wow…” Jim Fuller, a Red Hat senior principal software engineer specializing in security, speculates that Aisle knows what it’s doing, knows the limitations of tooling, and I suspect has worked harder than just running a scanner. **Also:Linux is getting a security wake-up call – why it was inevitable, and I’m not worried** In an interview, Stenberg added, “I think at least a part of this success (for both of us) is our communication and cooperation. We’ve met, we’ve talked, and they spend proper engineering time to make sure that we get curated results of top quality, which motivates us to take every Aisle report seriously.” Curl maintainers accepted six Aisle-reported vulnerabilities for the project’s latest release. All six issues were patched in Curl 8.22.0, which was released September 2. Curl’s own advisory database lists the six CVEs as low severity, while the project’s release notes list them among the 10 security vulnerabilities addressed in the release. Now, the results shouldn’t be overstated. Six accepted low-severity CVEs from a single project and one testing sequence do not establish a general performance ranking among Aisle, Mythos, and Codex Security. That said, the Curl results are stronger evidence than a benchmark score or a capture-the-flag exercise because they involve current production code and external validation by the project’s maintainers. ## System versus model Aisle is using the Curl result to advance what it calls a “system over model” argument: that an AI security product’s results depend less on the raw capability of its underlying foundation model than on the surrounding system — its agent orchestration, codebase context, vulnerability hypotheses, validation loops, and workflows for reproducing and remediating candidate issues. **Also:Linux is getting a security wake-up call – why it was inevitable, and I’m not worried** I buy this theory. A general-purpose model can be highly capable at reasoning about code yet produce uneven results when asked to inspect a large, mature project through a one-off scan. A specialized system can potentially gain an advantage by iterating over code paths, tracking configuration-specific behavior, correlating libraries and historical vulnerability patterns, ranking leads, and testing them before presenting a report. Aisle’s platform claims to combine vulnerability discovery and triage with patch generation and verification. The startup’s broader pitch is not simply that AI can identify a bug, but that it can produce a developer-reviewable remediation and supporting validation, an effort to reduce the security team and maintainer labor required to turn alerts into merged fixes. ## Maintainer approval matters The more important lesson from the Curl episode may be methodological. Security tool comparisons often rely on benchmarks with known flaws, synthetic tasks, or the vendor’s internally verified results. Such tests are useful, but they say little about whether an AI system can find a subtle, previously unknown defect in code already exposed to years of real-world review. Here, Curl’s maintainers, not Aisle, Anthropic, or OpenAI, controlled the decisive outcome. They reviewed reports, decided whether they represented security vulnerabilities, issued CVEs, created patches, and incorporated those fixes into a public release. **Also:AI a ‘force multiplier’ for low-skilled threat actors: 4 ways organizations should respond** The comparison is also more than a raw report count. Aisle initially reported 29 candidate issues, but only six cleared Curl’s security review bar as CVEs. That outcome does not make the remaining 23 issues useless. Some may be ordinary bugs, false positives, duplicates, or still-under-review reports. However, the result underscores why “findings” and “confirmed vulnerabilities” should not be treated as interchangeable. So, Aisle’s performance on Curl offers a meaningful early result for specialized, agentic security systems: on one of open source’s most hardened C codebases. Whether the outcome proves repeatable across other projects, languages, and operational environments remains the next question. Be that as it may, when Stenberg, Kroah-Hartman, and Fuller, all of whom know finding and fixing security bugs like the back of their hands, are impressed, I’m impressed, too. If you’re serious about finding and fixing vulnerabilities, Aisle demands your attention. ## / featured ### Back up your files, or else: Here’s my easy 3-2-1 routine – and how to build yours ### I went hands-on with IFA’s top MacBook Neo competitors – here’s which one stands out ### Apple’s iPhone event is almost here: What I’m watching closely ### 45% of professionals use shadow AI tools – here’s how to manage the risks Show Comments Log In to Comment * Log Out Community Guidelines Please accept cookies to view the comments powered by Disqus. Please enable JavaScript to view the comments powered by Disqus. Steven Vaughan-Nichols Senior Contributing Editor Steven J. Vaughan-Nichols is a freelance writer and technology analyst. Besides ZDNET, he works with Foundry (Formerly IDG Communications), The Register, The New Stack, TechStrong, and Cathey Communications. He does not own stocks or other investments in any technology company. See full bio ### The Latest from Steven * This AI tool found 6 Curl vulnerabilities Mythos and Codex missed – even Greg KH is impressed * OpenAI’s agents exploited a patched Linux bug in Hugging Face incident: 6 steps to take ASAP * Google’s AI-first Googlebook laptop is almost here – can it avoid the Copilot+ PC problem? ## / featured ### I found the best Labor Day deals on Bluetooth speakers to keep the party going ### The best Labor Day Costco deals 2026: TVs, smartwatches, Apple devices, and more ### The best Labor Day 2026 TV deals: Samsung, LG, and more ### The best Labor Day deals to shop now: Save on TVs, Apple devices, and more
012
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 04/09/2026
Ein #Railjet Express der #ÖBB steht für einen Zwischenstopp am Bahnhof. Es kommt eine Durchsage (nur leicht gekürzt): "Ich habe leider den Schaffner vom anderen Zugteil in St. Anton stehen lassen. Wir warten, bis er mt der Westbahn nachkommt, bevor wir weiterfahren können." Ja, wirklich. Ich […]
infosec.exchange
Original post on infosec.exchange
000
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 04/09/2026
This is a really good summary of code generation vs. review. Understanding and system complexity are key, not the lines of code. ----------------------------------------- Every layer of review makes you 10x slower apenwarr.ca/log/20260316-every-laye… > […]
infosec.exchange
Original post on infosec.exchange
000
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 03/09/2026
Given the multiple cryptanalysis papers that came out in the last few weeks, I have updated my very unscientific guide to the security of various PQC algorithms to account for them. keymaterial.net/2025/12/13/a-very-u…
keymaterial.net
A very unscientific guide to the security of various PQC algorithms
After publishing my series on UOV, one feedback I got was that my blog posts made people feel more confident in the security of the scheme, because “at least someone is looking into these things”. I don’t necessarily know if that is the takeaway I would make from my posts, but it gave me the idea to write my extremely subjective, and very much biased guesstimates for how secure I consider various approaches and problem families within PQC. Since unfortunately I do not possess infinite wisdom or the gift of time travel, these are at best informed guesses, and I take no responsibility for being wrong on any of them. **Update (2026-09-03):** There have been several cryptanalysis papers that have come out since I wrote this article, which have changed some of my priors, I have added updated sections to reflect these changes. ## Generalities There is a somewhat popular saying in cryptography “attacks only get better”. It’s a vacuously true statement, since obviously an attacker will always use the most powerful technique currently known, but I think it is also at least slightly misleading, implying that progress on attacks is not only inevitable, but also somewhat continuous. Instead, what we are seeing is usually something like this: Initially, when a certain technique is first seriously discussed, attacks come in quickly and parameters have to be adjusted to account for them. With time, as our understanding of the space grows, we tend to refine those attacks, but it is a process of diminishing returns. It is possible that some novel mathematical technique starts a new spurt in advances in attacks, but importantly, there is usually no continuous improvement in attacks. As an example, if we look at RSA, we first have the naive factoring algorithms such as trial division and Fermat’s method, which predate cryptographic use. Then, in the seventies, they get joined by the first major improvement in the space, Pollard’s rho. In the 80s, we get the quadratic sieve, as the first subexponential algorithm, joined by various lattice methods. Finally in the 90s, more than 30 years ago, we get the current best factoring algorithm, the general number field sieve, a refinement of the quadratic sieve, as well as further improvements on lattice techniques. Quantum algorithms also first enter the scene, with Shor’s algorithm. After that, successes die down substantially, mostly confined to relatively minor improvements to the general number field sieve. This is not because we stopped working on factoring algorithms, but most of the effort shifted to other targets such as The Montes’ algorithm for factoring polynomials over discrete valuation rings. If we look at elliptic curves, the story of attacks is even less exciting. There is, to this date, no known generic classical attack against elliptic curves that is better than a space-time traded off version of a brute force search. This is again not because the topic isn’t studied, elliptic curves are one of the most fundamental building blocks of algebraic geometry, and we know them in great depth. In fact, we know them well enough that we can even start to explain this lack of attacks: They are the most generic form of Diffie-Hellman out there. All in all, this makes our job predicting the future of which algorithm is likely to break and which ones are likely to last, very, very hard. We are not looking at nice, predictable trends, but instead are mostly looking at a process that jumps in huge steps every few decades. A different view to look at the same trends is to say that a scheme gets more trustworthy every time it survives an attack. From that point of view, attacks that fail teach us something about the scheme itself, adjusting our priors, making it more trustworthy. This is particularly true for attacks that tell us something fundamental about the underlying problem; the more general the attack, the more it can teach us why a scheme is resiliant. But, now, without further ado, my personal list about how safe I think various approaches to PQC are, together with how familiar I am personally with the space and how much I think it has been studied. ## 1st Place: Hash-based Signatures There isn’t much to say about hash-based signatures. They have a security reduction to the properties of the hash function used. Any signature scheme, and pretty much any public key encryption scheme requires a hash function somewhere in its construction, be it to compress the message, act as a random oracle, a key derivation function, or as a one-way function. If we cannot construct a secure hash function, we cannot do cryptography. In fact, if we consistently failed in creating secure hash functions, we would most likely live in a universe where P equals NP. Hash-based signature schemes have reduction proofs that reduce their security to that of their underlying hash function. As such, hash-based signature schemes are at least as secure as any other asymmetric (or symmetric) cryptographic primitive. They have plenty of drawbacks, but lack of security is not one of them. While I haven’t studied them to great depth, there is also just not much to say about their security. They are secure. Note that one of the drawbacks that some hash-based signature schemes have is the necessity to keep state (LMS/XMSS). While these schemes are as secure as their hash function if used correctly, the same is not true if the state is not managed correctly, i.e. if one-time-signatures are used more than once. While I have extremely high confidence in the mathematics of hash-based signatures, I also have extremely low confidence in our collective ability to not corrupt state once in a while. ## 2nd Place: Lattices It is hard to overstate my confidence in lattices. General lattices, such as used in FrodoKEM, being broken is pretty much all but equivalent to proving P = NP, at which point all cryptography vanishes (since symmetric cryptography reduces to boolean satisfiability very easily), and it is time to find another career. Lattices feature heavily in arithmetic number theory, as they arise very naturally when studying number fields. As such, lattice algorithms are actually far more central to mathematics than factoring algorithms. The number of problems an efficient lattice reduction algorithm solves is far higher than that of an efficient factoring algorithm. The main reason for that is that lattice problems are the simplest form of Diophantine equation problem, the linear Diophantine equation. You can see an example of this in one of my previous blog posts. This makes lattice reduction one of the most useful algorithm to calculate pretty much about anything in discrete mathematics. Far from being constrained to just algebraic number theory, they also show up in algebraic geometry, in the description of Abelian varieties over the complex numbers. Or, as it turns out, p-adic numbers, as studied in my PhD thesis. Given how central they are to mathematics, I would be extremely surprised if someone, somehow, found a way to improve on generic lattice reduction. Even when it comes to quantum algorithms, lattice reduction is probably one of the most studied one, and so far, no generic improvement has been found, and several fundamental looking obstructions have been identified. Lattices, as a mathematical object, have been studied pretty much for the same time as elliptic curves have been, since both arise from the same underlying questions about the circumference of an ellipsis. In this study, certain integrals arise naturally, defining a function that has two periods in the complex plane. In other words, functions that can be seen as defined on the complex numbers modulo a lattice. And the simplest of these functions , obeys a differential equation . In other words, and its derivative define a elliptic curve. In cryptography, lattices also have been studied about as long as elliptic curve have. First as an attack, due to their mentioned ability to solve Diophantine equations, and soon after as cryptosystem themselves, by increasing the lattice rank to the point that the reduction becomes impossible to compute. The main reason you might not have heard of them before is their generally larger overhead compared to elliptic curves and RSA, making them unappealing in a world where elliptic curves and RSA are unbroken. But we are not using generic lattices, we are specifically using module lattices. Those are the lattices coming from number field orders. A number field is a field extension of (such as adding the imaginary unit _i_ to the rational numbers), and an order in such a number field is a generalization of the integers (such as adding the imaginary unit _i_ to the integers, to obtain the number field order called the Gaussian integers). These number field orders are canonically lattices themselves, and any finitely generated module (I.e. vector space, but for rings) over them is again a lattice in a canonical way. If there is a break of ML-KEM or ML-DSA, my money would be on exploiting this additional structure. However, even when it comes to this additional structure, it is very well understood and studied. Looking at MLWE and NTRU specifically, both problems are deeply related to the p-adic rational reconstruction problem. In the case of MLWE, we need to switch to RLWE, but a number field order can be seen as a module over an order of some subfield, so this doesn’t really change the picture all that much. So what is the rational reconstruction problem? Recall that, in order to attack LWE, we needed to find such that , which mainly boils down to describing the kernel, the solutions to . For RLWE (or indeed, for NTRU), we need to switch to a number field order, which we mainly do by replacing the capital with a lower case . We can, of course, without much consequence, switch the sign of the error term, and write , for the lattice we need to reduce. With a slight reordering, this is equivalent to . Since and are small in some metric, this means that what we are asking is given a fraction with bounded numerator and denominator, which is only known modulo some ideal (or more generally a number of finite places), find the numerator and denominator. We all know this problem when we replace the finite places with infinite places, especially over , albeit usually less dressed up in formal mathematics lingo: This is the question of which fraction fits best with some given limited precision decimal expansion, such as the question of whether an output of 1.666 came from an actual result that was 5/3, or 1666/1000. This problem (over finite places, i.e. modulo a prime) arises relatively naturally when studying number fields, and the only way we know for solving it is lattice reduction. This is a very common pattern in arithmetic number theory, you usually take problems that arise there and reformulate them until you can express them as a lattice problem, and then proceed to reduce the lattice when the number field is small enough. The opposite, where you can use the number theoretic properties of the number field to say something about a lattice without reducing it on the other hand is very rare. That being said, we are not using a random number field when it comes to lattice cryptography, but a fairly small set of very specific ones, which have properties that are not usually encountered in many number fields, such as having a class number of 1, and an easy to calculate group of units (up to some finite cofactor easy to calculate, that is, but still this is usually a hard lattice problem for a random number field, but is easy for the cyclotomic fields heavily ramified over 2 that we want for our cryptographic purposes). That being said, even with these blemishes, when it comes to module lattice cryptography, we are talking about a very well understood and explored part of mathematics, that should be very safe to use for cryptographic purposes. **Update (2026-09-03):** Since writing this article, two advancements have been made in lattice cryptanalysis. First HAWK has been broken by a classical attack, making it so that an attacker has to only reduce a lattice that is much smaller than the one assumed. This makes the scheme no longer attractive, as the necessary increase in parameter choices pushes it beyond ML-DSA in terms of signature and public key sizes. You might have noticed that I did not even mention HAWK in this overview to begin with, and there is a good reason for that: While NTRU and MLWE rely on the mentioned step of going from local information at a finite place to global information (the thing that we only really know how to do with lattice reduction). HAWK’s public key already used global information, so my argument as to why even number field based lattices should be secure did not apply to it. All in all, the fact that HAWK was broken should not be considered as all that relevant information when it comes to the security of other lattice schemes. Second Daniel Simon, of Simon’s algorithm fame released a quantum algorithm that claimed to solve the dihedral coset problem in polynomial time. This rather unassuming title would be a bombshell for lattice cryptography and beyond, as it would imply that a lot of instances of LWE and general lattices are solvable on a quantum computer. The paper received a lot of attention and led to another set of quantum algorithm people writing another paper that points out some fundamental problems with the given algorithm. That paper gives an information theoretical argument that generalizes further, and has led Kuperberg, another famous quantum algorithm person, to conjecture that it might be possible to prove that at least certain common approaches to solving lattice reduction with a quantum algorithm might _never_ have more than a polynomial advantage over classical algorithms here. All in all, this is a great showcase of the dynamic I mentioned in the beginning of this blog post: The failed attack led to us learning more about the nature of lattice reduction, to the point that it has substantially increased our confidence in the security of lattices. ## Update (2026-09-03): 2.5th Place: Have you considered Kerberos First suggested by Adam Langely, mostly as a semi-serious thought experiment, Kerberos, as a protocol, is already quantum safe. This is due to it using only symmetric cryptography, which is unaffected by quantum computers. With the recent results on Classic McEliece (which I will go into in the next section), “just use Kerberos” should now be mentioned as more desirable from a security point of view than any of the algorithm families discussed below. This is a moderately uncomfortable situation, because basically, if lattices fail, we do not have any other conservative choice to fall back to, but at the same time, given our very high confidence in lattice schemes, maybe is actually the right fallback to think about. Of course relying on symmetric cryptography to secure the internet would require a substantial amount of rearchitecturing, and have rather uncomfortable consequences for what privacy means in a future like that, but it is important to keep in mind that even without asymmetric key agreements, we would still have at least some ideas on how to proceed. ## 3rd Place: Codes I know a lot less about codes than I do about lattices, I’ve always considered them as the smaller sibling of lattices. Both schemes fundamentally work via underdetermined linear systems, where the solution has certain special properties. Being small in the case of lattices, and having lots of zeroes (i.e. being small in the Hamming metric) in the case of codes. Their construction has many similarities, to the point that code based cryptography can be attacked with the same lattice reduction techniques that lattice cryptography has to deal with. Compared to lattices, codes are far less central to mathematics, but whether that is a good or a bad thing is hard to say. But really, I haven’t studied codes to any necessary detail to have much of an opinion on them, other than that they are fine, probably, at least as long as lattices are fine. They are also less efficient than lattices in pretty much all of their instantiations, and at least I do not know how to think of them as a more general mathematical problem (akin to the p-adic rational reconstruction problem that governs MLWE/NTRU). **Update (2026-09-03):** At the same time that the other two mentioned papers came out and grabbed all the spotlight, a third paper was published on Classic McEliece. Initially, this paper only claimed a distinguisher attack, i.e. an attack that would allow an adversary to decide whether a given public key was created using Classic McEliece’s key generation algorithm (and have a private key), or randomly chosen in a way that just makes the format match. Distinguisher attacks are usually not by themselves a problem. We only rarely care about being able to hide our public keys in random data, after all. But they are also quite often a harbinger of things to come. Being able to distinguish a correctly formatted, but random instance of a problem from the instance that was created via key generation means that the actual problem used to safeguard the algorithm is not what we originally thought it was. This gives insight in what the actual problem underlying a cryptographic algorithm is, and if that actual problem turns out to be substantially easier than what we thought the problem was, we can potentially figure out a key recovery attack. And indeed, the authors of the paper managed to tweak their quasi polynomial distinguisher into a quasi polynomial key recovery attack. While the attack is quasi-polynomial, it is still quite expensive to run, and so while quite a few people currently believe that Classic McEliece’s standardized parameters are all easier to break than AES 128, as far as I am aware, nobody has been able to actually run the algorithm itself. This is somewhat similar to what the situation is with RSA 1024 at the moment, believed to be breakable, but nobody has the spare compute lying around to actually demonstrate the break. While BIKE and HQC, the other two code based KEM schemes that were in the NIST competition (with HQC being the one selected by NIST) are not affected by this attack, it certainly does not give me great confidence when the what is widely seen as conservative candidate of an algorithm family suffers a break like this. ## 4th Place: Isogenies Now to a bit of a controversial placement: Isogenies. What, even though SIKE was broken? Yeah, well obviously I don’t place SIKE at 4th place, it’s somewhat lower, right above Vigenère ciphers, and only because the attack is more interesting. SQISign on the other hand is a different story. The main reason to place it ever so slightly above multivariate cryptography in my opinion is that we much better understand the underlying hard problem and how it relates to the scheme itself. I am not ashamed to admit that I have a bias towards pretty mathematics, and SQISign does some of the most beautiful mathematics I know of. That being said, the scheme is for now too slow to actually be used in practice, and while it can be reduced to the endomorphism problem, we cannot currently rule out that the endomorphism problem ends up being easy, especially given that it is far less central to mathematics than lattices are. It has been studied somewhat extensively, though, but I am somewhat worried that the best experts on the endomorphism problem in algebraic geometry are just now slowly even learning about the existence of isogeny based cryptography. After all, the SIKE attack is based on a theorem discovered in 1997, and yet wasn’t discovered until 2022, showing a huge gap between academic algebraic/arithmetic geometry and cryptographers working on isogeny based crypto. ## 5th Place: Multivariate Cryptography I’ve written a whole series on Unbalanced Oil and Vinegar, probably the most basic of the multivariate schemes. Since then, a new attack has come out, leveraging wedge products. While the attack is far from catastrophic, it also feels very arbitrary, similar to the Kipnis–Shamir attack on Balanced Oil and Vinegar, it seems to me that we are missing something to really have a full understanding of the space. Humorously enough, even before the paper, I had tried unsuccessfully to attack UOV using wedge products, more precisely I tried to figure out if there is a structure in the cotangent space that can be exploited, so the fact that wedge products were a meaningful attack vector is not surprising per se, but still, if we want to trust UOV, we need to, in my opinion, have a better understanding of what the hard problem here actually is. It is easy to point to Gröbner bases here, but in my opinion the gap from generic Gröbner basis computation to the specific UOV problem is quite large. While all NP-complete problems necessarily reduce to each other, reducing to a Gröbner basis computation is one of the easier reductions, just like you can reduce a computer program to a boolean circuits satisfiability problem by literally translating the instructions, you can reduce a problem about polynomials to a Gröbner basis computation. One thing that particularly stands out to me about Multivariate Cryptography is that variations that have tried to reduce the size of the public key ended up broken quite often. To me, there is something missing about fully understanding what makes this problem hard to fully trust it, but my progress in understanding the problem space better has at least given me a glimpse of why basic UOV should be secure. That being said, realistically, I should place them above isogenies, mostly because we have had more survived attacks in this space, but this my list, and if it doesn’t contain at least one upsetting placement, it wouldn’t be very subjective now, would it? ## Bonus: Why RSA and Elliptic Curves both fall together One question that I got asked recently was why RSA and elliptic curves, while looking so different as cryptosystems, are both susceptible to Shor’s attack, when all these other schemes barely spend a word talking about why Shor’s does not apply to them. While it is true that at first glance, RSA and elliptic curves do look very different, they are actually far more related than one might think, some of it is even already visible in classical attacks. As I described in my post on why elliptic curves are really the only option for discrete logarithm problems, elliptic curves contain the multiplicative discrete logarithm as a subcase (at least if you allow for stable models). And for multiplicative discrete logarithm problems, we already have the same attacks working on RSA and DLOG. From that perspective it might be less surprising that an attack that is polynomial on RSA also solves ECC. More concretely, the thing that Shor’s algorithm actually solves is the Abelian Hidden Subgroup problem: Given a group , a function is said to hide the subgroup of if is constant on each coset, but different for different cosets. In particular, if is a normal subgroup, this means that is defined and injective on . The hidden subgroup problem is Abelian if the group in question is Abelian. This is a bit of a mouthful, so let’s look at a trivial example first, using as our group and try to hide as a subgroup. A function would hide this subgroup if it has a different value on the cosets, for example, if the function was just the value of the integer modulo 3. For a slightly more interesting function, which actually meaningfully hides something, we can look at the world of variant Sudoko, where we often see the concept of a modular line or modular mirror or similar, which requires certain digits to have the same residue mod 3 (For example this one or that one). Solving these puzzles is usually done by coloring the corresponding digits in one of three colors, indicating the residue class mod 3. Importantly, it is (at least initially), not known which color corresponds to which residue class, which starts to show why the function is considered hiding this subgroup. Of course, even if you just mapped integers to colors, the hidden subgroup would still be pretty easy to find by anyone who can count to three (and importantly, solving the Sudoko has nothing to do with solving the hidden subgroup problem), but you can imagine that for a larger modulus, this becomes an actually hard problem. While not necessary, it is very useful to know the classification problem for Abelian groups when looking at this question for Abelian groups in particular. All finitely generated Abelian groups can be written as the product , where . Knowing this means we know very well how, at least in theory, any subgroup of an Abelian group looks like, which is going to make the next bits a bit easier to grasp in their generalities. Knowing that Shor’s algorithms can solve the Abelian Hidden Subgroup problem, and now knowing what the Abelian Hidden Subgroup problem is, all that is left to do is to show where the subgroup is hiding, for both RSA and elliptic curves. As discussed, elliptic curves are more or less the most generic of all DLOG groups, so we don’t really need to concern ourselves with the intrinsics of how elliptic curves work, and can instead just take a generic group G (and as a bonus, this allows me to use multiplicative notation without feeling dirty). In fact, let’s start with DLOG. So given two elements , we are looking for such that . Instead of working with G as domain, we use two copies of , and define our function as . Since , this is equal to , i.e. it’s a linear transform on followed by a discrete exponentiation. But the discrete exponentiation is a group isomorphism, so we can basically ignore it for the purposes of hidden groups, since the hidden group definition does not really care about the range of the function to begin with. As a linear function, it is easy to see where maps to the unit, namely exactly for vectors generated by . Since is a group homomorphism, we can use the group isomorphism theorem to know that is constant on each of the cosets and injective on the quotient, i.e. hides an Abelian subgroup. Applying Shor’s algorithm, and obtaining a generator of this subgroup, we can recover k, since all elements of this subgroup have the form . Reformulating RSA into an Abelian Hidden Subgroup problem is even easier: The security of RSA is build on the attacker not knowing the order of the group, since the order of is , from which we can recover n’s factors p and q easily. So how is order finding an Abelian Hidden Subgroup Problem? Just take a random element and define as . This function has the same result exactly for all the multiples of the order of a, in other words it hides as a subgroup of . And the order of an element is always a divisor of the order of a group, so we can use this to find factors of n. Hidden Subgroup Problems are more general than just this, and are mostly just a framework to restate problems to. In fact, we can restate lattice reduction as a hidden dihedral subgroup problem. But importantly, quantum computers are really good at operating on Abelian groups, but have, at least so far, have not shown any success whatsoever on non-Abelian groups. This does make sense, given their construction, and gives us some data on why lattices have withstood quantum cryptanalytic attacks so far. ### Share this: * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Like Loading…
24217
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
MikroTik @mikrotik.social · 03/09/2026
🚨 We have released a critical security update in all RouterOS release channels. Even though the fixed issue does not affect most home users with default configuration, we still suggest to treat this seriously and upgrade your MikroTik routers and inform other users. To give time to update your […]
mikrotik.social
Original post on mikrotik.social
1720
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 30/08/2026
Oh for fuck's sake what is wrong with these people? " #Calibre 9.14 introduces more #AI features, including the ability to generate #book covers using AI with different cover styles such as #romance, #scifi, pulp #fiction, etc., as well as #Anthropic and #Grok backends for #Claude and Grok […]
eupolicy.social
Original post on eupolicy.social
0010
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 24/08/2026
www.librarian.net/notoai is a nice summary of current settings/options on AI tooling integrated into standard apps.
librarian.net
How to disable or avoid intrusive AI
[_Put on your own oxygen mask first! Image from San Diego Air and Space Museum Archives_] One of the biggest questions I get at Drop-In Time at the library (besides “what is taking up all my cloud storage?”) is how to disable or avoid intrusive AI that shows up where people don’t want it. This is a guide for people who would like less intrusive AI in their tech environment. Maybe you like AI and find it useful? That’s fine, this document is probably not for you. Additions/edits welcome. Leave a comment or drop me an email. This page is available at the short URL https://NoToAI.org ## Adobe Acrobat * Windows: **Menu > Preferences > Generative AI** * macOS: **View > Preferences > Generative AI** Uncheck the checkbox on the page, click **Save**. ## Adobe Reader Choose **Disable new Acrobat Reader** from the top menu (upper left), approve the dialog box and restart. ## Android/Gemini Depending on your phone’s manufacturer, you may be able to uninstall the Gemini app entirely. If not, there are some application-specific ways you can turn off some of its features ### Messages Tap **your account** picture, select **Messages settings** , then **Gemini in Messages** , and toggle the assistant off. ### Other features in other apps Tap your profile icon, select **Gemini Apps activity** , and then choose **Turn off** or **Turn off and delete activity**. Next, tap the profile icon again and go to the **Connected Apps** setting (check the **Personal Intelligence** setting). Disable all the apps where you don’t want Gemini. ### Power Button If Gemini has “taken over” your power button, you can turn this off. Go to **Settings,** then **System** , then **Gestures** and change the settings under **Press & Hold Power Button** If that doesn’t work you can try opening **Settings** , then searching for **Power key** ## Apple Intelligence & Siri Only exists on iPhone 16 and newer Macs and iPads Open **Settings** (iPhone or iPad) or **System Settings** (Mac) and choose**Apple Intelligence & Siri**. Then turn off the **Apple Intelligence** option. Confirm your choice in the dialog that appears by tapping **Turn Off Apple Intelligence**. More details on how to turn off specific parts of Apple Intelligence and leave others alone. Apple has a “learn from this application” feature which can be on even when Apple Intelligence is not on. To turn it off For Mac: go to **System Settings** – **Apple Intelligence & Siri**. Select **About Siri, Dictation & Privacy…** near the end of the page, turn off apps you don’t want Siri to learn from For iOS: **Settings** – **Apple Intelligence & Siri**, scroll down to **Apps** , disable “Learn from this App” ## Browser-embedded AI ### Chrome/AI Nano Type **chrome://flags** into the address bar and hit **Enter**. You’ll see a list of system flags and a search bar; look for **GLIC** [Google live in Chrome]. This will filter the massive list down to about a dozen AI features. The second search term you’ll need in this window is “**Gemini** ” set them all to “disabled.” Don’t accidentally enable the couple of settings which default to disabled. ### Edge Similar to Chrome: type **edge://flags** into the Edge address bar, hit **Enter** , then type “**AI** ” or “**Copilot** ” into the search box. Click **Appearance** in the left-hand Settings sidebar, and scroll down to **Copilot and sidebar** Turn the sidebar **off** , and turn off the “**Personalize my top sites in customize sidebar** ” and “**Allow sidebar apps to show notifications** ” toggles. Click**Copilot** under **App specific settings**. Turn off “**Show Copilot button on the toolbar**.” Then, back in the **Copilot and sidebar** settings, turn off the **“Show sidebar button”** toggle that has just appeared. Click **Languages** in the left-hand navigation. Disable **“Use Copilot for writing on the web.”** ### Firefox The latest Firefox (148 and later) has a feature to block all AI enhancements. So update, if you can, go to **Settings** and look for **AI Controls**. Turn **Block AI Enhancements** on (or select more granularly from the list) Using Firefox, this extension removes a lot of the AI junk if you use Google as your default search engine. * * * * More details on removing AI slop from search results in different browsers. * Here is a link for how to do this in DuckDuckGo and Bing. * TenBlueLinks gives you some simple steps to do this in Chrome/Firefox ### DuckDuckGo DDG is both a browser and a search engine. They have a no-AI version you can get to by going to https://noai.duckduckgo.com/ You can also change your default search engine to this and stop using Google, here are steps for every browser. If you want to go all out and get the DDG browser, they also have instructions on how to do that. ## Google Workspace (Gmail, Google Docs &c) In Gmail, click the Settings (gear) icon, and then select **See all settings**. On the **General** tab, scroll down to **Google Workspace smart features**. Click **Manage Workspace smart feature settings** and toggle off two options: **Smart features in Google Workspace** and **Smart features in other Google products**. Uncheck the box next to **Turn on smart features in Gmail, Chat, and Meet** on the same tab. In Gmail for Android the workspace smart features are under the **Gmail hamburger/dropdown** menu – **Settings** – **Account name** ## Slack Owners and admins of Slack workspaces have some options in disabling AI features. Here is their help page about managing those features. ## WhatsApp AI lives in here in a few places. Suggested Replies, go to **Settings – Chats – Suggestions & smart replies** and toggle off **Suggested replies**. **AI Sticker suggestions** can be shut off in that same menu. For AI message summaries, those are managed in a different location: **Settings – Notifications – AI message summaries**. Depending on what operating system you’re running, it may also be in **Settings – Chat – Private Processing – Private Processing Features** ## Windows 11/Copilot Copilot exists both as an embedded AI agent in Office 365 and also built into the Windows 11 operating system. Right-click the **Copilot** entry in the **Start** menu and select **Uninstall**. If that option isn’t there, head over to your installed apps list (**Start – Settings – Apps**) and uninstall Copilot from there. In certain builds of Windows 11, Copilot is stuck into the OS, so a simple uninstall might not work. In that case, you can toggle it off via the settings: **Start – Settings – Personalization – Taskbar** –**turn off Copilot** **File Explorer** has some AI built into it which can be turn-onable accidentally. To remove. **Start – Settings – Privacy & Security – Click to Do.** **Notepad** has its own special Copilot, so you’ll need to disable AI there separately. Open the Notepad settings, find the **AI features** section (or a sparkly icon near a **Writing Tools** section), and toggle Copilot off. **Office 365/Outlook** There is a separate **Enable Copilot** checkbox in each app and the checkbox only applies to that app on that device. Read more about how to turn it off. If you don’t have that option, you can change your privacy settings to disable Copilot. “**Text and image generation** ” are turned on by default, affecting Notepad, Photos, Snipping Tool, and Xbox. Turn this off. It is complicated, though not impossible, to remove Copilot from your Windows computer entirely. Here is a link that gets into the details. If you feel comfortable installing software O&O ShutUp 10 is one way to do that, Win11DeBloat is another. ## Yahoo Mail Cick the **… More** on the bottom of the left-hand sidebar, select **Settings,** select **AI Features** and switch Message summaries off. ## Zoom Sign in at Zoom.com. Scroll to **My Account** on the left and select **Settings**. Go to the **Zoom AI** tab on the right where you can disable everything. Note: new AI options get added and they default to “on” so check back. To the right of the **Zoom AI** tab click on **My Notes** and disable “Allow participants to transcribe meetings with My Notes” ## Other useful AI Removal/Detection links * How to un-AI your internet * Library Freedom Project has a lot of handouts about AI on their Resources page * Do Not Talk To Me About “AI” printable cards Inspired by the librarians from Bangor. Last updated 16aug26
011
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 23/08/2026
RE: blob.coffee/@miramarco/117144166001… Every time I have to use #GoogleMaps I'm amazed by how low its data quality is and how little detail the map data has as compared to #OSM. The only thing it seems to do well is routing cars and showing up-to-date #POI. Pedestrian or hiker? […]
eupolicy.social
Original post on eupolicy.social
102
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Lina Lastname @lina.ohai.social.ap.brid.gy · 21/08/2026
new blog post! lina.sh/blog/hijacking-e164-arpa i hijacked some telephone infrastructure of a few islands over the span of multiple months; and accidentally logged information of a few hundreds of thousands of phone calls going to military bases in the process.. it's a really really […]
ohai.social
Original post on ohai.social
31879
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 18/08/2026
I just watched the #BlackHat #OpenAI #HuggingFace talk (www.youtube.com/watch?v=87DyyMV0kCY) and have ... mixed feelings, to be polite about it: 1. I didn't hear a "we messed up and are sorry about our mistakes", but this was another marketing talk dressed up to look like an innocent […]
infosec.exchange
Original post on infosec.exchange
001
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 17/08/2026
Between AI slop overwhelming verified information, search engines becoming significantly worse, Cloudflare starting a payment service for service access through AI agents, and age verification for the few trending human users, I fear we are witnessing the end of the open Internet.
111
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Liam Proven @lproven.social.vivaldi.net.ap.brid.gy · 16/08/2026
1230971167
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 15/08/2026
That noise you're hearing is all the cryptographers working on PQC (and particularly lattices, but a breakthrough like that would have likely had far reaching consequences beyond just lattices) collectively breathing out after holding their breath for a week. eprint.iacr.org/2026/1693
0256
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Sophie Schmieg @sophieschmieg.infosec.exchange.ap.brid.gy · 10/08/2026
Woohoo, the TLS key exchange algorithm Chrome, Firefox, and friends have been using for the last two years is now an actual standard! datatracker.ietf.org/doc/html/rfc10…
datatracker.ietf.org
RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange.
14017
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Richard de Waard @waardrichard.social.edu.nl.ap.brid.gy · 02/08/2026
“Vaporizing a car’s worth of aluminum, other metals, and chemicals in the upper atmosphere, every hour, indefinitely? Not good.” #spacedebris #space #sustainability #satellites #megaconstellation buttondown.com/creativegood/archive…
2116
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
spooky Deirdre Connolly¹ ² at a distance @durumcrustulum.com · 06/08/2026
"LLM-generated patches did not resolve the vulnerability, added a new vulnerability, or both, an average 53.9% of the time." 👁️👄👁️ 1password.com/blog/why-ai-...
LLM-generated patches did not resolve the vulnerability, added a new vulnerability, or both, an average 53.9% of the time. You can read further details about our findings, observations, and conclusions in the research paper we’ve published alongside this post.
3174120
René Mayrhofer :verified: 🇺🇦 🇵🇸 @rene-mobile.infosec.exchange.ap.brid.gy · 03/08/2026
RE: floss.social/@jgoerzen/117032366113… This is a blast from the past. I fondly remember Kermit from BBS days. Yes, that was with (DR)DOS...
floss.social
001
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
bontchev.infosec.exchange.ap.brid.gy @bontchev.infosec.exchange.ap.brid.gy · 01/08/2026
A computer can never be held accountable...
02496
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
abadidea @0xabad1dea.infosec.exchange.ap.brid.gy · 31/07/2026
OpenAI: we put our evilest AI in a sandbox that did in fact have an internet connection but mediated through a proxy that was only supposed to allow downloading python junk. It circumvented the proxy and we failed to notice for FIVE DAYS that it was going on an interstate crime spree with the […]
infosec.exchange
Original post on infosec.exchange
522155
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Scary "Grampus" Jerry 👻 @jerry.infosec.exchange.ap.brid.gy · 31/07/2026
Anthropic: “our models went rogue and hacked companies way before that OTHER company’s models. And it was way worse and way better at the same time. In completely unrelated news, we are IPOing soon. Don’t forget! XOXO” www.anthropic.com/news/investigatin…
5840
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jan Penfrat @ilumium.eupolicy.social.ap.brid.gy · 27/07/2026
Important reminder that tech solutions like #encryption, panic buttons, and duress #passwords alone are unlikely to save us from #authoritarianism. #Democracy and #HumanRights need organising and real-world resistance to be protected […]
eupolicy.social
Original post on eupolicy.social
015
Reposted by René Mayrhofer :verified: 🇺🇦 🇵🇸
Jess👾 @jesstheunstill.infosec.exchange.ap.brid.gy · 25/07/2026
Just imagine if we'd invested over a trillion dollars in green energy rather than AI.
10105210