kasarlabs / barknet Goto Github PK

Timing variability in curve25519-dalek's Scalar29::sub/Scalar52::sub

Timing variability of any kind is problematic when working with potentially secret values such as
elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a
problem was recently discovered in curve25519-dalek.

The Scalar29::sub (32-bit) and Scalar52::sub (64-bit) functions contained usage of a mask value
inside a loop where LLVM saw an opportunity to insert a branch instruction (jns on x86) to
conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:

• 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv
• 64-bit (see L48): https://godbolt.org/z/PczYj7Pda

A similar problem was recently discovered in the Kyber reference implementation:

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ

As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a
volatile read as an optimization barrier, which prevents the compiler from optimizing it away.

The fix can be validated in godbolt here:

• 32-bit: https://godbolt.org/z/jc9j7eb8E
• 64-bit: https://godbolt.org/z/x8d46Yfah

The problem was discovered and the solution independently verified by
Alexander Wagner <[email protected]> and Lea Themint <[email protected]> using
their DATA tool:

https://github.com/Fraunhofer-AISEC/DATA

See advisory page for additional details.

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

A possible workaround for crates affected through the transitive dependency in chrono, is to avoid using the default oldtime feature dependency of the chrono crate by disabling its default-features and manually specifying the required features instead.

Examples:

Cargo.toml:

chrono = { version = "0.4", default-features = false, features = ["serde"] }

chrono = { version = "0.4.22", default-features = false, features = ["clock"] }

Commandline:

cargo add chrono --no-default-features -F clock

Sources:

• chronotope/chrono#602 (comment)
• vityafx/serde-aux#21

See advisory page for additional details.

webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in
<briansmith/webpki#69> and re-reported recently
by Luke Malinowski.

rustls-webpki is a fork of this crate which contains a fix for this issue
and is actively maintained.

See advisory page for additional details.

webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in
<briansmith/webpki#69> and re-reported recently
by Luke Malinowski.

rustls-webpki is a fork of this crate which contains a fix for this issue
and is actively maintained.

See advisory page for additional details.

Testings for the first Barknet barknet state inscription inside Bitcoin regtest.

Description:

Create a new module in Barknet named bitcoin to house all the Bitcoin-specific data availability functions and structures. The goal is to have parity with other da's

Tasks:

1 - Merge keep-starknet-strange#1021 into net (only issue that can be merged to dev directly)
2 - Create a new directory and module named bitcoin and initiate the same architecture as the other da's.
3 - Include the necessary imports from the Bitcoin-da crate.

Implement da_config.json. if you're working off the current PR you will put a config json in your madara path w/ the bitcoin specific configs "/da-config.json". Then initialize madara with the da-layer CLI flag:

RUST_LOG=info cargo run --release -- --da-layer=ethereum --dev

You will also need to add bitcoin to the DaLayer enum

