BitLocker keys given to FBI highlight the danger of centralized cloud storage. Encryption without proper key management is security theater. Users must prioritize user-controlled key storage and transparency. #Cybersecurity #DataPrivacy #KeyManagement

https://saysomething.hashnode.dev/microsofts-bitlocker-keys-the-fbi-a-developers-guide-to-secure-key-management

Microsoft has confirmed it may provide BitLocker recovery keys in response to valid legal orders when users choose cloud-based key storage.

The case underscores the importance of encryption architecture decisions, key management models, and informed user choice — especially as other vendors adopt zero-access designs.

How do you evaluate provider-held key risks in enterprise or personal environments?

Source: https://www.forbes.com/sites/thomasbrewster/2026/01/22/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/

Share insights and follow @technadu for objective InfoSec coverage.

#InfoSec #Encryption #KeyManagement #Microsoft #BitLocker #DataProtection #CyberRisk

Does anyone have good resources on [personal] key management? That is latest blog posts or books on the topic?

This is things like secure management and backup (SSS?), off-line/dedicated devices, managing many keys due to rotation, etc.

e.g. If you encrypt old/past keys, even with a secure key, and that key leaks, you need to know where all the encrypted data is to destroy/rewrite it with a new key, so you can't just keep tons of backups.

#Security #Cryptography #KeyManagement

Часть 5
Размышления о TLS в сетях Yggdrasil и Mycelium
#Thoughts #TLS #Yggdrasil #Mycelium #OverlayNetworks
В среде оверлейных сетей почему-то считается само собой разумеющимся, что если ключи узлов постоянны, а соединения между ними защищены с помощью TLS, то дополнительный уровень SSL якобы не нужен. Однако в последнее время я начал в этом сомневаться.
Компрометация ключей
#KeyManagement #CryptoRisks #PKI
В сетях вроде Yggdrasil и Mycelium отсутствует высокая сложность генерации приватных ключей, поэтому теоретически (пусть и с крайне малой вероятностью) возможна коллизия. Именно по этой причине рекомендуется использовать основные адреса, а не подсети — последние разработчики планируют, но пока не удалили. При этом подсети удобны в условиях шаред-хостинга.
В любом случае это не исключает возможности случайного извлечения копии ключа — или вовсе не случайного, если учитывать потенциальные возможности современной криптоиндустрии. Вопрос лишь в целесообразности применения суперкомпьютеров для таких целей: сколько пользователей будут включать эти сети, каким капиталом они будут обладать и насколько оправданны атаки на маршрутизацию, основанную на фиксированном алгоритме построения дерева из peer ID.
Комментарий: Речь идёт не о практической уязвимости Yggdrasil, а о модели угроз. Детерминированная маршрутизация на основе публичных ключей описана в документации проекта: https://yggdrasil-network.github.io/architecture.html
Двойной слой
#DoubleEncryption #TLS #Performance
Технически транспортный протокол Yggdrasil берёт на себя роль шифрования трафика даже в тех случаях, когда это не требуется. Например:
— экономия электроэнергии и CPU при передаче крупных медиафайлов
— ситуации, когда SSL / HTTPS уже используется на уровне приложения, чтобы избежать перехвата логинов/паролей или конфиденциальных GET-запросов при работе через прокси
Практический пример — требование обязательного шифрования трафика в протоколе Gemini внутри Yggdrasil. Gemini проектировался как защищённый протокол для Интернета, однако я использую его не совсем в том контексте, который закладывал автор. Поэтому некоторое время я применял альтернативу — Nex, но позже пришёл к выводу, что часть данных всё же потенциально требует сертификата. В результате мне понадобилась старая добрая модель HTTP + HTTPS для чувствительных форм.
Если с клиента на сервер передаются конфиденциальные данные, то, на мой взгляд, использование SSL-сертификата оправдано как дополнительный предохранитель. Однако маршрутизатор уже «позаботился» обо всём заранее, тем самым создавая лишние проблемы.
Комментарий: Gemini использует TLS обязательно, в отличие от HTTP, где шифрование опционально. Спецификация: https://gemini.circumlunar.space/docs/specification.html
Сертификация в локальных сетях
#Certificates #LocalNetworks #TOFU
Из-за изолированности локальных сетей в Yggdrasil проблематично настроить валидный сертификат, например от Let’s Encrypt. Зато в случае протокола Gemini центры сертификации вообще не используются. Вместо этого применяется принцип TOFU — Trust On First Use, который со временем существенно снижает риск перехвата данных — до момента обнаружения утечки.
У меня даже возникали мысли об организации внутреннего центра сертификации внутри сети. А почему бы и нет? Почему бы даже не сделать такой сервис платным?
Комментарий: TOFU широко используется в SSH. Первый контакт считается доверенным, а любые изменения ключа в дальнейшем считаются подозрительными.
Выводы
#SecurityTheater #NetworkDesign #Overengineering
Когда и каким образом шифровать данные — должен решать пользователь или администратор сети, исходя из конкретных потоков и типов данных. Yggdrasil и Mycelium же делают это «добровольно-принудительно», как, впрочем, и прочее новомодное ПО с ярлыком «абсолютно защищено». Современное ПО, разработчики которого соревнуются за право называться «безопасным», напоминает криптокапусту с коэффициентом защиты «было → стало».
Начинает раздражать, когда за меня принимают решения там, где их никто не просил. Маркетинг — это маркетинг, лозунги — это лозунги, но опытные пользователи из-за такого дискомфорта уходят, а туристы всё равно не задерживаются.
И ещё один вывод: эффективные сетевые решения были придуманы послевоенными специалистами полвека назад, которым нужно было выживать, а не играть в коммерческие эксперименты. С тех пор ничего принципиально нового не изобретено. Возможно, следующий прорыв будет связан с квантовой передачей данных, а не с подобной ерундой — прокладкой автоматических маршрутов через потенциально скомпрометированные узлы с одновременным шифрованием тонн бесполезного мусора, проходящего через них.

