jonmon6691 (u/jonmon6691)

jonmon6691 commented on Mobile carriers can get your GPS location an.dywa.ng/carrier-gnss.h... · Posted by u/cbeuw

NoiseBert69 · 12 days ago

Meshcore and -tastic have the huge problem that the encryption keys are bound to the device and not the app.

jonmon6691 · 12 days ago

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.

jonmon6691 commented on Exploring Dithering on Spectra 6-color E-Ink Displays myembeddedstuff.com/e-ink... · Posted by u/edent

jonmon6691 · a month ago

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.

jonmon6691 commented on AI agents break rules under everyday pressure spectrum.ieee.org/ai-agen... · Posted by u/pseudolus

scotty79 · 2 months ago

At one point if someone mentions they have trouble cooperating with AI it might be a huge interpersonal red flag, because that indicates they can't talk to a person in reaffirming and constructive ways so that they build you up rather than put down.

jonmon6691 · 2 months ago

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

jonmon6691 commented on Imperial Tyranny, Korean Humiliation english.hani.co.kr/arti/e... · Posted by u/anigbrowl

antonymoose · 5 months ago

The big question, and please don’t go ape on me, is were these workers actually here with proper visas, did corporate screw up, or was this willful action on the part of the individuals?

I’m tired of seeing stories with no real facts and similarly tired of comment sections discussing the issue without them either.

What actually happened here?

jonmon6691 · 5 months ago

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.

jonmon6691 commented on NIST selects HQC as fifth algorithm for post-quantum encryption nist.gov/news-events/news... · Posted by u/gnabgib

whimsicalism · a year ago

Give how quickly quantum is potentially coming, I wonder if we should/could find some way of using multiple quantum-resistant algorithms simultaneously as a default, in case a fault is found after the limited time we have to verify that there are no faults.

Also - should we not be switching over to these algorithms starting like... now? Am I wrong that anyone collecting https traffic now will be able to break it in the future?

jonmon6691 · a year ago

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.

jonmon6691 commented on The Rise of Worse Is Better (1991) dreamsongs.com/RiseOfWors... · Posted by u/t14n

goalieca · a year ago

I’m always confused about when to use DER and when to use BER. Pretty much have to study the history to get it.

jonmon6691 · a year ago

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

jonmon6691 commented on Better-performing “25519” elliptic-curve cryptography amazon.science/blog/bette... · Posted by u/lemaudit

dlgeek · a year ago

The industry is moving to a hybrid that mixes classic crypto (including ECC) with post-quantum crypto. AWS has even turned this on in some places - https://aws.amazon.com/about-aws/whats-new/2022/03/aws-kms-a... from 2022 and https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.... for some details.

jonmon6691 · a year ago

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

jonmon6691 commented on OpenSSH Keystroke Obfuscation Bypass crzphil.github.io/posts/s... · Posted by u/pabs3

mrngm · a year ago

This and a similar suggestion in another thread may sound nice and easy, "just add a constant stream of noise", but it assumes you can generate enough constant noise and be able to intersperse the noise with valid commands without being able to distinguish these events. The problem is not necessarily that you want to hide (to a network adversary) that you've been typing. It's that you do not want to reveal, through some side-channel, what the exact contents were.

On the openssh-unix-dev mailing list, someone recently pointed out[0] that just periodically (without jitter) sending out packets may be problematic due to subtle differences in clock timing. Aside, they also link to a presentation[1] [PDF] that shows influence of temperature on clock skew (especially page 18) and that this gives a possibility for fingerprinting.

Then there's the challenge of keeping SSH interactive enough that people do not experience too much input lag while typing. What if the user typed a character, but due to such a timing side-channel preventive measure, that character needs to be sent in the next packet, adding latency to the user experience? Surely it improves security, but it may add too much frustration for regular usage.

[0] https://marc.info/?l=openssh-unix-dev&m=169402700622936&w=2 [1] https://murdoch.is/talks/ccs06hotornot.pdf ([2006] Hot or Not: Revealing hidden services by their clock skew, see also https://doi.org/10.1145/1180405.1180410 and an HN thread from 2014: https://news.ycombinator.com/item?id=7694612)

jonmon6691 · a year ago

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.

jonmon6691 commented on Better-performing “25519” elliptic-curve cryptography amazon.science/blog/bette... · Posted by u/lemaudit

jonmon6691 · a year ago

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.

jonmon6691 commented on OpenSSH Keystroke Obfuscation Bypass crzphil.github.io/posts/s... · Posted by u/pabs3

jonmon6691 · a year ago

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.