4 The ISO/IEC Standardization of Simon and Speck
67
As a result of substantial resistance to their attempts to standardize Simon and
Speck in ISO—discussed further below—the designers finally offered to ISO what
they called a “design rationale” in April 2017. As per the request from ISO experts,
this so-called design rationale was made public to the crypto-community via the
ePrint repository in June 2017 [66]. 2 The purpose of releasing this design rationale
is stated in Sect. 4.4:
A desire has been expressed that we publish our analysis of Simon and Speck, and we
certainly understand the wish to have insight into our analysis. Therefore, we would like
to address that here. We will begin by addressing how we as the design team considered
the standard block cipher attacks and their applicability to the security of the SIMON and
SPECK design.
However, the joy of finally having a design rationale was short-lived. While the
document is heavy on selling the algorithms’ efficiency, the security part of the
design rationale is practically non-existent. A careful reading of [66, Sec. 4] reveals
that it includes no new information regarding the algorithms’ security, and merely
cites publicly known third party analysis. In particular, three caveats which we now
describe in detail raised questions about whether this so-called design rationale was
published in good faith.
4.3.1 Lack of New Information
Rather than explaining the attacks the design team attempted, the authors quote the
work of others without committing to any particular security claim. The so-called
security analysis opens with:
As the limiting attacks on Simon and Speck have been observed to be differential and linear
attacks, it is important to understand the linear and differential properties of the algorithms.
Fortunately, this has been a focus of the academic research, and it was an area we paid
considerable attention to in our design effort.
The design team used standard techniques (Matsui’s algorithm, SAT/SMT solvers) to
determine optimal differential and linear paths for Simon and Speck. We agree with the
results obtained by outside researchers.
Reading this, the expectation was that the design team would explain in detail the
methods used to bound the length of differential and linear paths 3 and release their
tools so that the results they obtained can be reproduced. Instead, they proceeded to
describe academic works, sometimes veiling published results as original work by
the design team.
2 We remind the reader that the algorithms were published in June 2013, i.e., 4 years prior.
3 The designers use the term “path” in place of the more common terms “characteristic” and “trail”
and we will follow suit.
67
As a result of substantial resistance to their attempts to standardize Simon and
Speck in ISO—discussed further below—the designers finally offered to ISO what
they called a “design rationale” in April 2017. As per the request from ISO experts,
this so-called design rationale was made public to the crypto-community via the
ePrint repository in June 2017 [66]. 2 The purpose of releasing this design rationale
is stated in Sect. 4.4:
A desire has been expressed that we publish our analysis of Simon and Speck, and we
certainly understand the wish to have insight into our analysis. Therefore, we would like
to address that here. We will begin by addressing how we as the design team considered
the standard block cipher attacks and their applicability to the security of the SIMON and
SPECK design.
However, the joy of finally having a design rationale was short-lived. While the
document is heavy on selling the algorithms’ efficiency, the security part of the
design rationale is practically non-existent. A careful reading of [66, Sec. 4] reveals
that it includes no new information regarding the algorithms’ security, and merely
cites publicly known third party analysis. In particular, three caveats which we now
describe in detail raised questions about whether this so-called design rationale was
published in good faith.
4.3.1 Lack of New Information
Rather than explaining the attacks the design team attempted, the authors quote the
work of others without committing to any particular security claim. The so-called
security analysis opens with:
As the limiting attacks on Simon and Speck have been observed to be differential and linear
attacks, it is important to understand the linear and differential properties of the algorithms.
Fortunately, this has been a focus of the academic research, and it was an area we paid
considerable attention to in our design effort.
The design team used standard techniques (Matsui’s algorithm, SAT/SMT solvers) to
determine optimal differential and linear paths for Simon and Speck. We agree with the
results obtained by outside researchers.
Reading this, the expectation was that the design team would explain in detail the
methods used to bound the length of differential and linear paths 3 and release their
tools so that the results they obtained can be reproduced. Instead, they proceeded to
describe academic works, sometimes veiling published results as original work by
the design team.
2 We remind the reader that the algorithms were published in June 2013, i.e., 4 years prior.
3 The designers use the term “path” in place of the more common terms “characteristic” and “trail”
and we will follow suit.