Matrix messaging security is so tight that I can't even decrypt my own messages after signing into other Matrix clients. Let me know if I'm wrong.

#Matrix #EndToEndEncryption #SecureMessaging #PrivacyTech #DecentralisedWeb #ElementClient #EncryptionIssues #DigitalSecurity #TechChallenges #OpenSource #CrossDeviceSync #Cybersecurity #MessagingApps #MatrixProtocol #KeyManagement

There is something darkly funny about one of the world's leading cryptography communities having to cancel its own leadership election because a decryption key walked off into the void. Oops. 😬 A failure of governance, key management, and the very human tendency to treat operational tasks as afterthoughts in systems that look elegant on paper.

The voting system was solid: Helios, with verifiable, privacy-preserving ballots and a split key held by three trustees so that no two people could quietly rewrite the result. Then, everyday life intervened. One slice of key material is "irretrievably lost," and suddenly the only honest option is to throw out the entire election and start over. That's what happens when resilience to human error isn't a part of the threat model.

The real lesson for CIOs and security leaders is simple: if your system assumes perfect humans, it is already broken. Cryptography gives you strong guarantees right up until someone misplaces a token, fails to back up a shard, or stores a key in the wrong place. Good design assumes keys will be lost, people will be unavailable, and someone will eventually click the wrong button on a bad day.

This is why key management, recovery procedures, and threshold designs matter more than the logo on your algorithm. Always, always build for messy, imperfect human behavior: clear key ownership, documented handover, tested recovery drills, and quorum-based access that can tolerate one person making a mistake without taking the whole system down. The irony is that the more advanced your cryptography becomes, the more mundane your operational discipline needs to be.

TL;DR
🧠 Strong crypto fails fast when key management is weak
⚡ One lost key can nullify an entire election
🎓 Design systems that expect human error, not perfect behavior
🔍 Treat key governance and recovery as core security, not boring paperwork

https://arstechnica.com/security/2025/11/cryptography-group-cancels-election-results-after-official-loses-secret-key/

#CyberSecurity #Cryptography #KeyManagement #CIO #security #privacy #cloud #infosec

Oops. Cryptographers cancel election results after losing decryption key.

Voting system required three keys. One of them has been "irretrievably lost."

Ars Technica

That said, I am glad that IACR is addressing this "human mistake" by making a "system design change" to a 2-of-3 quorum for the re-run.

https://www.iacr.org/news/item/27138

#IACR #Cryptography #KeyManagement #InfoSec #OPSEC #Elections

IACR News item: 21 November 2025

Diving into the rabbithole of multi/hybrid cloud environments with regard to encryption, key-management, certificates, IAM etcetera. Big fun 😀
Always looking for recent and relevant literature on this subject.
#cloud #iam #encryption #certificates #cybersecurity #keymanagement

🔐 Tired of SSH keys that never expire?

New blog post: SSH Authentication Key Rotation: Why and How to Expire SSH Keys

• How to use AuthorizedKeysCommand
• Custom JSON-based expiry config
• Lightweight alternative to SSH CAs

Read it here:
➡️ https://richard-sebos.github.io/sebostechnology/posts/SSH-Auth-Key-Rotation/

#SSH #Linux #Security #OpenSSH #DevOps #KeyManagement

SSH Authentication Key Rotation: Why and How to Expire SSH Keys

Introduction

Sebos Technology