...then shuffled that array 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256) times uniquely, each time recording the resulting shuffled array.
Correct as an analogy for block ciphers, but note that there are (2^256)! unique permutations of the input space. You're selecting an unimaginably small slice of possible keyed pseudorandom permutations.
The higher Himalayas are largely unpeopled as well, especially above 4000m. The only time I met people above those altitudes were at night in camps/settlements. I'm sure the EBC route is more crowded, but that's one very small trek in an enormous mountain range.
Oftentimes that comes from road taxes, so it's really car use subsidizing the car-centric projects.
The various vehicle taxes haven't fully covered roadway expansion and maintenance for years. The national average is somewhere in the neighborhood of 60% of costs, I believe.
C has had a catalog of undefined behavior since C99, Annex J. There's sample code demonstrating all cases too.
It's worth noting (as the report itself does) that these sorts of lists can only document explicitly undefined behavior, and not the much larger universe of implicitly undefined behavior. So they're not strictly all possible UB, just the most important cases.
I believe the aim of this C++ paper is to identify all possible UB in the standard. They mention the possibility of implicit UB but take the view that if that exists, that means the standard didn't sufficiently specify what to do in situation X, i.e. it's a bug in the standard that needs a fix.
Affine as in substructural linear types. They correspond to linear logic [0], and affine logic is named such because the way it's defined corresponds to affine functions. You don't literally need to scale your pointers though.
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
The entire point of my post was that it's trivial, exactly as difficult as computing the CRC in the first place. Not sure why that was controversial.
Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.
It's fairly trivial, but still significantly harder than computing a single CRC.
From stackoverflow:
Because a 32-bit CRC yields only 2³² (approx. 4.29 billion) possible outputs, the Birthday Paradox dictates a 50% chance of an accidental collision after processing just ~77,000 unique inputs.
I've done it for shits and giggles and from memory it took my desktop PC maybe 10 minutes to generate a collision.
You're missing the point though.
Noise is not the only thing they should be protecting against.
The point is that AMD is executing code based on checking using an algorithm that has barely any protection from malicious inputs, which is stupid, and not fixing it just compounds that stupidity.
A cryptographic signature protects against both noise and malicious inputs.
It's fairly trivial, but still significantly harder than computing a single CRC.
You can do it with a single GF(2) multiplication, ignoring the complications of reflection and such. A normal CRC is just the special case of making the remainder 0 (again ignoring complications). You can also brute force it, but that's a bit slow for 64 bit CRCs and well, nanoseconds vs minutes in your example.
Noise is not the only thing they should be protecting against.
Sorry, can you point to the comment where I tried to defend AMD's use of CRCs in this particular application? I think I've made it pretty clear that I don't think they're appropriate for cryptographic applications. I was just talking about the math.
Different tools for different purposes. You probably don't want to be using your mac scheme for noise resistance, because then you're paying a cost in either buffer space, PDU size, or retransmits, and your error correction capabilities are nil. CRCs allow some error correction (albeit rarely used and inefficient for multibit errors vs FECs), good bit error detection properties, and are cheap. It's common to use both at different layers of a protocol stack.
reply