Testings for the first Barknet barknet state inscription inside Bitcoin Signet (https://en.bitcoin.it/wiki/Signet) testnet directly. Use https://signetfaucet.com/ for test tokens

Implement Bitcoin devnet under scripting

Description:

Integrate methods in the BitcoinClient struct that cater to Bitcoin's unique data availability requirements, leveraging the functionalities provided in the Bitcoin-da crate.

Tasks:

1. Design Methods to Listen to Storage Changes for Bitcoin:

   • Listen to Changes:

     • Design a method in BitcoinClient that listens for relevant storage changes in the substrate.
     • This method should be asynchronous and might involve hooks or listeners to the substrate's storage system.

   • Process Changes:

     • Once detected, these changes should be processed and prepared for potential publication on the Bitcoin network.
     • Utilize the chunk_slice utility to handle large data sets that exceed Bitcoin's transaction size limits.

2. Implement a Method to Update the Bitcoin State:

   • Fetch Latest State:

     • Create a method, e.g., update_bitcoin_state, that fetches the latest state from the substrate system.
     • Use the Bitcoin-da crate's RPC functionalities to interact with a Bitcoin node and fetch relevant data.

   • Process State:

     • Depending on the DaMode, decide how to process and potentially publish this state.
     • Maintain a record of the last published state to prevent redundant publications.

3. Address Unique Bitcoin Characteristics:

   • UTXO Model:

     • Implement functionalities to handle Bitcoin's UTXO model correctly. This might involve:
       • Selecting the right UTXOs for transactions.
       • Managing change outputs.
       • Ensuring transaction outputs aren't double-spent.

   • Data Embedding:

     • Given the functionalities like extract_push_data, design methods to embed and extract data from Bitcoin transactions. This is essential for data availability.

   • Taproot:

     • Bitcoin's Taproot offers advanced scripting possibilities. If your implementation requires complex scripts or wishes to leverage Taproot for privacy, design methods accordingly.
     • Utilize the Bitcoin-da crate's Taproot functionalities to construct and interpret Taproot-based transactions.

Add manual sealing in Barknet to avoid empty blocks inscriptions

Implement bitcoin-da to Substrate full node via servie.rs: https://github.com/KasarLabs/net/blob/3720836791141854ff88f96bc4b04fb76d10294e/crates/node/src/service.rs#L400

mach is unmaintained

Last release was almost 4 years ago.

Maintainer(s) seem to be completely unreachable.

Possible Alternative(s)

These may or may not be suitable alternatives and have not been vetted in any way;

• mach2 - direct fork

See advisory page for additional details.

Description:

Ensure that the integration of the Bitcoin-da functionality into the substrate node is robust, functional, and free of critical bugs.

Tasks:

1. Design Unit Tests for BitcoinClient and Its Methods:

   • Initialize BitcoinClient:

     • Test the initialization of the BitcoinClient structure with different configurations.
     • Validate that it can successfully connect to a Bitcoin node using provided RPC credentials.

   • Data Handling Methods:

     • Test methods responsible for handling storage changes:

       • Ensure that changes are detected correctly.
       • Validate that large data sets are chunked appropriately using the chunk_slice utility.

     • Test the update_bitcoin_state method:

       • Ensure it fetches the correct state from the substrate system.
       • Validate its behavior for different DaMode settings.

   • Error Handling:

     • Use the BitcoinError enum to trigger different error scenarios.
     • Ensure that the BitcoinClient methods handle errors gracefully and provide meaningful error messages.

2. Implement Integration Tests for Substrate Compatibility:

   • Integration with Substrate Storage:

     • Ensure that the BitcoinClient can listen to substrate storage changes seamlessly.
     • Validate that state updates in the substrate system are correctly processed by the BitcoinClient.

   • Transaction Broadcasting:

     • Simulate the broadcasting of Bitcoin transactions that contain data from the substrate system.
     • Check that these transactions are formed correctly, with data embedded as expected.

   • State Synchronization:

     • Modify the state in the substrate system and ensure that the BitcoinClient recognizes and processes these changes.
     • Validate that the state on the substrate system and the data on the Bitcoin network remain synchronized.

3. Test on Bitcoin's Testnet:

   • Environment Setup:

     • Set up a local or remote Bitcoin node connected to the testnet.
     • Configure the BitcoinClient to interact with this testnet node.

   • Transaction Tests:

     • Broadcast transactions to the testnet that embed substrate data.
     • Ensure that these transactions are confirmed and can be viewed on Bitcoin testnet explorers.

   • Data Extraction:

     • After broadcasting transactions, attempt to extract the embedded data.
     • Ensure that the extracted data matches the original substrate data.

   • Performance and Stability:

     • Monitor the stability of the BitcoinClient over extended periods on the testnet.
     • Measure performance metrics like transaction confirmation times, data extraction times, etc.

   • Edge Cases:

     • Simulate edge cases like transaction rejections, chain reorganizations on testnet, etc.
     • Ensure that the BitcoinClient can handle these scenarios gracefully.

Crate parity-wasm deprecated by the author

This PR explicitly deprecates parity-wasm.
The author recommends switching to wasm-tools.

See advisory page for additional details.

dotenv is Unmaintained

dotenv by description is meant to be used in development or testing only.

Using this in production may or may not be advisable.

Alternatives

The below may or may not be feasible alternative(s):

• dotenvy

See advisory page for additional details.

aes-soft has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new force-soft feature of the aes
crate to disable autodetection.

See advisory page for additional details.

Description:

Establish a BitcoinClient struct within the bitcoin module to facilitate interactions with the Bitcoin network. This structure must conform to the DaClient trait.

Tasks:

1. Define the BitcoinClient Struct:

   • Fields:

     • rpc_client: An instance or connection to a Bitcoin RPC client. This field will allow direct interactions with a Bitcoin node.
     • network_type: Specifies the Bitcoin network (mainnet, testnet, regtest).
     • mode: Specifies the mode of data availability (e.g., DaMode::Sovereign).
     • Additional fields can be integrated based on specific requirements, such as authentication credentials, wallet addresses, etc.

   • Example Structure:

   pub struct BitcoinClient {
       rpc_client: RpcClient,  // Use the appropriate type from the Bitcoin-da crate
       network_type: String,
       mode: DaMode,
       // Add other fields as required
   }

2. Implement the DaClient Trait for BitcoinClient:

   • Method Skeletons:

     • Based on the DaClient trait, define the methods that BitcoinClient will need to implement.
     • Initially, these methods can return default values or unimplemented!() to be filled in later.

   • Example Skeleton:

   impl DaClient for BitcoinClient {
       fn get_mode(&self) -> DaMode {
           self.mode
       }
   
       async fn last_published_state(&self) -> Result<I256> {
           unimplemented!()  // Placeholder
       }
   
       async fn publish_state_diff(&self, state_diff: Vec<U256>) -> Result<()> {
           unimplemented!()  // Placeholder
       }
   }

3. Implement DaClient Methods with Bitcoin-da Functionality:

   • get_mode:

     • This method should return the data availability mode of the client. If you've set it in the struct, this can be returned directly.

   • last_published_state:

     • Adapt this method to fetch the last published state from the Bitcoin network. Depending on how data is stored or marked on Bitcoin (e.g., via OP_RETURN or other mechanisms), this method should retrieve and return the relevant state.
     • Use functionalities from the Bitcoin-da crate to interact with the Bitcoin network and fetch the required data.

   • publish_state_diff:

     • This method should publish a state difference to the Bitcoin network. Depending on the size and nature of the state difference, it may need to be split and embedded across multiple Bitcoin transactions.
     • Utilize the Bitcoin-da crate's capabilities to create, sign, and broadcast the necessary Bitcoin transactions.

   • Additional Considerations:

     • Given the distinct nature of Bitcoin (e.g., UTXO model, transaction sizes), some adaptations might be necessary compared to the Ethereum implementation.

This issue is related to the net/activity and the activity/amm_front. The goal is to deploy an AMM on top of Barknet to generate activity and fill out state for benchmarking

Timing variability in curve25519-dalek's Scalar29::sub/Scalar52::sub

Timing variability of any kind is problematic when working with potentially secret values such as
elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a
problem was recently discovered in curve25519-dalek.

The Scalar29::sub (32-bit) and Scalar52::sub (64-bit) functions contained usage of a mask value
inside a loop where LLVM saw an opportunity to insert a branch instruction (jns on x86) to
conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:

• 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv
• 64-bit (see L48): https://godbolt.org/z/PczYj7Pda

A similar problem was recently discovered in the Kyber reference implementation:

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ

As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a
volatile read as an optimization barrier, which prevents the compiler from optimizing it away.

The fix can be validated in godbolt here:

• 32-bit: https://godbolt.org/z/jc9j7eb8E
• 64-bit: https://godbolt.org/z/x8d46Yfah

The problem was discovered and the solution independently verified by
Alexander Wagner <[email protected]> and Lea Themint <[email protected]> using
their DATA tool:

https://github.com/Fraunhofer-AISEC/DATA

See advisory page for additional details.

Description:

Develop a configuration structure for Bitcoin in a manner analogous to Ethereum's configuration in config.rs. This structure will facilitate the connection and interaction with a Bitcoin node.

Tasks:

1. Define Default Constants:

   • Bitcoin Node RPC Endpoint:

     • Create a constant similar to DEFAULT_ETHEREUM_NODE for Bitcoin. This will be the default RPC endpoint for a Bitcoin node.
     • Example: DEFAULT_BITCOIN_NODE: &str = "127.0.0.1:8332"; (This is a common default for Bitcoin Core's RPC server)

   • Bitcoin Network Type:

     • Define a constant specifying the default Bitcoin network type (mainnet, testnet, regtest).
     • Example: DEFAULT_BITCOIN_NETWORK: &str = "testnet";

   • Other Constants:

     • Depending on the Bitcoin-da functionalities you wish to integrate, you might need additional default constants. These could be related to fee rates, confirmation targets, etc.

2. Create BitcoinConfig Struct:

   • Fields:

     • rpc_provider: RPC endpoint for the Bitcoin node.
     • network_type: Specifies which Bitcoin network to connect to (mainnet, testnet, regtest).
     • Additional fields can be added based on specific requirements, such as wallet addresses or authentication credentials for the RPC server.

   • Deserialization:

     • Use the serde crate to enable easy deserialization from configuration files, as done in the Ethereum configuration.

   • Example Structure:

   #[derive(Clone, PartialEq, Deserialize, Debug)]
   pub struct BitcoinConfig {
       #[serde(default = "default_rpc")]
       pub rpc_provider: String,
       #[serde(default = "default_network_type")]
       pub network_type: String,
       // Add other fields as required
   }

3. Implement Default Methods for Configuration:

   • Default RPC Endpoint:

     • Create a method to provide a default RPC endpoint for Bitcoin, referencing the DEFAULT_BITCOIN_NODE constant.

   • Default Network Type:

     • Implement a method to provide a default network type, referencing the DEFAULT_BITCOIN_NETWORK constant.

   • Loading Configuration from File:

     • Adapt the try_from_file method from EthereumConfig to work for BitcoinConfig. This will allow loading of configurations from a specified file.

   • Complete Default Implementation:

     • Implement the Default trait for BitcoinConfig to provide default values for each field.

   • Example Methods:

   fn default_rpc() -> String {
       DEFAULT_BITCOIN_NODE.to_string()
   }
   
   fn default_network_type() -> String {
       DEFAULT_BITCOIN_NETWORK.to_string()
   }

Mixed issue between net/ and bitcoin-da

Right now, the wallet that has been used to test bitcoin-da functions was a local wallet created using bitcoin-cli.
We need to import a wallet.
We need a wallet for @izcrv 's testnet, one for bitcoin testnet and a last one for mainnet.

It should take inspiration on how it's done in Ethereum DA.
It will probably be a parameter in bitcoin-da Relayer and Barknet DA BitcoinClient.

rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input

If a close_notify alert is received during a handshake, complete_io
does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io
and are not affected.

rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.

See advisory page for additional details.

Should deploy a counter contract at genesis to test things

aesni has been merged into the aes crate

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:

RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

This issues aims to simulate activity for the Barknet network in order to fill the state. Please keep in mind that this one will be used for the benchmark issue, so try to make it as complete as possible

ansi_term is Unmaintained

The maintainer has advised that this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• console
• nu-ansi-term
• owo-colors
• stylish
• yansi

Dependency Specific Migration(s)

• structopt, clap2

See advisory page for additional details.

Double Public Key Signing Function Oracle Attack on ed25519-dalek

Versions of ed25519-dalek prior to v2.0 model private and public keys as
separate types which can be assembled into a Keypair, and also provide APIs
for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of
the inputs used in the deterministic computation of the S part of the signature,
but not in the R value. An adversary could somehow use the signing function as
an oracle that allows arbitrary public keys as input can obtain two signatures
for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled
private/public keypair as signing input, except as part of specially labeled
"hazmat" APIs which are clearly labeled as being dangerous if misused.

See advisory page for additional details.

This issue will contain all sub issues regarding the benchmarking of Barknet. It should contain both Barknet and Barknet inscriptions testings. Please comment below.

This issue is related to the net/activity and the activity/amm_back. The goal is to deploy an AMM on top of Barknet to generate activity and fill out state for benchmarking