Deleted Comment
[0]: https://taoism.net/wp-content/plugins/wonderplugin-pdf-embed...
> The first improvement we're excited to announce is that the $5 Hobby plan is no more. We're replacing it with a very simple Pay As You Go plan. On this plan there's no more upfront $5 charge and no minimum monthly commitment. You only pay for what you use. If you don't use anything for a given month you pay $0. You still need a credit card on file to prevent abuse. But your card is only charged if you use the service.
[0]: https://community.fly.io/t/fresh-produce-pay-as-you-go-plan/...
In AES-CBC terms, the algorithm can be described as:
1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
2. If MSB₁(L) = 0, then K1 = L << 1;
Else K1 = (L << 1) ⊕ 0¹²⁰10000111
3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
6. Nₓ = N[12:]
Where AES-CBC-256 returns the first 128-bit block of the ciphertext, discarding the padded block. (Thus, if you can't turn off padding, it costs three additional AES calls with the same key compared to a lower level implementation — not bad). After deriving a key, use it with the standard AES-GCM.Here's my JS implementation based on WebCrypto API, which uses this fact: https://github.com/dchest/xaes
It accepts a proper CryptoKey intended for AES-CBC, supporting all CryptoKey features, e.g. storing it in IndexedDB with "extractable" bit set to false.
Great job, Filippo!
for those of you(like me) wondering where this apparently spooky constant is coming from, it is a bitstring of the coefficients of the lexically first irreducible polynomial of degree b with the minimum possible number of non-zero terms, where b is the block size(in bits) of the underlying block cipher with which CMAC is instantiated. So, nothing up the sleeve here.
You are right that security works in the context of a threat model. There are however useless tools that give a false sense of "security" that do not fit in any reasonable model.
I have cases where I block whole ranges of IPs for "legal" reasons - it does not make sense but there you are, the ones who write the rules are not the ones who actually know the stuff.
Too late for what? Again, it only makes sense to talk about "security" in the context of a threat model. You can debate the reasonableness of that threat model, but that's another discussion.
My threat model(for the sake of argument :^)) is an attacker with a static public IP address trying to bruteforce access to my service via repeated login attempts.
I'll maintain(for now) that fail2ban can be an effective tool that does provide some security against an attacker of this kind.
Also, if you're using xsalsa20 anyway, why go through the trouble of doing incremental n0nces? One of the main benefits of opting for an extended-n0nce construction is that it simplifies n0nce handling greatly. Why not randomly generate the 24 byte n0nce and forget about the tricky and error prone project of ensuring n0nce uniqueness?