Update 01_XX_cmce.rst

docs/audit_report/src/side_channels/01_XX_cmce.rst

@@ -28,7 +28,7 @@ The Botan library is configured using the following console prompt:
 
 .. code-block::
 
-        ./configure.py --prefix=./build --cc=gcc
+    ./configure.py --prefix=./build --cc=gcc
     --cc-bin=/home/wagner/workspace/tools/homebrew/Cellar/gcc@11/11.4.0/bin/g++-11      \
     --cc-abi=-fno-plt                                                                   \
     --disable-modules locking_allocator --disable-sse2 --disable-ssse3                  \
@@ -48,14 +48,15 @@ The host operating system is `Ubuntu 20.04.6 LTS`.
 
 **Analysis with DATA**
 
-DATA identified in the first evaluation runs leakage points within the routines used for key pair generation, encryption and decryption.
-Based on these results, the in the utility program instantiated PRNG was modified to isolate the cause of the observed leakage points.
-The modifications included to seed the PRNG with a constant and a key-unique seed.
-The constant seed resulted in no differences within the execution, in contrast the key-unique seed resulted in clear distinction of the execution traces between the used key material.
+In the first evaluation runs DATA identified leakage points within the routines used for key pair generation, encryption and decryption.
+Based on these results, the PRNG instantiated in the utility program was modified to isolate the cause of the observed leakage points.
+The modifications comprised seeding the PRNG with a constant and a key-unique seed.
+The constant seed resulted in no differences within the execution.
+In contrast, the key-unique seed resulted in a clear distinction of the execution traces between the used key material.
 
-The leakage boils down to the same lines for all three routines within the CMCE Botan implementation.
-In the following we describe the leakage cause and criticality within the decryption routine.
-Please note, that this also applies to the key pair generation and encryption routine, but is omitted here as the information would be redundant.
+The leakage occurs at the same lines of code for all three routines (key pair generation, encryption, decryption) within the CMCE Botan implementation.
+In the following we describe the cause of the leakage and the criticality in relation to the decryption routine.
+Please note that this also applies to the key pair generation and encryption routine, but is omitted here as the information would be redundant.
 
 The leakage was observed in the `decode()` routine which is part of the `Classic_McEliece_Decryptor`.
 The function definition is in the file `cmce_decaps.cpp` in file 84 to 119.
@@ -100,10 +101,10 @@ It is listed below:
        return {decode_success, std::move(e)};
     }
 
-Within the `decode()` function the leakage was observed in line 102 to 106.
+Within the `decode()` function the leakage was observed at code lines 102 to 106.
 This is the part where the error vector `e` is obtained.
-The identified leakage was due to a codeflow difference.
-This codeflow difference stems from the code in the `bitvector.h` file in line 223.
+The identified leakage was due to an execution flow difference.
+This execution flow difference stems from the code in the `bitvector.h` file at line 223.
 It contains the following constant expression: A bit is set if the given bool is true.
 The relevant line is listed below:
 
@@ -112,15 +113,15 @@ The relevant line is listed below:
          private:
             constexpr bitref& assign(bool bit) noexcept { return (bit) ? set() : unset(); }
 
-If this line is compiled it results in an assembly which contains a conditional jump instruction.
+When compiled, this line results in a conditional jump instruction in assembly code.
 Depending on the boolean input value a different code branch is executed.
-This expression is executed when assigning values to the elements of `e` in line 104:
+This expression is executed when assigning values to the elements of `e` at line 104:
 
 .. code-block::
 
       e.push_back(is_zero_mask.as_bool());
 
-The `push_back()` routine is contained in the file `bitvector.h` in line 381 to 385 and implemented as follows:
+The `push_back()` routine is contained in the file `bitvector.h` at lines 381 to 385 and is implemented as follows:
 
 .. code-block::
 
@@ -130,26 +131,23 @@ The `push_back()` routine is contained in the file `bitvector.h` in line 381 to
          ref(i) = bit;
       }
 
-The `=` operator in line 384 is implemented for the `bitvector` class in line 208 as:
+The `=` operator at line 384 is implemented for the `bitvector` class at line 208 as:
 
 .. code-block::
 
             constexpr bitref& operator=(bool bit) noexcept { return assign(bit); }
 
 This results in a call of the `assign()` routine listed above.
 
-The identified leakage would allow an adversary to potentially recover the error vector from the code execution.
-Hence, potential critical.
-
+The identified leakage would allow an adversary to potentially recover the error vector from the code execution, which is security critical.
 
 **Countermeasure implementation and evaluation**
 
 In the following, we propose a countermeasure, implement it and evaluate its effectiveness.
 The underlying issue of the leakage is due to the branch of the `?` operator used in the `assign()` routine.
-This must be avoided.
-To do so, set and unset have to be performed regardless of the input value.
-As only one of the two operations is wanted, the design has to be as such as the unwanted evaluation of the both a re ineffective.
-Below is a countermeasure proposal:
+This must be avoided, e.g., by performing the set and unset operations regardless of the input value.
+As only one of the two operations is needed at a time, the other operation has to be ineffective.
+Below is a proposal for such a countermeasure:
 
 .. code-block::
 
@@ -161,11 +159,9 @@ Below is a countermeasure proposal:
                 return \*this;
             }
 
-The input bool `bit` is casted as an `uint8_t` datatype. It is used to generate a mask.
-This mask is used to force the unwanted evaluation to be ineffective and such that only the wanted evaluation has an effect.
-
-
-For the exemplary created binary for the analysis this results in the following instructions - without any conditional branch based on the input:
+The input bool `bit` is casted as an `uint8_t` datatype and is used to generate a mask.
+This mask is used to implement the behavior that only one operation is effective at a time.
+When compiled, this results in the following instructions - without any conditional branch based on the input:
 
 .. code-block::