Microblog

random thought: Both UNIX and Plan 9 heavily utilize ambient namespace authority. Sure, in Plan 9 you have per-process namespaces and that’s good and all, but (1) you can still use #hash devices to mount random things, but (2) more importantly, the namespace is still ambient, it’s not that things a process needs are explicitly passed to it on startup. If, say, we consider a scheme where every program’s dependencies are passed to it as file descriptors on startup, we still get trivial pluggability of things like /dev/draw (it could be a pipe or such) and /net (well, can’t do it on UNIX properly, but you could imagine how it could be via file descriptor passing on Plan 9). Now, revocations are an issue, but w/e. One of the annoying part is that access control and unforgeable capabilities is still scoped to processes, which may often times be an awkward abstraction, but things like CHERI really improve on this, and makes the boundary of capability passing much more fine grained. well, actually, i could do something on unix that involves “pass a unix domain socket that speaks 9p” (and capsicum of course). well, i’d need to experiment with how this goes for real programs and workflows. i think the problem with a lot of capability systems is that sometimes you can’t always anticipate what capabilities you need and the direction they flow in; in some cases, having something that feels like “xdg-desktop-portal but capability based: establish a unix domain socket or such to it, ask it for something, it prompts the user, if ok, it SCM_RIGHTS a handle to the caller” would be nice.

You can’t just slap synthetic IVs on top of a pure stream cipher like that.

For multicast scenarios like encrypted group chats, abuse reporting systems, and PAKE, beware of the Invisible Salamanders attack. Note that key malleability is not the same as key malleability; an AEAD constructed with BLAKE3 as an XOF would still be ciphertext-malleable.

KEMs break XX and NX because the responder cannot send their static key and authenticate with it in the same message because unlike DH-based constructions, KEMs are not commutative. Therefore any handshake that transmit static keys must add an additional message.

A library’s core abstractions determine the long-term shape of the entire codebase.

I think sudo-rs enabling pwfeedback (show asterisks) by default was a bad idea. Haven’t we learned from OpenSSH and keystroke timings? pwfeedback doesn’t just leak password length visually; I’d agree that leaking the length of your password is very insignificant if your password is strong enough anyway. But especially when we use long passphrases instead of passwords, we type in a particular pattern. OpenSSH and such have keystroke timing obfuscation so the packets from your client to the server, but if your server emits a * every character you type, the timing side-channel gets re-introduced.