Tag Archives: Uncategorized

DarkSword Malware

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/darksword-malware.html

DarkSword is a sophisticated piece of malware—probably government designed—that targets iOS.

Google Threat Intelligence Group (GTIG) has identified a new iOS full-chain exploit that leveraged multiple zero-day vulnerabilities to fully compromise devices. Based on toolmarks in recovered payloads, we believe the exploit chain to be called DarkSword. Since at least November 2025, GTIG has observed multiple commercial surveillance vendors and suspected state-sponsored actors utilizing DarkSword in distinct campaigns. These threat actors have deployed the exploit chain against targets in Saudi Arabia, Turkey, Malaysia, and Ukraine.

DarkSword supports iOS versions 18.4 through 18.7 and utilizes six different vulnerabilities to deploy final-stage payloads. GTIG has identified three distinct malware families deployed following a successful DarkSword compromise: GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER. The proliferation of this single exploit chain across disparate threat actors mirrors the previously discovered Coruna iOS exploit kit. Notably, UNC6353, a suspected Russian espionage group previously observed using Coruna, has recently incorporated DarkSword into their watering hole campaigns.

A week after it was identified, a version of it leaked onto the internet, where it is being used more broadly.

This news is a month old. Your devices are safe, assuming you patch regularly.

Hacking Polymarket

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/hacking-polymarket.html

Polymarket is a platform where people can bet on real-world events, political and otherwise. Leaving the ethical considerations of this aside (for one, it facilitates assassination), one of the issues with making this work is the verification of these real-world events. Polymarket gamblers have threatened a journalist because his story was being used to verify an event. And now, gamblers are taking hair dryers to weather sensors to rig weather bets.

There’s also insider trading: a lot of it.

Amazon Q Developer end-of-support announcement

Post Syndicated from Ankit Sharma original https://aws.amazon.com/blogs/devops/amazon-q-developer-end-of-support-announcement/

When we launched Amazon Q Developer, our goal was to bring AI assistance directly into the developer workflow. Customers adopted Q Developer across VS Code, JetBrains, Eclipse, and Visual Studio, using it for code generation, debugging, and chat-based guidance. Q Developer proved that AI belongs in the inner loop of software development.

Over the past year, we’ve learned that the most impactful AI developer experiences go far beyond code generation and completion. Developers need AI that understands their entire project: the architecture, the requirements, the tests, and the intent behind the code. It requires a purpose-built environment. That’s why we built Kiro.

What is Kiro? Kiro is an agentic development environment (IDE, CLI) built from the ground up for spec-driven development. Instead of reacting to individual prompts, Kiro works from structured specifications to plan, implement, and verify changes across your entire codebase. Key capabilities include:

  • Specs — Define what you want to build in structured, natural-language requirements that Kiro uses to drive implementation end to end.
  • Hooks — Automated triggers that run on file save, commit, or other events to enforce standards, run tests, or update documentation without manual intervention.
  • Steering files — Project-level configuration that gives Kiro persistent context about your architecture, conventions, and constraints.
  • Custom subagents — Specialized AI agents you define for domain-specific tasks like security review, API contract validation, or infrastructure provisioning.
  • Powers — Composable capability modules that extend Kiro’s agentic behavior for your specific workflows.

Kiro also includes everything developers rely on in Q Developer today: agentic coding, inline chat, terminal integration, and MCP support.

What’s changing Amazon Q Developer IDE plugins and paid Subscriptions will reach end of support on April 30, 2027, giving customers 12 months to transition to Kiro.

  • New signups will no longer available starting May 15, 2026. New Q Developer Free Tier account creation (via Builder ID in IDE plugins) and new Q Developer subscription creation (via the AWS Console) will be blocked.
  • Model changes: starting May 29, 2026, Opus 4.6 will no longer be available on Q Developer Pro. Opus 4.5 and all other existing models remain available. The latest coding models, including Opus 4.7, are available exclusively on Kiro.
  • Existing customers retain access. If you access Q Developer via a Q Developer Pro subscription or Kiro subscription, you will continue to have access to the Q Developer IDE plugins until April 30, 2027. The May 15, 2026 change affects new signups for Q Developer accounts and subscriptions.
  • IDE plugin listings remain live. Q Developer plugins will remain published on all four IDE marketplaces with a deprecation notice directing users to Kiro. Critical bugfixes will continue to be pushed to existing users through the transition window.

What’s not changing Amazon Q Developer in the AWS Management Console and first-party AWS experiences (AWS Marketing Website, AWS Documentation Website, AWS Console Mobile App, and Amazon Q Developer for Chat Apps – Slack & Microsoft Teams) are not impacted by this sunset and will continue to be available to AWS customers. Customers using Q Developer in these products will retain access to their current subscription benefits and capabilities.

What you should do

  • Explore Kiro today. Download Kiro at kiro.dev and try spec-driven development on your next project.
  • Review the migration guide for your specific IDE.
  • If you have questions about migrating, contact your AWS account team.

We’re excited about the future of AI-powered development and we’re committed to making this transition as smooth as possible for every customer.

Промените, които носи AI

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2695

Писал съм и преди за тях. Отначало колебливо – чувствах се неадекватен фантазьор. Но напоследък все повече хора пишат същото или части от него. Ето поредната статия по темата:

https://shumer.dev/something-big-is-happening

И реших, че е добре да напиша нещо полезно за който има акъл. Който не чете дълги неща – за него си е, мога да му кусна в устата, но не и да глътна вместо него. И да не ми циври после, че не е знаел навреме.

—-

1. Технологичните революции

AI не е първата технологична революция на човечеството. Преди него бяха компютрите. Преди тях – атомът. Електричеството. Парата. Индустрията… Та чак до стиснатия в питекантропския юмрук камък.

Не, всъщност преди това – слизането от дърветата. Не, всъщност още преди това – качването на тях… До първата жива клетка. Всяка еволюционна промяна е по същество технологична революция, и обратното. Много различно ли е за един хомо хабилис умението да издяла каменен нож от еволюцията да му поникнат страшни зъби?

А технологичните революции не са милостиви. При индустриалната по света са измрели от глад и мизерия милиони селяни, ненаучили се да са работници. Десетки милиони са потънали в мизерия, когато електричеството е изместило парата. Световна атомна война ни се размина, но знаем какво би причинила атомна бомба дори на могъща и добре подготвена армия от 1940-те, за милионен град да не говорим. Компютрите оставиха без работа стотици милиони „сини якички“… Винаги по една и съща причина – неподготвените за новото остават излишни.

В по-нови времена – все повече по свой избор. Крепостните селяни не се учеха да четат, понеже книгата хляб не раждала. „Сините якички“ не учеха компютри, за да не си развалят очите. И едните, и другите разбраха грешката си по трудния начин и платиха за нея с късен и лош старт. С тези, които днес не учат AI, ще е същото.

Много от тях са убедени, че работа за фермери, зидари и готвачи ще има винаги. Същото мислеха орачите преди тракторите, преписвачите на книги – преди печатарската преса, каруцарите – преди колите… А колко професии го мислеха преди компютрите – да изброявам ли?

Новото не само унищожава работни места. Обикновено и създава нови, често напълно неочаквани, и често още повече от унищожените. Но каймака го обират първите пренаучили се. За другите остава утайката, ако изобщо я има. Изберете си от кои искате да бъдете.

2. Този път е различно!

Точно така са мислели и орачите преди тракторите, преписвачите преди печатарската преса и т.н. Всеки път е било същото, просто те не са искали да го разберат, защото не са били на кеф. И са си плащали после.

Само че този път наистина е различно. Проблемът е, че не по добрия начин.

Един трактор заменя десетки орачи, но не оре без тракторист. Първите орачи, които се научат да го карат, живеят по-охолно отпреди. Печатарските преси също не могат без работници. Камионите без шофьори. Компютрите – без работещи на тях… Често много по-малко от заменените, особено отначало, но все пак хора.

Тук е разликата. AI все повече нямат нужда от оператор – вършат все по-добре работата му и сами. Вече сме не просто на ръба AI да може да изпълни задача или да отговори на въпрос по-добре от всеки човек. На ръба сме той да може да формулира задачата или да зададе въпроса по-добре от всеки човек.

Ама и AI имат нужда някой да пише софтуера им? Също вече не. Последните версии на почти всички големи AI са написани предимно от предишните им версии. Скокът във възможностите им се дължи предимно на това. И тези много по-добри последни версии в момента пишат следващите, още по-добри от тях, с още по-голяма разлика. Последният модел на Anthropic – Mythos – вече е далеч по-добър и от най-добрите програмисти в софтуерните задачи. Толкова по-добър, че засега е непубличен, за да не откриват чрез него хакери екплойти в дори смятани сега за непробиваеми софтуери… Познайте дали не е също толкова по-добър от сегашните модели и в други отношения. Подобренията, влезли в него, няма как да са само в един вид умения, LLM-ите не работят така – ще са във всички.

