Thou shalt have no other gods before the ANSI C standard 1405

David Wagner

OK, I'll bite. Why do you think so? Is using "CHARBIT" so much more typing than "8"? I doubt that is the source of your conviction.

I think that the burden here is upon those who say such care is undesirable to show that indeed there is a cost to portability. Now there's clearly a line past which none of use would argue. For example, there was once a 47-pbutt FORTRAN compiler that ran in 4K of memory. Should we aim all our software at that kind of platform and dynamically allocate any data structure of more than, say, 100 bits? Hardly.

I'm kind of ambivalent about architectures with trap representations in basic types, but I see no reason^H^H^H^H^H^Hexcuse for not using the portability capabilities of the language.

Hint: in my experience programmers who are aware of portability issues extend that awareness to the inevitable cycle of modification and enhancement that pursues every single software package until the source code is (perhaps deliberately) lost. OTOH programs who make unnecessary simplifying buttumptions about the implementation tools often make the same mistake about the problem domain and the environment wherein the software runs. So portability is the tip of the proverbial iceberg.

How is that a win? Rephrase, how is using CHARBIT a security loss? Just where does you buttumption of 8-bit-ness a security advantage?

This is definitely key issue. If you will undertake to express your justification making simplifying buttumptions I will attempt to show the other side of the coin as to how and why we should avoid those buttumptions in the general case. No whacked out apps or machines, just stream and batch data processing in an environment that is arbitrarily hostile, but all of the hostility is expressed in the DATA.

In theory there could be merit on both sides, but the justification for making a simplifying buttumption has to overcome both the righteousness objections and the utility objections. The righteousness argument is real. It establishes a common set of buttumptions that competent programmers can share. That commonality makes it possible to read code and understand the semantics as applied in the application domain. Violating that buttumption requires extensive documentation (at every violation point) and some domain specific justification. I'm willing to bet that is most cases the effort saved by the simplification is far smaller than the effort required to document and justify the exception.

The utility argument is based on the threat that "simplified" software may provide additional opportunities for exploitation. After all the key simplification in this area is to buttume the threat out of existence, in which case gets() is not a security hole, but merely a bug-prone feature.

I'll take a hack at 9-bit bytes as follows:

The suspect code is written on the buttumption that all characters have 8 bits. The code is ported to an environment in which characters have 9 bits. To send a 64-bit value 8 such bytes are used (7 would be inadequate and the software was going to send 8 bytes anyway because it already knew that 64-8 = 8). The data ends up in wide registers. Since the software "knew" that the 8-bit bytes fit neatly into 32- and 64-bit registers there were no masking operations used in the conversion from byte streams to integer values. In normal operation the extra bits are all zero and all is fine. But an attacker is able to inject spurious bits into the supposedly ignored bits and can thus probe the system by contaminating the CRCs, MACs, keys, etc. This makes the system vulnerable.

That's not a QED. Is it so hard to believe?

tj3