jonmon6691

I made something like this! Except I have it plugged into an outlet in the kitchen, so no battery to deal with. It's a little hacky but it works for me.

https://github.com/jonmon6691/arduino_busstop

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.

I found this article helpful when I had that same question. Basically BER has some less rigid specifications for how to encode the data that can be convenient for the implementation. Such as symbol-terminated sequences instead of having to know their length ahead of time. But this means that there are many equivalent serializations of the same underlying object, which is problematic for cryptography, so DER is an unambiguous subset of BER which will have only one correct possible serialization for a given object.

https://luca.ntop.org/Teaching/Appunti/asn1.html

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??

With so many mentions of footguns these days, I was surprised that a cursory search of HN didn't show this timeless link in a post recently.

This is really not a new thing, ups and fedex have been using custom package cars for decades. It seems totally crazy to go with a military contractor for something that we have a mature industry for a la FCCC or Paccar equivalent

I totally agree. I actually just built some scripts to do this using rclone, but they could easily be modified to work with a remote ZFS which is actually way more ideal. It is encrypted in-flight, and at rest on the remote, and merging block-level increments never require decryption. My key never has to leave my local machine.

https://github.com/jonmon6691/storage_architecture