В софтуера нещата са най-напред. Не толкова защото ударението по създаване на AI беше там – по-скоро защото програмните езици са силно формализирани, простички и детерминистични, с тях AI се справя по-добре с едни и същи ресурси. Но и във всичко друго нещата не са много по-назад – да кажем, едно-две поколения модели. Сега актуалният публичен модел на Anthropic – Opus – е в софтуера на нивото на приличен, макар и не блестящ програмист, а примерно в разбирането на човешките чувства – където предишният им модел, Sonnet, е в програмирането. Mythos надмина дори отличните програмисти в софтуера, по-добри от него са само гениите – логично е в разбирането на човешките чувства да е на нивото на Opus в програмирането. Все още не блестящ, но вече добър, на нивото на Opus в софтуера.

Конкуренцията между големите AI фирми е безмилостна – която изостане и с месец, почва да трупа изоставане и потегля към фалита. Така че Mythos с гаранция вече пише на максимални обороти следващия модел. Който ще има програмистки умения, много по-добри от това на написалия го, надминаващи тези и на гениите програмисти. (Терминът за такова ниво е “transhuman”.) Познайте и в колко други неща ще надмине повечето хора този следващ модел. По-следващият вероятно ще надмине във всичко или почти всичко всеки човек, освен може би гениите в най-трудните за AI области. Този след него ще надмине хората в абсолютно всичко… А следващият след него? А по-следващият?…

Преди ново поколение AI модел се създаваше от нула до зрялост за към две години, първите версии на ChatGPT отнемаха към толкова. При Sonnet това отне дори мъничко по-малко от година, 11 месеца и половина. Opus измина този път само за около 9 месеца – Sonnet вече що-годе ставаше за програмиране и помагаше, към една трета от Opus е написана от него или с негова помощ. Mythos (по непублична информация) вече е почти зрял, по-малко от 5 месеца след започването му – вероятно ще измине този път за около 6 месеца, и разликата от него до Opus е доста по-сериозна от тази от Opus до Sonnet. Благодарение основно на това, че Opus вече е приличен програмист, твърди се, че към две трети от Mythos са написани от него… Следващият модел, да го наречем условно Legend (Антропик, безплатна идея за вас! 🙂 ), като се има предвид колко добър е Mythos, вероятно ще е написан почти изцяло от него, вероятно ще има още по-голямо предимство пред предшественика си, и вероятно ще е вече зрял след 3-4 месеца. (Дотогава нищо чудно Mythos да е още непубличен.) По-следващият, да го наречем условно Superman, вероятно ще е с още по-голяма разлика от Legend, и ще е готов може би за 3 месеца или дори малко по-малко. А моделът след него вероятно ще е богоподобен на фона дори на Superman, ще стане готов за вероятно не повече от 2-2.5 месеца и вероятно ще е най-подходящо да го наречем God… Quo vadis – накъде отиваме? Може би до не повече от година?

2027 година е. Шеф сте на софтуерна фирма. Legend програмира много по-добре от кой да е реално привлекаем жив програмист. Конкурентите му от OpenAI, Google и прочее – също. Достъп до AI, който върши работата на 100 програмисти – с перфектно качество, винаги в срок, никога не боледува, няма проблеми, не взима отпуски, работи 24/7 – ще към 1000 долара месечно, стандартна корпоративна цена сега. Ще държите ли на работа 100 програмисти, или ще купите един такъв достъп? Глупав въпрос, нали?

Три до шест месеца след това. Актуалният модел на Antropic вече е Superman. Шеф сте на компания за какъв ще да е интелектуален труд. Дизайн, инженерство, архитектура, песни, книги, филми, наука, право, счетоводство, медицина, обучение… добавете пропуснатото. Достъп до AI, който върши работата на 100 служители… глупав въпрос, нали?

Още три до шест месеца по-късно. Актуалният модел на Antropic вече е God. Шеф сте на компания за какъвто и да е физически труд. Строителни услуги, хамаллък, садене на марули, бране на ябълки, продаване в магазин, гледане на болни, планинско спасяване, развличане на деца, метене на улици… добавете пропуснатото. Вече има машини – някои от тях човекоподобни роботи, други специализирани – проектирани, произведени и управлявани от God или конкурентите му. Достъп до машина или набор машини, които вършат работата на 100 бачкатори… глупав въпрос, нали?

Да, досега проектирането, изпитването и производството на толкова нови и много машини е отнемало десетки години. Познайте обаче колко време ще отнеме на God, или на следващия след него модел, или на по-следващия, готов след година – година и половина. Вероятно след броени години ще има достатъчно такива машини, за да изместят всеки човек.

Тази екстраполация е базирана на Sonet, Opus и Mythos. Sonnet и Opus ги познавам добре. Възможно ли е да са ми прехвалили Mythos, както не мога да се уверя лично? Да – но надали с много. Че е достъпен засега само за 12 големи, предимно софтуерни организации, точно заради брилянтността му в софтуера, е потвърден факт. (Намира с лекота купища експлойти и в най-сигурните сегашни софтуер – докопат ли го хакерите, в света ще настане хаос.) Така че темпото на развитие би могло да е малко по-бавно, може би чак двукратно, но не повече. А двукратно по-бавно означава масовите уволнения заради изместване от AI да се случат след 2 години вместо след 1. Ако това ви успокоява, сте герои от виц. Недейте, скоро и с палячовство няма да може да се изкарва доход, смешни наоколо ще има в излишък.

И да, публикуването на нов модел очевидно може да бъде забавено по едни или други причини. Но засега няма механизъм, който ще забави разработката на нови модели, дори ако старите още не са публикувани. Не само заради конкуренцията между AI фирмите. Коя агенция за сигурност на държавата ще позволи развитието на нейните AI да бъде спряно, докато в това време потенциалните ѝ врагове развиват AI като бесни?… И когато поредният модел стане способен да създаде лекарство против рак и да забави или дори спре стареенето, надали ще бъде скрит за дълго, примерно за цяла година – който го скрие, ще е заслужил каквото всички извършители на геноцид в историята заедно не са. Така че забавяния може да има, но надали ще са много големи.

Мислите иначе ли? За такива неща мислят глупавите, умните смятат. Ако можете да смятате, направете си и вие сметките колко бързо пътува този влак и им вярвайте. Ако не, вярвайте на който може да смята. Иначе ще сте урок за по-умните.

Ще станат ли хората непотребни? Надали. Нищо чудно добри решения по въпроса да дойдат именно от AI-та. Но се пригответе да живеете скоро в свят, различен от сегашния.

3. Икономическите последствия

2027-8-9 година е. Шеф сте на фирма. Конкуренцията ви е подменила част от служителите си с AI. Спестила е разходи за заплати, надконкурира ви. Какъв е изборът ви? Оставате шеф на фирма само ако направите същото. Иначе фалирате.

Правите го. Отново сте в бизнеса. Но там винаги има и най-неконкурентен, влак без последен вагон няма как. Какъв е изборът му? Подменя още служители с AI, иначе фалира. Последният вагон е откачен и изоставен или преместен напред – последен става този преди него…

Скоро всички служители във фирми са подменени с AI. Малко по-късно и всички работници. Където преди са работели хиляди, сега има само шепичка шефове. За кратко – кой шеф може да бъде по-кадърен и лоялен от от поколението Superman, да не говорим за God?… Много скоро след това фирмите имат вече само собственици. А конкуренцията между тях не спира – най-неуспешните фалират, други ги изкупуват, агрегацията тече с AI скорост. Докато се огледате, наоколо са останали един файтон свръхбогаташи, всички други са разорени.

Харесва ли ви идеята? „Ако съм свръхбогаташ – да!“ Да, ама не – спали сте в час по икономика. Нека наваксаме проспаното.

Заводите „Форд“ в САЩ са ваши. Произвеждате и продавате по 10 милиона коли годишно. Марджинът ви е 5%, при 400 милиарда годишен оборот печелите 20 милиарда годишно. Но подменяте всичките си работници с AI и марджинът ви става заради спестените заплати 50%. Годишната ви печалба ще е 200 милиарда, десетократно по-голяма. Шампанско, моля! И нови яхти!

