251a6e96e8
* WIP constant-time implementation of the ec-divisors library * Fix misc logic errors in poly.rs * Remove accidentally committed test statements * Fix ConstantTimeEq for CoefficientIndex * Correct the iterations formula x**3 / (0 y + x**1) would prior be considered indivisible with iterations = 0. It is divisible however. The amount of iterations should be the amount of coefficients within the numerator *excluding the coefficient for y**0 x**0*. * Poly PartialEq, conditional_select_poly which checks poly structure equivalence If the first passed argument is smaller than the latter, it's padded to the necessary length. Also adds code to trim the remainder as the remainder is the value modulo, so it's very important it remains concise and workable. * Fix the line function It selected the case if both were identity before selecting the case if either were identity, the latter overwriting the former. * Final fixes re: ct_get 1) Our quotient structure does need to be of size equal to the numerator entirely to prevent out-of-bounds reads on it 2) We need to get from yx_coefficients if of length >=, so if the length is 1 we can read y_pow=1 from it. If y_pow=0, and its length is 0 so it has no inner Vecs, we need to fall back with the guard y_pow != 0. * Add a trim algorithm to lib.rs to prevent Polys from becoming unbearably gigantic Our Poly algorithm is incredibly leaky. While it presumably should be improved, we can take advantage of our known structure while constructing divisors (and the small modulus) to simply trim out the zero coefficients leaked. This maintains Polys in a manageable size. * Move constant-time scalar mul gadget divisor creation from dkg to ec-divisors Anyone creating a divisor for the scalar mul gadget should use constant time code, so this code should at least be in the EC gadgets crate It's of non-trivial complexity to deal with otherwise. * Remove unsafe, cache timing attacks from ec-divisors |
||
---|---|---|
.github | ||
audits | ||
common | ||
coordinator | ||
crypto | ||
docs | ||
message-queue | ||
mini | ||
networks | ||
orchestration | ||
patches | ||
processor | ||
spec | ||
substrate | ||
tests | ||
.gitattributes | ||
.gitignore | ||
.rustfmt.toml | ||
AGPL-3.0 | ||
Cargo.lock | ||
Cargo.toml | ||
CONTRIBUTING.md | ||
deny.toml | ||
LICENSE | ||
README.md | ||
rust-toolchain.toml |
Serai
Serai is a new DEX, built from the ground up, initially planning on listing Bitcoin, Ethereum, DAI, and Monero, offering a liquidity-pool-based trading experience. Funds are stored in an economically secured threshold-multisig wallet.
Layout
-
audits
: Audits for various parts of Serai. -
spec
: The specification of the Serai protocol, both internally and as networked. -
docs
: User-facing documentation on the Serai protocol. -
common
: Crates containing utilities common to a variety of areas under Serai, none neatly fitting under another category. -
crypto
: A series of composable cryptographic libraries built around theff
/group
APIs, achieving a variety of tasks. These range from generic infrastructure, to our IETF-compliant FROST implementation, to a DLEq proof as needed for Bitcoin-Monero atomic swaps. -
networks
: Various libraries intended for usage in Serai yet also by the wider community. This means they will always support the functionality Serai needs, yet won't disadvantage other use cases when possible. -
message-queue
: An ordered message server so services can talk to each other, even when the other is offline. -
processor
: A generic chain processor to process data for Serai and process events from Serai, executing transactions as expected and needed. -
coordinator
: A service to manage processors and communicate over a P2P network with other validators. -
substrate
: Substrate crates used to instantiate the Serai network. -
orchestration
: Dockerfiles and scripts to deploy a Serai node/test environment. -
tests
: Tests for various crates. Generally,crate/src/tests
is used, orcrate/tests
, yet any tests requiring crates' binaries are placed here.
Security
Serai hosts a bug bounty program via Immunefi. For in-scope critical vulnerabilities, we will reward whitehats with up to $30,000.
Anything not in-scope should still be submitted through Immunefi, with rewards issued at the discretion of the Immunefi program managers.
Links
- Website: https://serai.exchange/
- Immunefi: https://immunefi.com/bounty/serai/
- Twitter: https://twitter.com/SeraiDEX
- Mastodon: https://cryptodon.lol/@serai
- Discord: https://discord.gg/mpEUtJR3vz
- Matrix: https://matrix.to/#/#serai:matrix.org
- Reddit: https://www.reddit.com/r/SeraiDEX/
- Telegram: https://t.me/SeraiDEX