Problem definition

Different users of the XMSS library have different requirements for bit error resilience. We consider the following problems with simple booleans:

Single upset events.

A single upset event can flip a single bit in the return value, or sometimes even the adjacent bits. This could turn a value of zero into a value of non-zero, or it could turn a non-zero value (most notably the value one, a common value for true) into a value of zero. A single upset event could invert the naive values zero for false and one for true.
Fault injections.
1. An attacker may (e.g., by power glitching) induce well-timed bit flips in the underlying hardware, effectively inverting the boolean interpretation of the returned value.
2. An attacker may (e.g., by clock glitching) replace entire bit sequences with sequences of 0 or 1. With such attacks it is possible to turn any return value into the value zero, a value that is often used to indicate success in C.

Rationale for using Hamming codes

To mitigate both problems, the API always returns values that have a Hamming distance of at least 4 bits

with respect to each other,
from the value 0 (represented by all bits 0), and
from the value represented by all bits 1.

In practice, the API uses the extended Hamming(8,4) code. Note that even though this code allows to correct for single bit errors, we recommend against using error correction at all. Instead, it is recommended to only detect bit errors and to handle any failures appropriately.

The Hamming(8,4) codes consist of 16 different data values using 8 bits, one of which is represented by all bits 0.

The value with all bits 0 is not used.

One non-zero value is selected to represent true, another non-zero value is selected to represent false.

Rationale for not using a value with all bits 0

One identified fault injection attack is to replace all bits with 0. This is mitigated by requiring that a value with all bits 0 is never a valid return value.

Relation to functions returning an error code

The remaining 13 Hamming(8,4) codes, excluding the values for true and false and excluding the value with all bits 0, are available to bit error resilient error and/or success values.

Rationale for using 8-bit values on 32/64-bit platforms

The API always uses return type int, which is at least 32 bits on the supported platforms. Therefore, all Hamming(8,4) codes have a Hamming distance of at least 24 with respect to the fault injection attack forcing all bits to 1.

Some instruction sets are optimized for comparison with immediate 8-bit values. Even though a return value is usually of type int, which is usually 32 bits, it is still beneficial to restrict the return values to 8 bits when possible. In case more than 15 different return values are required, it is recommended to use the 15 non-zero Hamming(8,4) codes for the most common values and augment them with other values beyond 8 bits and restrict those values to also having a Hamming distance of at least 4 with respect to each other and with respect to the Hamming(8,4) codes.

Conclusion

The API ensures that both logical return values true and false are resilient against any 1, 2, or 3 bit errors, as well as against replacing all bits of the return value with either 0 or 1.

The API furthermore allows for up to 13 efficient, bit error resilient, success/error return values.