Add the last reviewed version to Cargo.toml / [dependencies]:

secret_integers = "0.1.5"

Filter reviews clicking on the numbers in the summary.

Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.

Neg
Neu
Pos
Str
tho
und
rev
2
2
2
2
crate version
rating
date
reviewer
thoroughness, understanding
secret_integers 0.1.5
negative
2020-01-07
medium, medium

The crate contains no comments on how the supposed constant time operations
are actually achieved. There is no mention of a memory model, no discussion
of references, black boxes, speculation, optimization, etc. And on top of
these theoretical shortcomings the crate also contains no tests to verify any
of their assumptions. This means: no asm output review, no smoke tests for
operation's time dependencies and a general lack of even functional tests.

The classify method is just a glorified constructor and even contains a
generic which will in general have no guarantees and is totally misplaced
here. And declassify doesn't really do anything since the whole type state
can always be dereferenced into the underlying type if the compiler pleases
(and, oh, it will).

An unexplained fill-horn of converters is added. Since they do not perform
any more robust sequencing or basic optimization barriers, one might as well
use the classify constructor instead. They are even declared #[inline]!

Some allocating to-bytes converters are offered. Despite plainly leaking all
values into the global heap without any protection or zeroing after
expiration, they have no documentation, unlike much less dangerous methods.

Despite the fact that several operations are disallowed as a 'security
feature', an inconsistent other set is allowed. Overflow checked operations
will, almost by definition, at least contain conditional moves if compiled
naively using the built-ins. But for some unexplained reason, the division
operation of all is untrusted!

Many other such ops -- with invalid and panicking inputs or similar -- exist:
Rotations will probably do a branch on the input value, additions overflow
check and complain etc. in debug code. Maybe the bitwise operations are not
totally broken.

WORST! Some operations are transliterated from WireGuard. But they contain
TYPOS that plainly contradict newly introduced variable names. How do they
even work? It is not explained.

By the way, the code is copied from a GPL licensed project (WireGuard) but
the crate itself advertises an MIT license. So this might also be a licensing
risk for the future.

secret_integers 0.1.5
negative
2020-01-07
medium, medium

The crate contains no comments on how the supposed constant time operations
are actually achieved. There is no mention of a memory model, no discussion
of references, black boxes, speculation, optimization, etc. And on top of
these theoretical shortcomings the crate also contains no tests to verify any
of their assumptions. This means: no asm output review, no smoke tests for
operation's time dependencies and a general lack of even functional tests.

The classify method is just a glorified constructor and even contains a
generic which will in general have no guarantees and is totally misplaced
here. And declassify doesn't really do anything since the whole type state
can always be dereferenced into the underlying type if the compiler pleases
(and, oh, it will).

An unexplained fill-horn of converters is added. Since they do not perform
any more robust sequencing or basic optimization barriers, one might as well
use the classify constructor instead. They are even declared #[inline]!

Some allocating to-bytes converters are offered. Despite plainly leaking all
values into the global heap without any protection or zeroing after
expiration, they have no documentation, unlike much less dangerous methods.

Despite the fact that several operations are disallowed as a 'security
feature', an inconsistent other set is allowed. Overflow checked operations
will, almost by definition, at least contain conditional moves if compiled
naively using the built-ins. But for some unexplained reason, the division
operation of all is untrusted!

Many other such ops -- with invalid and panicking inputs or similar -- exist:
Rotations will probably do a branch on the input value, additions overflow
check and complain etc. in debug code. Maybe the bitwise operations are not
totally broken.

WORST! Some operations are transliterated from WireGuard. But they contain
TYPOS that plainly contradict newly introduced variable names. How do they
even work? It is not explained.

By the way, the code is copied from a GPL licensed project (WireGuard) but
the crate itself LOOKS like an MIT license but actually mentions APACHE
within the text. So this might also be a licensing risk for the future.

© bestia.dev 2021, MIT Licence, Version: 2021.1208.1729

Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/