Tweakable enciphering modes (TEMs) provide security in various storage and space-critical applications, including disk and file-based encryption and packet-based communication protocols. XCB-AES (originally introduced as XCBv2) is specified in the IEEE 1619.2 standard for encryption of sector-oriented storage media and comes with a formal security proof for block-aligned messages. In this work, we present the first plaintext recovery attack on XCB-AES $-$ the shared difference attack, demonstrating that the security of XCB-AES is fundamentally flawed. Our plaintext recovery attack is highly efficient and requires only two queries (one enciphering and one deciphering), breaking the claimed $\mathsf{vil\text{-}stprp}$, $\mathsf{stprp}$ as well as the basic $\mathsf{sprp}$ security. Our shared difference attack exploits an inherent property of polynomial hash functions called separability. We pinpoint the exact flaw in the security proof of XCB-AES, which arises from the separability of polynomial hash functions. We show that this vulnerability in the XCB design strategy has gone unnoticed for over 20 years and has been inadvertently replicated in many XCB-style TEM designs, including the IEEE 1619.2 standard XCB-AES. We also apply the shared difference attack to other TEMs based on XCB $-$ XCBv1, HCI, and MXCB, invalidating all of their security claims, and discuss some immediate countermeasures. Our findings are the first to highlight the need to reassess the present IEEE 1619.2 standard as well as the security and potential deployments of XCB-style TEMs.
#xcb #development thoughts:
One of the features I'd like to add to #Xmoji is a "system #tray icon". I know these aren't "en vogue" any more, but I like the concept a lot for an application you'll typically leave running and only use from time to time, which is likely a usage pattern for an "#emoji #keyboard".
So, I found a spec based on #XEMBED, X selections and client messages (therefore, pure X inter-client communication), I think I can implement that! 👍
https://specifications.freedesktop.org/systemtray-spec/0.2/
Digging deeper, I found there's a successor called #SNI and the spec above is considered "legacy" (after only 20 years, hehe) 🤨. SNI is based on #dbus. Oh damn ... it's not that I particularly hate dbus, it probably makes a lot of sense for complex desktop environments, but I really want to keep #Xmoji "plain #X11". I'll just use the old spec. At least I found #KDE seems to have a compatibility service: xembed-sni-proxy. No idea about Gnome. But then, screw it.
1 Overview # The system tray is an application running on a given X screen that can display small icons provided by running applications. Windows XP calls this feature the notification area. [1] Inspired by KDE, this specification uses the term system tray. From a UI standpoint, the system tray is n…
Finally removed the nasty "glitches" setting from #Xmoji!
After lots of (unsuccessful) research whether I can somehow check which modules(!) are loaded on the X server (to find out whether #GLAMOR is used, which I *think* causes a bug in compositing glyphs with #XRender) ... I finally remembered an old strategy which is both horribly ugly and pretty reliable: probing!
I now do a dummy glyph compositing to a single-pixel off-screen pixmap during startup and fetch the resulting pixmap from the server, so I can simply *see* whether the result is buggy. 🙈
https://github.com/Zirias/xmoji/commit/93143775e6ad9b01f7f23b2da48c5e6921669fd0
I actually wonder why I didn't have that idea much earlier. E.g. coding on the #C64, probing the hardware (e.g. to identify VIC and SID model by their behavior) is a pretty common thing to do 🥸
Rastislav ₡ore
Lucho
CosicBe
a66ey 🇪🇺🏳️🌈 she/her
zirias (on snac)
Felix Palmen 