Но месец по-късно от почти милион коли месечно продажбите ви са спаднали на към 2000. Годишно ще са 24 000, и годишната ви печалба е станала вместо 200 милиарда годишно към 500 милиона. Вместо да скочи 10 пъти, е паднала 40 пъти. Защото всеки фирмаджия в САЩ е постъпил като вас – подменил е с AI всичките си работници или служители. И те, останали без заплати, вече не могат да си позволят да купуват коли. Правят го само малкото все още работещи, заради връзки или по милост, в държавната и общински администрации.

Докато се опомните от вестта, AI-шефът на заводите ви предупреждава и че обемът на покупките ви на материали, ток и всичко друго е спаднал драстично. Така че вече пазарувате на доста по-дребно и доставните ви цени са скочили с 20%. Поемете ли вие разликата, марджинът ви слиза на 30%, печалбата – на 300 милиона годишно, вече почти сто пъти по-малка отпреди подмяната. Качите ли цените си с 20%, продажбите ще спаднат и още, обемът на покупките ви на материали също, цените им ще скочат още – бизнесът ви влиза в свредел.

Нямате избор. Орязвате печалбата си. Все пак 300 милиона годишно пак са много в такава ужасна криза. (Че тая криза я създаде подмяната на работници с AI, в която участвахте и вие, предпочитате да не си спомняте.) Но много скоро иде нов удар – продажбите на практика спират. Заради 100 пъти намалената ви печалба сте платили 100 пъти по-малко данък и държавната и общински администрации, които живеят от данъците, вече не могат да плащат заплати. Подменили са служителите си с AI и те също вече не могат да купуват коли… Дори да спрете производството напълно, вече не можете да плащате дори на фирмата за роботи-охранители с AI. Налага се да продадете заводите си, докато крадците не са ги опоскали и времето не ги е съсипало.

А на кого? Всички други големи фирми са също във фалит. Даже фирмите зад големите AI – могат да устискат на сериозно намаление на приходите си, но не и на спадане до 1%, а вече няма кой да може да им плати и толкова. Банките са фалирали до една заради трилионите заеми за жилища и прочее, които са станали необслужваеми – останалите без заплати заемополучатели нямат с какво да плащат вноските си. А ликвидността на една банка рядко е над 20% – ако над такъв процент заеми гръмнат, гръмва тя цялата… Чудо ще е, ако за заводите ви, стрували стотици милиарди, сега някой ви даде и милион. Вече не сте мултимилиардер – надали сте и милионер даже.

Да кажем, чудото се е случило, успели сте да намерите такъв. Все пак сте взели един милион. Но какво ще си купите с него? Магазините са затворени – кой има пари, че да купи каквото и да е?! Бившите свръхбогаташи сте единици, а останалите нямат пукнат цент. Същото важи за всички услуги – транспорт, бензиностанции, ток… Фермерите, които още имат земя и машини, вече искат да произвеждат храна само за себе си – но откъде части и гориво дори за това?!… И вече се чудите не на коя от яхтите си да празнувате, а как да се нахраните.

Икономиката е кръговрат. Произвеждате стоки или услуги, продавате, плащате на работниците, те с тези пари си купуват стоки и услуги. Не е перпетуум мобиле, защото етапът на производството в този кръг създава повече стойност, отколкото консумира. Така че върти ли се кръгът, производството непрекъснато създава принадена стойност, плюс над разходите, и тя се разпределя навсякъде в кръга. Има и за покриване на неизбежните загуби, и за данъци, и за вашата и на работниците издръжка, и за тях да спестяват, и за вас да богатеете – тоест, за да расте икономиката като цяло… Но спре ли да се върти кръгът, примерно защото работниците вече нямат пари да купуват, спира и производството, а оттам и създаването на принадена стойност. Приходите стават нулеви. Вчерашните мултимилиардери почват да умират от глад. А някои от неизбежните разходи продължават и унищожават и останалото от спрялата икономика.

(Този механизъм, в много по-лек вариант, е причината за Великата депресия от 1929 г. Вярването в trickle-down теорията и дерегулацията, неглижирането на антитръстовските закони и на опасността от растящото икономическо неравенство създават условия много от парите в обществото да бъдат изтеглени „горе“, при най-богатите. Те обаче са нищожен процент, техните потребителски нужди са нищожни на фона на тези на хиляди пъти по-многобройните средна класа и по-бедни. Създава се ситуация, в която който има нужда от стоки и услуги няма достатъчно пари да купува, а който има достатъчно пари, няма достатъчно нужда от покупки. Потреблението спада с около 30%, производството – БВП на САЩ – също. Резултатът е незапомнена безработица и мизерия. От 30% спад в потреблението. А спадът в потреблението заради AI революцията вероятно ще е много по-голям, теоретично може да доближи 100%…)

4. Справяне с икономическите последствия

Ще бъдат ли взети мерки да се избегне катастрофата? Вероятно да – както виждаме, дори свръхбогаташите имат нужда от тях, и то повече от клошарите или даже работниците. Не е сигурно обаче дали ще са взети достатъчно и с достатъчно ефект.

Ефективните срещу такъв проблем мерки са видове преразпределяне на парите откъдето са се концентрирали силно към където има капацитет за масово потребление. Ляво правителство е по-вероятно да предприеме достатъчни, за да не рухне икономиката. (Въпреки че и тези правителства обикновено имат задкулисни връзки с големите пари, които ще ги спират.) Дясно може да прояви разум и да се жертва, но може и да не вземе достатъчно и/или ефективни. А реакционери и/или политически измамници с мераци за корони и тронове вероятно дори ще се възползват от ситуацията, за да се сдобият с абсолютна власт. (Великата депресия е основна причина за мизерията в Германия през 1930-те, която докарва Хитлер на власт.) Ако сред тях има и собственици на големи AI, изкушението те да бъдат използвани за установяване на технототалитарен абсолютен контрол е много силно, и рискът за това общество е огромен.

Какви общества имат най-голям шанс да се справят добре с такава икономическа ситуация? Няма как да се предскаже с гаранция. Но при равни други условия най-добри шансове имат социални общества със силна либерална демокрация, кадърна регулация на AI бизнеса, ниска корупция, високо грамотен народ и към този момент с кадърно и не-популистко лявоцентристко правителство.

Ще има ли не само на теория, а и в реалността необходимото осъзнаване сред ключовите играчи на необходимостта да бъде запазена покупателната способност на масовите потребители? Някои дори вече го заявяват открито – примерно съм срещал подобни твърдения на Илон Мъск. Много други засега не са го казвали, но е малко вероятно да не го разбират. Някои обаче вероятно не го разбират и ще противодействат на адекватните мерки, особено твърде обвързаните с десни идеологии. (Идеологията на мозъка е тежък вид лудост. Не я подценявайте.)

Какви механизми могат да реализират нужното? Най-често обсъжданата и най-проста идея е безусловен базов доход за всички. Тя обаче има сериозен недостатък – би създала уравновиловка в обществото, а изравненото икономически общество не е добро за развитието. За него е нужен спектър на богатството – не прекалено широк и маргинализиран, но не и прекалено тесен. (Едно по-сериозно отърсване на икономиката от идеологиите и създаване в нея на нетърпимост към тях вероятно би позволило на кадърни учени и/или мощни AI да изведат формулите за определяне на оптималното за всяка икономическа ситуация разпределение на богатството в обществото. Но ще е трудно да се постигне, през последните няколко години икономиката се идеологизира до екстремна степен.) Така че вероятно ще е нужно да се помисли за подходящи механизми, способни да разпределят богатството в обществото по определен спектър, и да променят този спектър при икономическа необходимост.

Какви биха били ключовите проблеми пред това реализиране? Икономиката е ентропийна отворена система, подчиняваща се на статистическата механика. В такава система негентропията проявява тенденция към концентриране към „входящата зона“. Казано икономически, парите проявяват тенденция към концентриране в зоната, където принадената стойност навлиза в системата. По начало това е зоната, в която тя се създава – производството. Законодателни или икономически мерки могат да я изместят другаде, примерно в зоната на управление на потока на парите (банковата система). Силна мафия може да я измести в зоната на върхушката си, чрез грабителство. (Или ако контролира държавата – дори чрез подходящо законодателство.) Но където и да е тази зона, парите ще се опитват да се концентрират там. А концентрирането им ще се стреми да намали зоната до малка част от икономическата система.

На теория мерки, които поддържат зоната на навлизане на принадената стойност разпределена на много широка площ (включваща всичкия или почти всичкия капацитет за консумиране в икономиката), биха били оптимални в такава ситуация. Такива мерки обаче засега не са известни. Вероятно достатъчно мощен AI би могъл да предложи подходящи. Поддържането на тази зона много широка обаче е противостоене на естествената ѝ тенденция за свиване – възможно е да се окаже, че няма как да се направи достатъчно стабилно, за да издържа силни сътресения. А технологичните революции са именно такива, и при такава скорост на развитието ще са много чести.

