Making my best effort to locally decrease entropy.
#StandWithUkraine 🇺🇦
| GitHub | https://github.com/rkiyanchuk |
| Подкаст «Шо по коду?» | https://youtube.com/@shopokodu |
| GitHub | https://github.com/rkiyanchuk |
| Подкаст «Шо по коду?» | https://youtube.com/@shopokodu |
What do you have in your #ClaudeCode statusline?
https://github.com/rkiyanchuk/dotfiles/blob/main/claude/.claude/statusline.sh
RE: https://infosec.exchange/@bezpieka/116515775007134434
I have a theory…
Hybrid key exchange (DH+ML-KEM) in TLS 1.3 has been approved today.
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.
The work presented by @arunninghacker at #CyCon should be an overdue wake-up call to Western tech companies:
russian military apps are actively leveraging Western cloud infrastructure, open-source maps, and Android's sideloading model to support battlefield operations against #ukraine
Without proactive countermeasures, the tech giants of the free world become passive accomplices of the aggressor.
Here's what companies can do to stop enabling aggressor's warfare by negligence:
⦿ Monitor cloud usage for signs of military activity
⦿ Enforce geofencing & API restrictions on russian actors
⦿ Scrutinize app ecosystem and flag military-grade tools
⦿ Rethink tech neutrality in times of war
Complicity through inaction is not neutral.
Research at Stanford developed Cybench: A Framework for Evaluating Cybersecurity Capabilities and Risks of Language Models.
https://crfm.stanford.edu/2024/08/19/cybench.html
The work has also been presented at this year's Stanford Computer Forum: https://forum.stanford.edu/events/2025-annual-affiliates-meeting/day-1-security-workshop
This Okta vulnerability is a great demonstration that engineers should stop using cryptographic primitives as magic boxes and start looking into actual properties and parameters of the algorithm they use: https://www.theverge.com/2024/11/1/24285874/okta-52-character-login-password-authentication-bypass
Bcrypt Wikipedia article mentions the input limit of 72 bytes. Which, of course, is not a great design by modern standards, but the reason Okta turned this limitation into a vulnerability is due to misuse of a password-based key derivation function.
The name suggests that you should only feed the password to the function. Instead, Okta passed concatenation of userId + username + password.
And to make things worse, the fix that Okta chose is a step in the wrong direction: instead of fixing inputs they moved from bcrypt to PBKDF2. Which provides weaker protection of low-entropy password source than more modern functions like Argon2 (and even bcrypt itself).
It's rather disappointing to see such incompetence from a security vendor. Out of all the companies, Okta should know how to avoid mistakes when hashing passwords.
Know your cryptography. Or hire professionals.

Signal’s mission and sole focus is private communication. For years, Signal has kept your messages private, your profile information (like your name and profile photo) private, your contacts private, and your groups private – among much else. Now we’re taking that one step further, by making your...
Engineers should be concerned about "AI", but not for the reason most think.
Machine learning and LLMs got to the point where they can either accurately describe a well-known concept, or make up complete, utter nonsense on topics that are not as widely covered on the Internet.
As the result, AI assistants act as a productivity boost for knowledgeable enough engineers who are already beyond the Danning-Kruger barrier and just need faster access to certain technical details.
But at the same time, they may completely derail and confuse novice engineers who cannot yet spot cases where LLMs hallucinate.
Consequently, LLMs provoke gap increase between top talent and novice engineers. Use it with caution.