Sujet : Re: FOSS and backdoors in the US
De : rich (at) *nospam* example.invalid (Rich)
Groupes : sci.cryptDate : 29. Apr 2024, 21:38:47
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v0p0gm$1uvh2$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Chris M. Thomasson <
chris.m.thomasson.1@gmail.com> wrote:
On 4/29/2024 10:45 AM, Stefan Claas wrote:
But would a published algorithm not been more peer reviewed than
later a lot of code implementations, from various people?
I hope so! I ask this question about HMAC because my experimental
encryption uses it.
There your larger concern would be someone hiding a backdoor in the
python library you utilize to perform the HMAC. I.e., someone
slipping compressed and obsfucated test files into the tests directory
for the library, then modifying the python build system in a sly way to
deobsfucate and decompress the test files, yielding "backdoor code"
that is slyly inserted into the copy of the library your example on the
web loads when it does its work.
While that is tricky to keep hidden, it is by far your bigger threat
than worrying that there's a backdoor in the underlying HMAC algorithm.
The underlying algorithm (assuming it is SHA or one of the other known
ones) has likely been vetted enough that it (if followed to the letter
by a given library) does not have a probem.
But the library you use, do you carefully check just exactly what
changed when you upgrade to a new version (for whatever reason you
might upgrade to a new version)? That's the path to being backdoored,
something getting slipped into the library code you are using.
And, note, the library could be backdoored such that when you feed it
data, it produces the exact expected outputs (while also doing
something else as well). Which would mean any tests you might have
yourself to verify the library produces correct hash outputs would
pass, even though the "backdoor code" got inserted.