На практика по-лесно се оказва парите в икономиката да бъдат преразпределяни от зоната, където се концентрират, към зоните с максимален потребителски капацитет. (Примерно богатите биват облагани с високи данъци, от които печелят всички – така икономическото неравенство продължава да съществува, но намалява като размер.) Известни са ни приличен брой такива механизми. Много от тях обаче имат сериозни недостатъци, например данъчното облагане често може да бъде изкривявано чрез заобикаляне на закона или вратички в него. Други начини, например разчитащите на фиксирана номенклатура, е възможно да стагнират развитието на икономиката, а може би и на технологиите и прогреса…

Като цяло, идеални мерки вероятно няма, дори за конкретно тази специфична ситуация. Но е напълно реално да има мерки, които при достатъчно широко и сериозно прилагане са достатъчно добри, за да намалят размера на икономическите проблеми до приемлив. Въпросът е дали ще бъдат приложени, и ако да – дали ще е достатъчно широко и сериозно.

5. Социалните последствия

Слагал ли е ваш колега гордо пред шефа 20 страници красив доклад, пълен с графики и прочее, как върви строежът, за който отговаря във фирмата той? Написан за една нощ с помощта на AI? Докато вие подсмърчате и се червите, понеже не умеете да се справяте с AI и докладът ви за вашия строеж е пет изречения? И разбирате отлично как изглежда в очите и на шефа, и на всички околни той, а как – вие? Не е малка разлика, нали?

(Да, докладът му вероятно хич не е идеален, съвременните AI не са още истински добри в това. Но шефът надали ще го разбере – вероятно ще накара някое AI да му го синтезира в пет изречения. Колкото е и вашият – но впечатлението от разликата ще остане… А и да забележак проблемите в доклада му, впечатлението е важното в тази история само за плиткоумните. Истински важното е, че той се е потил много часове, но се е научил как се правят хубави доклади с AI, а вие не сте. И занапред той ще посвещава още много часове за учене и трупане на нови знания и умения, често на цената на лишения и недоспиване. Докато вие най-много да научите как да правите с AI смешни картинки и какви са връзките между чакрите и предсказанията на баба Ванга. Защото толкова зор ще си дадете.)

Разликата изглежда голяма, но е микроскопична. След година-две този колега ще сложи пред шефа 20 000 страници (вероятно в електронен вид) проект за бъдещия ви строеж, подробен до последното кабарче по мебелите, перфектен във всяко отношение. Също направен за една нощ с AI, от актуалното след година поколение, преди вие да сте прочели докрай 20-те страници спецификация. След още година той за седмица не само ще направи проекта, но и ще построи сградата сам, с управлявани от AI ресурси, наети за една трета от стойността на работници. А след още година ще реализира сам със същата скорост и икономичност цели подводни или орбитални градове, Фулърови куполи или аркологии, мостове през морета или тунели под тях… Докато вие тепърва ще учите как се правят с някое чатджипити презентации и други подобни, от които вече никой не се интересува. Колко голяма на този фон е разликата с 20-страничния доклад?

Не бързайте да се депресирате, ей сега ще имате по-добър повод. Срещате тогава колегата и в разговора с него откривате, че той знае как точно се настройват резонансните струни на виола д’аморе. Може да нарисува по-добре от Леонардо изглед към Матерхорн от ледника Теодул. Да каже как точно ще се сгънат белтъчните молекули в хемоцианиновия комплекс в кръвта на краб-пътешественик, ако му инжектирате еди-кой си хемотоксин. Да докаже конектурата на Поанкаре по-елегантно от Перелман, за само няколко минути. Да разгроми на шах най-добрите сто шахматисти хора на света, в сеанс на едновременна игра срещу всичките. Да напише поезия, по-добра от тази на Верлен, на ведически санскрит или инупиак. И че е по-добър психолог и от гениите – може да разбере по едно ваше движение всичко, което ви безпокои, да ви предскаже перфектно, да ви манипулира за ваше добро или зло, по негов избор… Защото си е присадил имплант за връзка с AI, или се е научил да може всичко това по някакъв друг, дошъл от AI начин. А вие не сте.

Депресирахте ли се вече? Пак бързате. Той не само изглежда подмладен, отслабнал и с по-правилно лице. Наистина е – вече може да управлява просто с мисъл не само външността, а и възрастта си, старее само ако му се иска, подмладява се обратно когато му кефне, реално е безсмъртен. Вече никакви болести не го плашат не защото има лечения за тях, а защото организмът му вече не е податлив на тях. Може да вдигне тонове с една ръка и да улови с два пръста летяща муха със затворени очи, само по слух. Може да се гмурне до дъното на океана без да диша няколко часа и без да му пречат налягането, студът и тъмнината там. Ако изпразнят в него няколко картечни ленти, не само няма да умре на място, а след седмица-две дори без лечение ще е пак идеално здрав. И това е само началото на възможностите му. А всички те заедно са само началото на това, което ще може утре… Докато вие въздишате заради бръчките и белите си косми.

Ще стане ли всичко това за само две години? Може би не, дори въпреки скоростта на развитие на AI. Но и двайсет да отнеме, ще стане. И познайте колко ще ви утеши тогава, че е отнело по-дълго. Колегата ще пътува във влака към бъдещето, към нови и все по-невероятни чудеса. А вие ще сте останали на спирка, която за него ще е дори не Средновековие, а Питекантропие – и много скоро може да стане и Динозаврие…

Обществото ще се раздели на две групи. Група, която смогва да е актуална с развитието на технологиите, може би на цената на огромен труд и много жертви, но хората в нея сами определят съдбата си и са боговете на този свят на бъдещето. И група, която не смогва или се е отказала да е актуална, която просто се вози докъдето я закарат, и съдбата на хората в нея я определя първата група – реално те са неин добитък. Да, първата група може и да са добри към втората. Но дали ще го правят според интересите на тези във втората група, или според своите, е въпрос който е добре да си зададете.

В коя от двете групи ще сте, зависи от вас. Правите този избор в момента, с колко усилия ще посветите на учене на AI. Предупредени сте – не се оплаквайте, когато се окажете не в която група искате. Направите ли от мързел и/или глупост грешния избор, се сърдете на себе си. И ако собствените ви деца ви заплюят утре в очите, знайте, че сте го заслужили.

6. Добре, а какво да правим?

Въпросът за много повече от един милион долара.

Вече има сума ти статии по въпроса, и повечето казват едно и също. Можете да им вярвате, ако не идват от пропагандна радиоточка. Бих добавил и от мен:

– Стегнете си финансите. Веднага, не догодина. Нищо, че вече е трудно – то е, защото нещата вече се движат по нанадолнището, не ги чакайте и да наберат скорост, тогава хич няма да можете. Колко сериозни сътресения ни чакат не е ясно. Може почти да ги няма. Може да са зловещи. Когато има приличен шанс да завали пороен дъжд, е разумно да си вземеш чадър. Пък нека дъждът се размине.
– Въпросът „Какво да науча, че да ме храни следващите 10 години“ вече е индикатор за идиот. Учете каквото ще ви храни веднага, или почти веднага – ще остарее още преди да го научите. Свикнете непрекъснато да учите и непрекъснато да сменяте каквото учите, често драстично, изоставяйки плода на огромни усилия. Могъщите динозаври са измрели, защото не са се адаптирали достатъчно. Мишеподобните бозайници са оцелели, защото са.
– Днес AI не е съвършен – халюцинира, дава грешни съвети. Утре ще е много по-умен, и от днес, и от вас. Не го съдете по спомените си от днес или особено пък от вчера. Да мислите зрял юначага за бебето, което е бил, е неразумно подценяване.
– До 10-15 години, ако не се случи някакво ужасяващо бедствие, ще са възможни неща които днес изглеждат фантазия. Но ще са за който може да си ги позволи, а отначало това няма да е всеки. По-добре да можете, с пари или знания. И двете се постигат днес със здраво учене на AI.
– Учете не само как да работите с AI, а и как работи самият той. Да можете да се возите в кола не е ценност за никой, който би ви плащал. Ценност е да можете да карате кола по-добре от 99% от хората или да можете да ремонтирате или сглобите кола.
– Учете не по два часа седмично – по четири часа дневно, поне 6 дни седмично. Не от след месец – от днес, след месец вече хубавите вагони в този влака ще са заминали, а може би и лошите.
– Непрекъснато се напъвайте да научите и още, да пробвате и каквото не сте. Денят, в който си кажете „Научих достатъчно за днес“, е денят в който сте слезли от влака. Ако си казвате за нещо „Много зор ще е, но мога да го науча“, значи е важно за учене, но не е най-важното. Най-важното за учене е това, за което си казвате: „Това посмъртно не мога да го науча“ – подхващайте го веднага и без колебание.
– Каквото сте научили днес, утре вече няма да е същото, познанията ви ще са остарели до безполезност. Нормално е, възприемайте го като нещо естествено. Пренаучавайте се моментално, оставяйте днешното учене за утре само ако искате то вече да няма смисъл.
– Колкото по-напред отиват нещата, толкова повече и по-здраво учене ще ви трябва, за да не слезете от влака. Където слезете там ще останете, друг влак напред няма да има. А влакът е все по-бърз, малко допълнителен престой в него ви откарва доста по-напред, по-нататък – повече. Струва си да се напънете докрай.
– Колкото по-дълго се задържите на влака, толкова повече възможности ще имате. Ако нещата вървят с този темп, до максимум 10 години хората ще се разделят на „магьосници“ и „добитък“. В първата ще са задържалите се във влака достатъчно дълго. Във втората – останалите над 99%. Сетете се каква ще е разликата между двете, примерно в какво ще могат тези в едната и тези в другата група, и защо е добре да сте в първата.
– Вероятно с времето ще почне да има и AI с „открити познания“ (а и код на софтуера, който ги движи). Предпочитайте ги пред „закритите“ – точно както разумният човек предпочита софтуера с отворен код пред този със затворен, и откритите хора пред потайните. (Ако някой мисли иначе, не спорете с него. Умствените ресурси са ви нужни за учене на AI, не ги пилейте. Идиотите са за игнориране, не за спорене с тях.)
– Ако от някой момент нататък стане невъзможно да сте във влака без неща като мозъчни импланти и подобни, бъдете внимателни. Не ги ли вземете, изпадате. Вземете ли ги безразсъдно, ще ви се иска да бяхте изпаднали. Преценете как да го направите без риск за автокефалността си. Главата ви е за да носите шапка само ако сте плашило – на хората им е за мислене. И е полезно да я товарите здраво, и за нея, и за вас. Вид тренировка е.
– Същото важи изобщо за използването на AI. Дори да сте реалист и факт-чекър, мощта на днешен добър AI вече може да ви обамбузи здраво, ако му вярвате безпрекословно. Примерно ако сте се чули някога да кажете „Ама аз питах чатджипити!“. (И дори ако зад това не стои нечие намерение, а просто усилените през неговото богатство ваши си деформации.) Утрешните AI ще са несравнимо по-мощни – не ставайте нечии зомбита, не е живот.

Fast16 Malware

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/fast16-malware.html

Researchers have reverse-engineered a piece of malware named Fast16. It’s almost certainly state-sponsored, probably US in origin, and was deployed against Iran years before Stuxnet:

“…the Fast16 malware was designed to carry out the most subtle form of sabotage ever seen in an in-the-wild malware tool: By automatically spreading across networks and then silently manipulating computation processes in certain software applications that perform high-precision mathematical calculations and simulate physical phenomena, Fast16 can alter the results of those programs to cause failures that range from faulty research results to catastrophic damage to real-world equipment.”

Another news article.

Lots of interesting details at the links.

Claude Mythos Has Found 271 Zero-Days in Firefox

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/claude-mythos-has-found-271-zero-days-in-firefox.html

That’s a lot. No, it’s an extraordinary number:

Since February, the Firefox team has been working around the clock using frontier AI models to find and fix latent security vulnerabilities in the browser. We wrote previously about our collaboration with Anthropic to scan Firefox with Opus 4.6, which led to fixes for 22 security-sensitive bugs in Firefox 148.

As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation.

As these capabilities reach the hands of more defenders, many other teams are now experiencing the same vertigo we did when the findings first came into focus. For a hardened target, just one such bug would have been red-alert in 2025, and so many at once makes you stop to wonder whether it’s even possible to keep up.

Our experience is a hopeful one for teams who shake off the vertigo and get to work. You may need to reprioritize everything else to bring relentless and single-minded focus to the task, but there is light at the end of the tunnel. We are extremely proud of how our team rose to meet this challenge, and others will too. Our work isn’t finished, but we’ve turned the corner and can glimpse a future much better than just keeping up. Defenders finally have a chance to win, decisively.

They’re right. Assuming the defenders can patch, and push those patches out to users quickly, this technology favors the defenders.

News article.

What Anthropic’s Mythos Means for the Future of Cybersecurity

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/what-anthropics-mythos-means-for-the-future-of-cybersecurity.html

Two weeks ago, Anthropic announced that its new model, Claude Mythos Preview, can autonomously find and weaponize software vulnerabilities, turning them into working exploits without expert guidance. These were vulnerabilities in key software like operating systems and internet infrastructure that thousands of software developers working on those systems failed to find. This capability will have major security implications, compromising the devices and services we use every day. As a result, Anthropic is not releasing the model to the general public, but instead to a limited number of companies.

The news rocked the internet security community. There were few details in Anthropic’s announcement, angering many observers. Some speculate that Anthropic doesn’t have the GPUs to run the thing, and that cybersecurity was the excuse to limit its release. Others argue Anthropic is holding to its AI safety mission. There’s hype and counterhype, reality and marketing. It’s a lot to sort out, even if you’re an expert.

We see Mythos as a real but incremental step, one in a long line of incremental steps. But even incremental steps can be important when we look at the big picture.

How AI Is Changing Cybersecurity

We’ve written about shifting baseline syndrome, a phenomenon that leads people—the public and experts alike—to discount massive long-term changes that are hidden in incremental steps. It has happened with online privacy, and it’s happening with AI. Even if the vulnerabilities found by Mythos could have been found using AI models from last month or last year, they couldn’t have been found by AI models from five years ago.

The Mythos announcement reminds us that AI has come a long way in just a few years: The baseline really has shifted. Finding vulnerabilities in source code is the type of task that today’s large language models excel at. Regardless of whether it happened last year or will happen next year, it’s been clear for a while this kind of capability was coming soon. The question is how we adapt to it.

We don’t believe that an AI that can hack autonomously will create permanent asymmetry between offense and defense; it’s likely to be more nuanced than that. Some vulnerabilities can be found, verified, and patched automatically. Some vulnerabilities will be hard to find but easy to verify and patch—consider generic cloud-hosted web applications built on standard software stacks, where updates can be deployed quickly. Still others will be easy to find (even without powerful AI) and relatively easy to verify, but harder or impossible to patch, such as IoT appliances and industrial equipment that are rarely updated or can’t be easily modified.

Then there are systems whose vulnerabilities will be easy to find in code but difficult to verify in practice. For example, complex distributed systems and cloud platforms can be composed of thousands of interacting services running in parallel, making it difficult to distinguish real vulnerabilities from false positives and to reliably reproduce them.

So we must separate the patchable from the unpatchable, and the easy to verify from the hard to verify. This taxonomy also provides us guidance for how to protect such systems in an era of powerful AI vulnerability-finding tools.

Unpatchable or hard to verify systems should be protected by wrapping them in more restrictive, tightly controlled layers. You want your fridge or thermostat or industrial control system behind a restrictive and constantly updated firewall, not freely talking to the internet.

Distributed systems that are fundamentally interconnected should be traceable and should follow the principle of least privilege, where each component has only the access it needs. These are bog-standard security ideas that we might have been tempted to throw out in the era of AI, but they’re still as relevant as ever.

Rethinking Software Security Practices

This also raises the salience of best practices in software engineering. Automated, thorough, and continuous testing was always important. Now we can take this practice a step further and use defensive AI agents to test exploits against a real stack, over and over, until the false positives have been weeded out and the real vulnerabilities and fixes are confirmed. This kind of VulnOps is likely to become a standard part of the development process.

Documentation becomes more valuable, as it can guide an AI agent on a bug-finding mission just as it does developers. And following standard practices and using standard tools and libraries allows AI and engineers alike to recognize patterns more effectively, even in a world of individual and ephemeral instant software—code that can be generated and deployed on demand.

Will this favor offense or defense? The defense eventually, probably, especially in systems that are easy to patch and verify. Fortunately, that includes our phones, web browsers, and major internet services. But today’s cars, electrical transformers, fridges, and lampposts are connected to the internet. Legacy banking and airline systems are networked.

Not all of those are going to get patched as fast as needed, and we may see a few years of constant hacks until we arrive at a new normal: where verification is paramount and software is patched continuously.

