Would this patent cover just the encoding alone? The first sentence says:
> A method, apparatus, and system relating to embedding hidden content within a Unicode message and using the hidden content to perform a particular computer action.
So, in my extremely unqualified opinion, just the encoding technique alone is not covered by the patent, only when combined with some action performed based on the encoding?
> But it strangely leaves open the possibility, without saying either way, that a longer iv, with r(i)>96 random bits might allow generating more iv's. As you point out, it will depend on the properties of GHASH (and potentially on how the result is used downstream from there).
Well, the nonce is (usually) public information. It is shared along with the ciphertext, so that the other party can use the same nonce to validate and decrypt the ciphertext.
So it is trivial to detect which two messages share a nonce, if any do.
Correct. However, some implementations actually incorrectly refer to the nonce as an "IV" (initialization vector), where it's not so obvious.
Also, it's not entirely clear just how bad a reuse actually is. For example, in AES-CBC, reusing the IV has much less impact than reusing the nonce with AES-GCM.
Yes, I am, but unfortunately I do not think I can provide any answers here. A quick internet search reveals some CVEs for nonce reuse.
If I had to, based on absolutely nothing but a gut feeling, guess, I'd think this may appear more frequently in IoT devices, where AES-GCM is attractive because of its speed, but randomness is sometimes in low supply?
I'm honestly surprised at the relatively positive reception to this. While there isn't any problem with the code shown, the same effect couldn've probably been achieved with a few well thought out shortcuts in any IDE (delete outerHTML of svg tag, add new tag, add attributes). The only "more complex" output that is shown is the specification that CW produces, which literally contains an error in the first line ("Sp<logo>ral").
Moving on to the complex task, the author simply hand-waves "this isn't good yet but surely it will be". No evidence is given as to _why_ there should be any expectation of LLMs getting there.
And the perceived benefit of discovering that their idea of the more complex task was not thought out enough did not come from the LLM, it came from the author itself. They may as well have spoken to ELIZA or a rubber duck.
This article does not mention the release of the SteamDeck at all. I wonder if this could have had an impackt on Linux usage large enough to see in trends like these or if it's just a drop in the bucket.
This is my first ever blog post. It's about Bootstring, the encoding algorithm behind Punycode domain names. I wanted to cover both encoding and decoding in a single post, but I spent so much time on this already I decided to publish the decoding part as a Part 1, covering the encoding in a second part.
I spent a lot of time building small demos / widgets so you can see the algorithm in action.
As I said, it's my first ever blog post, so if you read it, please let me know what you think and what I can improve!
> January 10, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1097.
> January 12, 2025 – Kubernetes proposed a fix for CVE-2025-1974.
> January 16, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1974.
> January 20, 2025 – Kubernetes proposed a fix for CVE-2025-24513.
> January 21, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-24513.
Lol, lmao even. [1]
[1]: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...