Like how would this attack work in reality? It's not like the car would have a keyboard inviting spurious input. Or perhaps there's an assumption that some network interface should be available for arbitrary input. In both cases, the problem wouldn't be the LLM but the system design that allows arbitrary and totally unneeded input.
It's not like you can get to the car's internal networking or anything.
Hackers Are Stealing Cars by Injecting Code Into Headlight Wiring
There's all this hand-wringing over the collection and sale of personal data, but I really have to wonder if there's any point to it. I couldn't tell you the last time advertising affected my decision to purchase (or not) any particular product or service. It doesn't matter how many ads Levi's throws on my browser when I already know I'll be picking up my next pair of jeans at Costco, nor Sony when I'm not even interested in a gaming console, nor anybody else. Google reads my email and knows I'm registered for a coaching clinic? More power to them... good luck getting me to register for that second clinic six months from now halfway across the country, 'cause no matter how many times they shill it, my budget's not going to allow it. My purchasing either goes through a programmatic decision tree (i want a compact car with minimum t mpg and features r, s, and x... these are the models which satisfy, go test drive), or are literally "I have the munchies for chocolate crunchies, and Butterfinger has never failed me."
Wait until your health insurance costs twice as much next year because their AI decided that your spending habits correlate with people who have above average risk for various health issues, or you are no longer eligible for life insurance because there's too high a risk that your spending patterns mean they are too likely to have to pay out next year. Maybe the next time you're at the shop, Butterfingers cost twice as much for you because your purchasing pattern indicates that you will buy them anyway. It's going to get ugly.
Using X25519Kyber768 adds over a kilobyte of extra data to the TLS ClientHello message due to the addition of the Kyber-encapsulated key material. Our earlier experiments with CECPQ2 demonstrated that the vast majority of TLS implementations are compatible with this size increase; however, in certain limited cases, TLS middleboxes failed due to improperly hardcoded restrictions on message size.
Khyber1024 adds an additional ~400 bytes to the key size, making it greater than 1500 bytes (1568). This will be even more problematic than khyber768.
What is worth doing is worth the trouble of asking somebody to do.