This essay was written with Barath Raghavan, and originally appeared in IEEE Spectrum.

Friday Squid Blogging: How Squid Survived Extinction Events

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/friday-squid-blogging-how-squid-survived-extinction-events.html

Science news:

Scientists have finally cracked a long-standing mystery about squid and cuttlefish evolution by analyzing newly sequenced genomes alongside global datasets. The research reveals that these bizarre, intelligent creatures likely originated deep in the ocean over 100 million years ago, surviving mass extinction events by retreating into oxygen-rich deep-sea refuges. For millions of years, their evolution barely changed—until a dramatic post-extinction boom sparked rapid diversification as they moved into new shallow-water habitats.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Blog moderation policy.

Hiding Bluetooth Trackers in Mail

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/hiding-bluetooth-trackers-in-mail.html

It was used to track a Dutch naval ship:

Dutch journalist Just Vervaart, working for regional media network Omroep Gelderland, followed the directions posted on the Dutch government website and mailed a postcard with a hidden tracker inside. Because of this, they were able to track the ship for about a day, watching it sail from Heraklion, Crete, before it turned towards Cyprus. While it only showed the location of that one vessel, knowing that it was part of a carrier strike group sailing in the Mediterranean could potentially put the entire fleet at risk.

[…]

Navy officials reported that the tracker was discovered within 24 hours of the ship’s arrival, during mail sorting, and was eventually disabled. Because of this incident, the Dutch authorities now ban electronic greeting cards, which, unlike packages, weren’t x-rayed before being brought on the ship.

FBI Extracts Deleted Signal Messages from iPhone Notification Database

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/fbi-extracts-deleted-signal-messages-from-iphone-notification-database.html

404 Media reports (alternate site):

The FBI was able to forensically extract copies of incoming Signal messages from a defendant’s iPhone, even after the app was deleted, because copies of the content were saved in the device’s push notification database….

The news shows how forensic extraction—­when someone has physical access to a device and is able to run specialized software on it—­can yield sensitive data derived from secure messaging apps in unexpected places. Signal already has a setting that blocks message content from displaying in push notifications; the case highlights why such a feature might be important for some users to turn on.

“We learned that specifically on iPhones, if one’s settings in the Signal app allow for message notifications and previews to show up on the lock screen, [then] the iPhone will internally store those notifications/message previews in the internal memory of the device,” a supporter of the defendants who was taking notes during the trial told 404 Media.

A low-tech trick with sshfs

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2690

Sometimes old, low-tech sysadmin tricks do excellent job. 🙂

A friend of mine asked for help. Time had came for his company to grow up, and it had opened several offices across Europe. However, their IT system wasn’t up to that.

Their specialized software currently ran on a local server in their office. Now, every office had a server – but they had to use together a central database. The software could share a database between several instances, but access to it was built directly in the executable and required a local path. The company behind it had offered to add a client-server database model, but the cost was prohibitive.

Luckily, all of it ran over Linux, which has a huge set of tools for everything. I decided on a very simple and dumb solution. Mounted the directory with the database as local on the office servers through sshfs. It uses ssh as a transport agent, so the protection of data through Internet is very good.

sshfs [email protected]:/some/path/to/database /local/mount/path

To avoid the need for ssh login, I generated (as the user that mounts the directory) a key for every remote server:

su db_dir_mount_user
ssh-keygen -t rsa -b 4096

(It asks for some action from you, and finally generates the key in the .ssh subdirectory in the home directory of the user, as two files: id_rsa and id_rsa.pub.)

Then, I authorized these keys at the server with the database. I went to it, and there (as database_user) copied the id_rsa.pub file from the remote server to the server with the database, and added it to the file .ssh/authorized_keys:

su database_user
rsync -avz [email protected]:/home/db_dir_mount_user/.ssh/id_rsa.pub .ssh/local-server-1.id_rsa.pub
cat local-server-1.id_rsa.pub >> authorized_keys

So far, so well. However, when I started sshfs, it refused to work with a message:

fuse: device not found, try 'modprobe fuse' first

Turned out, the local office servers with the software were actually LXC containers. The company had one physical (well, and one backup 🙂 ) server per office, with several LXC containers running different things on it. Both the software container and the mother OS had fuse (which is required by sshfs) installed, but that was not enough.

The problem turned out to be a fuse device missing from the /dev directory. Which was easy to solve:

mknod /dev/fuse c 10 229

After that, everything went without a glitch. The experiments showed that the query times are low enough for production usage.

Yes, if this company continues to grow, rewriting the database communication as a client-server model will be unavoidable. However, this trick gave them some time to grow up more and find the money needed. 🙂

How to clone an AWS CloudHSM cluster across Regions

Post Syndicated from Desiree Brunner original https://aws.amazon.com/blogs/security/how-to-clone-an-aws-cloudhsm-cluster-across-regions-2/

Important: As of January 1, 2025, Client SDK 3 tools (CMU and KMU) are no longer supported. This guide has been updated to use Client SDK 5 commands exclusively. Ensure you’re using the latest Client SDK 5 version (5.17 or later) for the most recent features and security improvements.

You can use AWS CloudHSM to generate, store, import, export, and manage your cryptographic keys. It also permits hash functions to compute message digests and hash-based message authentication codes (HMACs) and supports cryptographically signing data and verifying signatures. To help ensure redundancy of data and simplification of the disaster recovery process, AWS recommends you to clone your CloudHSM cluster into a different AWS Region. By doing this, you can synchronize keys, including non-exportable keys, across Regions. Non-exportable keys can only be synchronized to cloned clusters. Non-exportable keys are keys that can never leave the CloudHSM device in plaintext. They reside on the CloudHSM device and are encrypted for security purposes.

In this post, I show you how to set up one cluster in Region 1 and how to use the CopyBackupToRegion feature to clone the cluster and hardware security modules (HSMs) to a virtual private cloud (VPC) in Region 2.

Note: This post doesn’t include instructions on how to set up a cross-Region VPC to synchronize HSMs across the two cloned clusters. If you need to set up a cross-Region VPC, see Building a Scalable and Secure Multi-VPC AWS Network Infrastructure.

Solution overview

You clone a cluster to another Region in a two-step process:

  1. Copy a backup to the destination Region
  2. Create a new cluster from this backup

To complete this solution, you can use either the AWS Command Line Interface (AWS CLI) or the CloudHSM API. For this post, I show you how to use the AWS CLI to copy the cluster backup from Region 1 to Region 2 and then launch a new cluster from that copied backup.
Figure 1 illustrates the process described in this post.

Figure 1: Architecture diagram

Figure 1: Architecture diagram

Here’s how the process works:

  1. CloudHSM creates a backup of the cluster and stores it in an Amazon Simple Storage Service (Amazon S3) bucket owned by the CloudHSM service.
  2. You use the AWS CLI API command to copy the backup to another Region.
  3. When the backup is completed, you use that backup to then create a new cluster and HSMs.
Note: Backups can’t be copied across partitions like the AWS GovCloud Regions, China Region and AWS European Sovereign Cloud.

As with all cluster backups, when you copy the backup to a new Region, it’s stored in an S3 bucket owned by a CloudHSM account. CloudHSM manages the security and storage of cluster backups for you. This means the backup in both Regions will also have the durability of Amazon S3, which has 99.999999999% durability. The backup in Region 2 will be encrypted and secured in the same way as your backup in Region 1. You can read more about the encryption process of your CloudHSM backups in AWS CloudHSM cluster backups.
Any HSMs created in this cloned cluster will have the same users and keys as the original cluster at the time the backup was taken. From this point on, you must manually keep the cloned clusters in sync. Specifically:

  • If you create users after creating your new cluster from the backup, you must create them on both clusters manually.
  • If you change the password for a user in one cluster, you must change the password on the cloned clusters to match.
  • If you create more keys in one cluster, you must sync them to at least one HSM in the cloned cluster. After you sync the key from cluster 1 to cluster 2, the CloudHSM automated cluster synchronization will take care of syncing the keys in the second cluster.

Prerequisites

Before starting, ensure you have the following in place:

Note: Syncing keys across clusters in more than one Region will only work if all clusters are created from the same backup. This is because synchronization requires the same secret key—called a masking key—to be present on the source and destination HSM. The masking key is specific to each cluster. It can’t be exported, and can’t be used for any purpose other than synchronizing keys across HSMs in a cluster.

Step 1: Create your first cluster in Region 1

The first step in cloning your CloudHSM cluster is to create the initial cluster—which will serve as the foundation for your cross-Region deployment—in your source Region.

Create the cluster

