Hot take:
Discord is not a documentation platform. It is a chat platform. If your project requires connecting to a discord to obtain necessary information, then your project is undocumented.
| Title | Sr. Security Engineer |
| Pronouns | he, him |
| Blog | https://scottarc.blog |
Hot take:
Discord is not a documentation platform. It is a chat platform. If your project requires connecting to a discord to obtain necessary information, then your project is undocumented.
# sodium_compat security release
* https://github.com/paragonie/sodium_compat/releases/tag/v2.5.0
* https://github.com/paragonie/sodium_compat/releases/tag/v1.24.0
Further information: https://00f.net/2025/12/30/libsodium-vulnerability/
@DefuseSec In case you wanted to refresh cryptofails.com sometime
Singh et. al. recently uploaded a preprint describing a new hash function inspired by the Collatz Conjecture. After performing some cursory tests, the proposed function appears to be completely unsuitable for cryptographic purposes, and should not be used.
This is still relevant, IMHO
$5B in revenue, millions of mobile players, one question: are the dice rolls fair?
When Monopoly GO! players questioned their dice roll outcomes, the game's developers hired us to conduct an independent cryptographic design assessment of their PRNG architecture.
Our cryptographic design assessment evaluated two core concerns:
✅ If the random number generator produces unbiased outcomes for all players
✅ Do the countermeasures effectively prevent malicious actors from predicting or manipulating results through client-side attacks
Read the case study: https://trailofbits.info/monopolygo-casestudy
Urgent release by the PQ League of Evil:
Private key formats for ML-KEM and ML-DSA have been hotly debated recently. We at the league have discovered a missing perspective in the discussion: while the expanded private key format contains most information, it misses the matrix itself, which should be possible to store as well. Therefore, we suggest the following solution:
ASN.1 CHOICE of:
Seed
Expanded private key
Extra expanded private key
Both
More both
Extra both
All
We already have modules in the validation pipeline that only support extra expanded private keys, and it would be unfair to us early adopters to not standardize like this!
Of course, we are aware of the concerns that keys might contain redundant data. To address this, implementers SHOULD randomly flip bits in some of the keys before loading.