[Cryptography] how reliably do audits spot backdoors?

[Jerry Leichter]

On Dec 28, 2013, at 6:16 PM, Jonathan Thornburg wrote:
Minor correction:
> In Java, ONLY 32-bit signed integers are available; there are NO unsigned
> integers and no 64-bit (or other-length) integers available.
Untrue.  Java has only signed integral types, always 2's complement, but it has short (16 bits), int (32 bits), and long (64 bits).  (While both int's and long's are common - with int being used in some places, like hash values, that arguably should be long's today but remain int's because machines had 32 bit words when Java was defined, I don't recall ever seeing a short in a piece of Java code.)

> Moreover, integer overflow checking is forbidden, i.e., if you take i = 2147483647 and add one to it, the result is REQUIRED to be -2147483648.
You say that like it's a bad thing.  :-)  Seriously, it's a completely consistent definition, and if one is concerned about the numerics, it's easy to detect overflows and such.  What's good about it is that it's definitely and completely specified.  You know exactly what to expect.

The story is more complicated for floats, where whether you're operating in strictfp mode or not has a major effect on semantics (and performance).  (You would think that strictfp mode was there for numerical codes, but in fact for most numerical codes, it kills performance without actually solving any interesting problems.  It's basically there for backwards compatibility with very old versions of Java, which had *only* the equivalent of fpstrict mode.)

C (and C++) have always defined unsigned arithmetic as arithmetic mod 2^n, but signed arithmetic used to be almost completely a "quality of implementation" issue.  It's been a while since I looked, but I believe the recent standards insist on a binary representation that's either 1's- or 2's-complement.  So much for you decimal machines!  (Don't laugh:  The first computer I ever used as an IBM 1620 - which *was* a decimal machine!)

> In C++, native integers are the same as C, but the language permits one
> to define (say) an integer-with-guaranteed-overflow-checking class; other
> code can then rely on overflows being caught.
Yes, but it can't have the full semantics of the built-in integer types (in particular, conversions are not promotions and vice versa).

                                                        -- Jerry