Replace <SUBNET_ID_1> with one of your private subnets. Make a note of the cluster ID to use later:
aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium --subnet-ids <SUBNET_ID_1>

Launch the EC2 client

Launch an Amazon Elastic Compute Cloud (Amazon EC2) instance in your public subnet. See Step 1 of Get started with Amazon EC2 for detailed steps.

Create the first HSM

Replace <CLUSTER_ID> with the ID you recorded earlier and <AVAILABILITY_ZONE> with the Availability Zone matching your private subnet (for example, us-east-1a):
aws cloudhsmv2 create-hsm --cluster-id <CLUSTER_ID> --availability-zone <AVAILABILITY_ZONE>

Initialize the cluster

Before you initialize the cluster, create a self-signed certificate and use it to sign the cluster’s certificate signing request (CSR). Once you have the signed certificate, initialize the cluster:

aws cloudhsmv2 initialize-cluster \
    --cluster-id <CLUSTER_ID> \
    --signed-cert file://<CLUSTER_ID>_CustomerHsmCertificate.crt \
    --trust-anchor file://customerCA.crt

Important: Copy the certificate used to sign your cluster’s CSR to to maintain a secure connection.

After the command completes, the cluster transitions to the Initialized state. Copy the certificate used to sign your cluster’s CSR to /opt/cloudhsm/etc so that the CloudHSM client can verify the cluster’s identity when you configure it in the next step:

sudo cp _CustomerHsmCertificate.crt /opt/cloudhsm/etc/
sudo cp customerCA.crt /opt/cloudhsm/etc/

Install the CloudHSM Client SDK 5

Download and install the latest CloudHSM Client SDK 5 (version 5.17 or later):
For example, for Amazon Linux 2023:

wget https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Amzn2023/cloudhsm-cli-latest.amzn2023.x86_64.rpm
sudo yum install -y ./cloudhsm-cli-latest.amzn2023.x86_64.rpm

Configure the client

Configure the CloudHSM client with your HSM’s elastic network interface (ENI IP) address:
configure-cli -a <HSM_IP>

Activate the cluster

To activate the cluster, run the CloudHSM CLI in interactive mode.

cloudhsm-cli interactive

You can run user list to see the admin user, which is not yet activated.

aws-cloudhsm > user list
{
  "error_code": 0,
  "data": {
    "users": [
      {
        "username": "admin",
        "role": "unactivated-admin",
        "locked": "false",
        "mfa": [],
        "cluster-coverage": "full"
      },
      {
        "username": "app_user",
        "role": "internal(APPLIANCE_USER)",
        "locked": "false",
        "mfa": [],
        "cluster-coverage": "full"
      }
    ]
  }
}

Use the cluster activate command to set the initial admin password.

aws-cloudhsm > cluster activate
Enter password:<NewPassword>
Confirm password:<NewPassword>
{
  "error_code": 0,
  "data": "Cluster activation successful"
}

When completed, sign out using the command quit, then sign back in with the new password, using the command login --username admin --role admin.

After doing this, you can create the first crypto user (CU). You create the user by running the command: user create --username <USERNAME> --role crypto-user. For more information, see HSM user types for CloudHSM CLI. Crypto users are permitted to create and share keys on the CloudHSM.

When completed, sign out using the command quit.

Step 2: Create keys in Region 1

Create a non-exportable AES-256 key:

aws-cloudhsm > key generate-symmetric aes \
    --label aes-example \
    --key-length-bytes 32 \
    --attributes extractable=false

Make note of the key reference returned in the output, because you’ll need it for synchronization later.

Step 3: Trigger a backup of your cluster

To trigger a backup for Region 2:

  1. Add another HSM to your cluster in Region 1 (can be done using the AWS Management Console or AWS CLI)
  2. The backup will contain:
    • All users (crypto officers (COs), crypto users (CUs), and appliance users)
    • All key material on the HSMs
    • All configurations and policies
Note: The user portion is critical because keys can only be synced across clusters to the same user.

Record the backup ID to use later. You can find this in the CloudHSM console under Backups, or using the following command:

aws cloudhsmv2 describe-backups --cluster-id

To avoid unnecessary charges, you can delete the additional HSM after the backup is created.

Step 4: Copy your backup Between Regions

Before you can transfer the backup to your destination Region, you need to configure the appropriate IAM permissions to allow the copy operation.

IAM permissions

Ensure proper permissions are configured for your IAM role or user. You need CloudHSM administrator privileges. Here’s an example permissions policy:

{
   "Version": "2012-10-17",
   "Statement": {
      "Effect": "Allow",
      "Action": [
         "cloudhsm:*",
         "ec2:CreateNetworkInterface",
         "ec2:DescribeNetworkInterfaces",
         "ec2:DescribeNetworkInterfaceAttribute",
         "ec2:DetachNetworkInterface",
         "ec2:DeleteNetworkInterface",
         "ec2:CreateSecurityGroup",
         "ec2:AuthorizeSecurityGroupIngress",
         "ec2:AuthorizeSecurityGroupEgress",
         "ec2:RevokeSecurityGroupEgress",
         "ec2:DescribeSecurityGroups",
         "ec2:DeleteSecurityGroup",
         "ec2:CreateTags",
         "ec2:DescribeVpcs",
         "ec2:DescribeSubnets",
         "iam:CreateServiceLinkedRole"
      ],
      "Resource": "*"
   }
}

Copy the backup

To copy your backup from Region 1 to Region 2, you need:

  • The destination Region
  • The source cluster ID and backup ID (you can use either or both) found in the CloudHSM console

If you specify only the cluster ID, the most recent backup will be chosen. For a specific backup, use the backup ID.

aws cloudhsmv2 copy-backup-to-region \
    --destination-region <DESTINATION_REGION> \
    --backup-id <BACKUP_ID>

Example response:

{
    "DestinationBackup": {
        "SourceBackup": "backup-4kuraxsqetz",
        "SourceCluster": "cluster-kzlczlspnho",
        "CreateTimestamp": 1531742400,
        "SourceRegion": "us-east-1"
    }
}

After copying, you will see a new backup ID in your console. Use this to create your new cluster in Region 2:

aws cloudhsmv2 create-cluster \
    --hsm-type hsm2m.medium \
    --subnet-ids <SUBNET_ID_REGION_2> \
    --source-backup-id <BACKUP_ID_REGION_2> \

Certificate transfer

Copy the cluster certificate from the original cluster to the new Region:

  1. Open two terminal sessions (one for each HSM)
  2. Copy the certificate content from cluster 1
  3. Create and paste into a new file in cluster 2

The certificate is required for encrypted connections between your client and HSM instances.

Security group configuration

Add the cloned cluster’s Security Group to your EC2 client instance:

  1. Select the Security Group for your EC2 client in the EC2 console
  2. Choose “Add rules”
  3. Add a rule allowing traffic from the cluster’s Security Group ID on port 2225

Then retrieve the ENI IP address of the HSM in Region 2 using the following command, and make a note of the output—you will use it in the next step to configure cross-Region connectivity:

aws cloudhsmv2 describe-clusters \
    --filters clusterIds=<cluster_ID_region_2> \
    --region <region_2> \
    --query 'Clusters.Hsms.EniIp' \
    --output text

Step 5: Configure cross-Region connectivity

To enable the CloudHSM CLI to communicate with both clusters simultaneously, add the Region 2 cluster to your existing client configuration using the ENI IP address you retrieved in the previous step:

Step 6: Synchronize keys between clusters

To synchronize keys between your source and destination clusters, you first need to verify which users and keys exist before replicating them.

configure-cli add-cluster \
    --cluster-id <cluster_ID_region_2> \
    --endpoint <hsm_eni_ip_region_2> \
    --region <region_2>

The CloudHSM CLI will now communicate with both clusters simultaneously using the certificates already configured during the initial setup, enabling key synchronization using the masking key shared between cloned clusters.

List users and keys

First, verify users and list available keys:
# List all users
cloudhsm-cli user list

# List keys for specific user
cloudhsm-cli key list --username

Replicate keys

To replicate a key from Region 1 to Region 2:

cloudhsm-cli key replicate \
    --filter key-reference=<key_ref> \
    --source-cluster-id <source_cluster_ID> \
    --destination-cluster-id <destination_cluster_ID>

Verify the key replication by listing keys again:

cloudhsm-cli key list --username <username>

The output should show identical key references on both clusters. Repeat this process for any additional keys that you want to synchronize.

Points to remember

