Ok, it's offtopic. But whoever calls it realtime is wrong. It can be done predictable in maximum delay, but we are talking milliseconds delays anyway. And I insist that encryption won't require any bandwidth overhead and delays anywhere close to naturally expected from CAN bus.It's realtime by convenience; every controller operates with it and performs critical operations over the bus. You also keep saying queue as if that is a thing within the spec. It's timing based on priority and arbitration with transmission delay. If a lower priority node sees a transmission it just waits until the next. Any small disruption to the order can compound to a lot of missed frames and disruption over the network for lower-priority nodes.
But I don't really need to rely on my understanding of the protocol as there are many sources citing CAN as realtime (even if we both agree serial multiplex is not the best implementation for that purpose!!).
Lets take VCfront for example, with a 120 MHz clockspeed max. Now that's monstrously fast for an embedded device but considering all the operations it handles (everything forward of the firewall and HV equipment), that leaves very few cycles for general computation. There is an encryption engine that connected to the memory protection unit but that appears to only be used for hardening the memory. So any encryption algorithm would have to use the general instruction set, and would need to be tailored to each module (assuming that everything on the CAN isn't using the same monster chip).
Maybe you can speak to programming an embedded device; I certainly can't. But my understanding is that it contains no fluff and coding an arbitrary encryption algo would be difficult, hence the use of engines and peripheral chips. Couple that with the minor overhead to bandwidth, it makes implementing encryption with the current hardware extremely difficult, if not practically impossible. CAN encryption is a pointless endeavor, like teaching a horse how to pilot a plane; it's a difficult, pointless addition to something that already works.
In any case, we already agreed that detection and defeat of a CAN module is arbitrarily easy. The whole encryption debacle is theoretical nonsense.
If you can safely and regularly exchange a symmetric key (and Tesla modules can do that) - encryption of 8 bytes (maximum length of data in CAN) is incredibly fast with just a regular arithmetic instruction set. You can just XOR it with a key and be done with it. No bandwidth loss, way below 1 microsecond delay.