jonmon6691

A bit ironic that this framework's authorship is completely missing.

I agree, there's way too much going on in the firmware, just make a dumb Lora-bluetooth bridge. Hell, just integrate a Lora radio in a phone.

I hope TRMNL will start supporting 6 color e-paper displays more widely. I have one of these 6 color panels running with my own custom firmware on their BYOD license and I'm really happy with it, just wish it could take advantage of the color capabilities.

Watching other people interact with a chat bot is a shockingly intimate look into their personality.

Putting these people into chains was, as the linked article puts it: "Imperial Tyranny", and a completely unnecessary humiliation of the workers. Regardless of their visa status.

Correct, KEM's should be replaced ASAP since they are currently vulnerable to store-now-decrypt-later attacks. Digital signature algorithms are less urgent but considering how long it takes to roll out new cryptography standards, they should be preferred for any new designs. That said, the new PQC signatures are much larger than the current 32 byte ed25519 signatures that are most common, and that could end up being very difficult to integrate into embedded systems with low bandwidth or limited memory, ie. CAN bus secure diagnostics, meshtastic nodes etc.

Thanks I forgot about that. So if understand it right, the idea is to provide some insurance in the case that these relatively young algorithms are broken as they get exposed to more and more cryptanalysis

But I don't think the conversation here is about anonymity, its about side channels to discover the actual content of the SSH session. The OP is looking at determining the command typed based on keystroke timing. The attacks you link would work for any traffic that could be intercepted, SSH or otherwise, and they wouldn't give any info about the content of the stream.

If we're just focused on removing all traces of keystroke timing from the channel, then I think a decoupled SSH transport layer which is providing say 1kB of zero-pad every 20ms to the the shell to fill up, along with a FIFO to spread that out, and maybe some logic to ramp up and down the channel bandwidth based on queue length, you would go a long way to mitigating this specific attack.

I'm assuming when they say that this improves user experience, that it implies the use case is primarily TLS. In which case store-now-decrypt-later attacks are already considered an urgent threat with regard to post quantum crypto. With FIPS 203 being released and Chrome is already using an implementation based on the draft standard, this seems like this algo (at least for TLS) should be on its way out.

Most people would consider streaming music to be a negligible amount of bandwidth. Seems to me like SSH in a "high security mode" could just send X Kbps of bi-directional pad at a layer directly above encryption but below application. Then just use that channel for all the normal SSH traffic. You could either treat this as a bandwidth limited channel or do some slow time-constant ramping up and down at the risk of leaking information about file downloads or large command outputs.

BMW had a wonderful mashup of these technologies for the radio memory buttons on 2014 era infotainment modules. The buttons were proper real buttons, and they could be mapped to any function on the HMI, radio station, settings menu, GPS destination, etc. But you could also rest your finger on them without pressing and the capacitive touch would activate, showing you a preview of what was mapped to that button before you pressed it. It was a physical implementation of a mouse hover. We've really gone backwards on automotive HMI since then

I don't know if "Genava" is the same as modern day Geneva CH, but if it is, then how is can it be correct to show Vienna to the west of it? I get that a subway map abstracts the physical layout, but surely this is a mistake in the topology??