After cloning a cluster to a backup cluster, remember these important points:

  • Always manually update users across clusters after the initial backup
  • Use key replication for any keys created after the initial backup
  • Keep your Client SDK 5 tools updated for the latest features and security improvements
  • The January 1, 2025, end-of-support date for Client SDK 3 tools (CMU and KMU) means you should migrate to Client SDK 5 as soon as possible

Client SDK 5 supports ARM64 architecture on the following Linux distributions:

  • Amazon Linux 2023
  • Amazon Linux 2
  • Red Hat Enterprise Linux (RHEL) 8 (8.3+)
  • Red Hat Enterprise Linux (RHEL) 9 (9.2+)
  • Red Hat Enterprise Linux (RHEL) 10 (10.0+)
  • Ubuntu 22.04 LTS
  • Ubuntu 24.04 LTS
  • Debian 12
  • USE Linux Enterprise Server 15

Conclusion

You now have a fault-tolerant AWS CloudHSM environment with synchronized keys across Regions using the latest tools and best practices. By implementing this cross-Region cluster configuration, you gain improved disaster recovery capabilities, reduced risk of data loss, and enhanced business continuity for your cryptographic operations. This approach helps ensure that your critical cryptographic keys remain available even in the event of a Regional outage, providing the resilience that enterprise workloads demand.

If you have feedback about this post, submit comments in the Comments section below. For questions about this post, start a new thread on the AWS re:Post.

Desiree Brunner

Desiree Brunner

Desiree is a Security Specialist Solutions Architect working with regulated customers as part of the AWS EMEA Security & Compliance team. She builds on her background in DevOps and platform engineering to support her customers in designing secure, compliant cloud environments. Passionate about mental health and knowledge sharing, she regularly speaks at AWS events and supports teams on their cloud security journey.

Rickard Löfström

Rickard Löfström

Rickard guides enterprises in building secure cloud environments as a Specialist Solutions Architect in the AWS EMEA Security & Compliance team. He advises customers on implementing AWS security services, focusing on identity management, data protection, and infrastructure security controls. He enjoys translating complex security requirements into technical solutions that enable organizations to meet their security objectives while maintaining operational efficiency.

Is “Satoshi Nakamoto” Really Adam Back?

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/is-satoshi-nakamoto-really-adam-back.html

The New York Times has a long article where the author lays out an impressive array of circumstantial evidence that the inventor of Bitcoin is the cypherpunk Adam Back.

I don’t know. The article is convincing, but it’s written to be convincing.

I can’t remember if I ever met Adam. I was a member of the Cypherpunks mailing list for a while, but I was never really an active participant. I spent more time on the Usenet newsgroup sci.crypt. I knew a bunch of the Cypherpunks, though, from various conferences around the world at the time. I really have no opinion about who Satoshi Nakamoto really is.

Mythos and Cybersecurity

Post Syndicated from B. Schneier original https://www.schneier.com/blog/archives/2026/04/mythos-and-cybersecurity.html

Last week, Anthropic pulled back the curtain on Claude Mythos Preview, an AI model so capable at finding and exploiting software vulnerabilities that the company decided it was too dangerous to release to the public. Instead, access has been restricted to roughly 50 organizations—Microsoft, Apple, Amazon Web Services, CrowdStrike and other vendors of critical infrastructure—under an initiative called Project Glasswing.

The announcement was accompanied by a barrage of hair-raising anecdotes: thousands of vulnerabilities uncovered across every major operating system and browser, including a 27-year-old bug in OpenBSD, a 16-year-old flaw in FFmpeg. Mythos was able to weaponize a set of vulnerabilities it found in the Firefox browser into 181 usable attacks; Anthropic’s previous flagship model could only achieve two.

This is, in many respects, exactly the kind of responsible disclosure that security researchers have long urged. And yet the public has been given remarkably little with which to evaluate Anthropic’s decision. We have been shown a highlight reel of spectacular successes. However, we can’t tell if we have a blockbuster until they let us see the whole movie.

For example, we don’t know how many times Mythos mistakenly flagged code as vulnerable. Anthropic said security contractors agreed with the AI’s severity rating 198 times, with an 89 per cent severity agreement. That’s impressive, but incomplete. Independent researchers examining similar models have found that AI that detects nearly every real bug also hallucinates plausible-sounding vulnerabilities in patched, correct code.

This matters. A model that autonomously finds and exploits hundreds of vulnerabilities with inhuman precision is a game changer, but a model that generates thousands of false alarms and non-working attacks still needs skilled and knowledgeable humans. Without knowing the rate of false alarms in Mythos’s unfiltered output, we cannot tell whether the examples showcased are representative.

There is a second, subtler problem. Large language models, including Mythos, perform best on inputs that resemble what they were trained on: widely used open-source projects, major browsers, the Linux kernel and popular web frameworks. Concentrating early access among the largest vendors of precisely this software is sensible; it lets them patch first, before adversaries catch up.

But the inverse is also true. Software outside the training distribution—industrial control systems, medical device firmware, bespoke financial infrastructure, regional banking software, older embedded systems—is exactly where out-of-the-box Mythos is likely least able to find or exploit bugs.

However, a sufficiently motivated attacker with domain expertise in one of these fields could nevertheless wield Mythos’s advanced reasoning capabilities as a force multiplier, probing systems that Anthropic’s own engineers lack the specialized knowledge to audit. The danger is not that Mythos fails in those domains; it is that Mythos may succeed for whoever brings the expertise.

Broader, structured access for academic researchers and domain specialists—cardiologists’ partners in medical device security, control-systems engineers, researchers in less prominent languages and ecosystems—would meaningfully reduce this asymmetry. Fifty companies, however well chosen, cannot substitute for the distributed expertise of the entire research community.

None of this is an indictment of Anthropic. By all appearances the company is trying to act responsibly, and its decision to hold the model back is evidence of seriousness.

But Anthropic is a private company and, in some ways, still a start-up. Yet it is making unilateral decisions about which pieces of our critical global infrastructure get defended first, and which must wait their turn.

It has finite staff, finite budget and finite expertise. It will miss things, and when the thing missed is in the software running a hospital or a power grid, the cost will be borne by people who never had a say.

The security problem is far greater than one company and one model. There’s no reason to believe that Mythos Preview is unique. (Not to be outdone, OpenAI announced that its new GPT-5.3-Codex is so dangerous that the model also will not be released to the general public.) And it’s unclear how much of an advance these new models represent. The security company Aisle was able to replicate many of Anthropic’s published anecdotes using smaller, cheaper, public AI models.

Any decisions we make about whether and how to release these powerful models are more than one company’s responsibility. Ultimately, this will probably lead to regulation. That will be hard to get right and requires a long process of consultation and feedback.

In the short term, we need something simpler: greater transparency and information sharing with the broader community. This doesn’t necessarily mean making powerful models like Claude Mythos widely available. Rather, it means sharing as much data and information as possible, so that we can collectively make informed decisions.

We need globally co-ordinated frameworks for independent auditing, mandatory disclosure of aggregate performance metrics and funded access for academic and civil-society researchers.

This has implications for national security, personal safety and corporate competitiveness. Any technology that can find thousands of exploitable flaws in the systems we all depend on should not be governed solely by the internal judgment of its creators, however well intentioned.

Until that changes, each Mythos-class release will put the world at the edge of another precipice, without any visibility into whether there is a landing out of view just below, or whether this time the drop will be fatal. That is not a choice a for-profit corporation should be allowed to make in a democratic society. Nor should such a company be able to restrict the ability of society to make choices about its own security.

This essay was written with David Lie, and originally appeared in The Globe and Mail.

Human Trust of AI Agents

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/human-trust-of-ai-agents.html

Interesting research: “Humans expect rationality and cooperation from LLM opponents in strategic games.”

Abstract: As Large Language Models (LLMs) integrate into our social and economic interactions, we need to deepen our understanding of how humans respond to LLMs opponents in strategic settings. We present the results of the first controlled monetarily-incentivised laboratory experiment looking at differences in human behaviour in a multi-player p-beauty contest against other humans and LLMs. We use a within-subject design in order to compare behaviour at the individual level. We show that, in this environment, human subjects choose significantly lower numbers when playing against LLMs than humans, which is mainly driven by the increased prevalence of ‘zero’ Nash-equilibrium choices. This shift is mainly driven by subjects with high strategic reasoning ability. Subjects who play the zero Nash-equilibrium choice motivate their strategy by appealing to perceived LLM’s reasoning ability and, unexpectedly, propensity towards cooperation. Our findings provide foundational insights into the multi-player human-LLM interaction in simultaneous choice games, uncover heterogeneities in both subjects’ behaviour and beliefs about LLM’s play when playing against them, and suggest important implications for mechanism design in mixed human-LLM systems.