Private payments for mobile devices.

Related tags

Cryptography fog
Overview

MobileCoin Fog

This is the README file for MobileCoin Fog.

Note to Developers

  • MobileCoin Fog is a prototype. Expect substantial changes before and after the release.
  • Please see CONTRIBUTING.md for notes on contributing bug reports and code.

MobileCoin Fog

MobileCoin Fog is a privacy-preserving service designed to support use of the MobileCoin Payments Network on mobile devices.

Table of Contents

License

MobileCoin Fog is available under open-source licenses. Look for the LICENSE file in each crate for more information.

Cryptography Notice

This distribution includes cryptographic software. Your country may have restrictions on the use of encryption software. Please check your country's laws before downloading or using this software.

Repository Structure

Directory Description
fog Privacy-preserving services to support MobileCoin payments on mobile devices.
android-bindings Bindings for android clients.
libmobilecoin Library for use in SDKs to interact with MobileCoin payment primitives.
util Miscellaneous utilities.

Selected Binaries

Target Description
fog-ingest-server Obliviously post-processes the blockchain to organize transaction outputs according to fog hints.
fog-ledger-server Obliviously serves ledger materials such as rings, merkle proofs, and key images, used to verify whether a Txo was spent, or to construct new transactions.
fog-report-server Provides the ingest enclave's Attestation Verification Report for transaction construction.
fog-view-server Obliviously serves the post-processed Txos to clients who wish to check their balance and construct new transactions.

Build Instructions

The workspace can be built with cargo build and tested with cargo test. Either command will recognize the cargo --release flag to build with optimizations.

Some crates (e.g. fog-ingest-service) depend on Intel SGX, which adds additional build and runtime requirements. For detailed information about setting up a build environment, how enclaves are built, and on configuring the build, see BUILD.md.

For a quick start, you can build in the same docker image that we use for CI by using the mob tool. Note that this requires you to install Docker. You can use the mob tool with the following commands:

# From the root of the cloned repository
./mob prompt

# At the resulting docker container prompt
cargo build

Test Instructions

To run the unittest tests locally, you need to start a local postgres instance, then run the tests. You can do this at the mob prompt:

# From the root of the cloned repository
./mob prompt

# Start postgres
service postgresql start

# Run the tests
cargo test

Overview

MobileCoin Fog is a suite of microservices designed to enable MobileCoin payments on mobile devices.

For MobileCoin payments to be practical, we cannot require the mobile device to sync the ledger or download the entire blockchain. However, a so-called "thin wallet" won't work either, because the types of queries made by a thin wallet generally reveal to the server the user's balance, when they got paid, etc. In typical thin wallet designs, the server is trusted by the user.

MobileCoin has been engineered to eliminate this sort of trust in the service is "oblivious" to the nature of the user requests, and the service operator is unable to harvest the users' data in exchange for running the service.

Because of this, off-the-shelf solutions to wallet services simply don't work. In many cases, if we naively make a database query to handle a query that a wallet would make if it had access to the ledger, it reveals significant information about e.g. whether Bob was paid or not in the last block, which payments Bob received, whether Alice paid Bob, etc., any of which would not meet our privacy goals.

Instead, Fog makes heavy use of SGX enclaves and Oblivious RAM data structures to serve such queries privately and without compromising scalability. Although such use of SGX may create potential operational challenges, the MobileCoin system has been carefully designed to navigate these challenges.

Architecture

Fog works by post-processing the blockchain in an SGX-mediated way. Records are written to a database (the "recovery database") which contains the entirety of information that a user needs to recover all of their transactions privately.

Fog consists of four services:

  • The "fog-ingest" service consumes and post-processes the blockchain, writing records to the recovery database. This is an SGX service. It additionally publishes a public key to the "fog-report" service.

  • The "fog-view" service provides an API for fog users to access this database. Some of the queries that the user needs to make to the database are sensitive. To protect them, this is an SGX service and some of the queries are resolved obliviously.

  • The "fog-ledger" service provides several APIs for fog users to make queries against the MobileCoin ledger. Some of the queries that the user needs to make are sensitive; SGX also provides this service, and some of the queries are resolved obliviously.

  • The "fog-report" service. The fog report service publishes a signed fog public key which comes from the fog-ingest SGX enclave. This public key must be available to anyone who wants to send MobileCoin to a fog user, so the fog report service is expected to be publicly accessible and require no authentication (the way the others probably would). In addition to the Intel report, there is an X509 certificate chain signing the report as well. The "fog-report" service is not an SGX service.

FAQ

  1. Is Fog decentralized?

    Fog is a scalable service that helps users find their transactions, conduct balance checks, and build new transactions. Fog does so without requiring a local copy of the blockchain and without revealing a user's activities or giving away their private keys.

    Fog is intended to be run by app providers to provide their users with a private and positive mobile experience. Users need only trust the integrity of SGX, and not the service provider, for their privacy.

    Fog is thus not a single, decentralized network, but can be deployed as needed by each party willing to offer this service. Fog can be treated as critical infrastructure for an app, and can be scaled to meet each party's needs.

  2. What is the hint field? Can I put anything in there?

    The purpose of the hint field is to send an encrypted message to a fog enclave associated to the transaction, which it finds when it post-processes the blockchain. A conforming client puts only an mc-crypto-box ciphertext of a specific size there. For non-fog transactions, a ciphertext encrypted for a random public key should be put there. Putting something in the hint field which is distinguishable from this may degrade privacy.

Support

For troubleshooting help and other questions, please visit our community forum.

You may also open a technical support ticket via email.

Trademarks

Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries. MobileCoin is a registered trademark of MobileCoin Inc.

Comments
  • Fog 393 view server fixes

    Fog 393 view server fixes

    This is supposed to make it so that view server does not get stuck on blocks that fog never promised to scan.

    The main change is in the fog-view block tracker. To support the new idea, we make it not use ingestable ranges, but track ingress keys directly, and load blocks from database based on ingress key rather than ingest invocation id.

    There are a couple additional places we try to unwind assumptions it was making like, every block leads to at least one ETxOutRecord, which isn't strictly speaking true. There is a code path in ingest enclave where a non-conforming client can send data that leads to no ETxOutRecord being produced, if the plaintext of encrypted fog hint isn't a valid ristretto.

    Because it changes the DB API, a lot of unit tests need to be fixed up after this change. A bunch more need to be added for the new behavior as well.

    opened by cbeck88 17
  • update fog and fog clients for encrypted memo changes: recoverable transaction history

    update fog and fog clients for encrypted memo changes: recoverable transaction history

    This makes fog ingest include the encrypted memo in the TxOutRecord object. It then passes through fog view as usual. We also update the FogTxOut object to parse the memo out of the view response.

    fog sample paykit is updated to both produce memos on new transactions, and parse memos from incoming transactions, and remember the last one or an error.

    This uprevs mobilecoin submodule, and makes the android bindings and libmobilecoin able to build.

    It installs a RTHMemoBuilder when those bindings create transaction builder, but it does not configure the RTHMemoBuilder, because we probably need to extend the bindings to do that properly.

    It also gets all the tests passing

    Still TODO:

    • [x] Make sample paykit actually read the memos and expose this info in some basic way
    • [x] Make fog test client confirm that the memos are working (if A sends to B then B got the right memo and so did A)
    opened by cbeck88 9
  • fix FOG-180: enclave report cache updated too frequently

    fix FOG-180: enclave report cache updated too frequently

    this commit attempts to make it so that ingest server updates the enclave report cache only when necessary

    This is: (1) At least once before anything happens (2) Whenever the ingress key has changed (3) Whenever we notice that the report doesn't match the key we think we are publishing to the database.

    Additionally, a background thread is created that updates it at least as frequently as consensus (18 hours)

    Before this commit, we update it at least once per block.

    There are some questions about whether DNS failures with looking for IAS were causing instability in the service. This commit doesn't speak directly to that, but it can't hurt to hit up IAS less often than we were doing.

    opened by cbeck88 7
  • fog-report-cli improvements

    fog-report-cli improvements

    This makes a second "mode" for fog-report-cli where it doesn't do any validation of the fog report response and just parses the data of interest out of it -- that is, the hex bytes of the fog ingress pubkey, and its pubkey expiry value.

    This is useful because sometimes, when the system gets stuck, the users report "tombstone block exceeded" and it can be traced back to the pubkey expiry value in the fog report server.

    It's also useful because it lets us quickly see the most recent fog ingress pubkey that has been published. If the active server dies, knowing the hex bytes of this key may help you figure out which backup to restart, if they have different keys.

    Some pitfalls with this workflow, before this commit:

    (1) You had to make a pubkey file which has all the right data, which requires going to another repo, building, and running a tool to generate keys, and then getting the artifacts to this repo and pointing this program at the keyfiles, which is cumbersome. In the new revision, you can specify fog url and SPKI as command-line args and skip the keyfile stuff. (2) If you don't download all the correct measurements and SPKI's for the network, and use that SPKI when you generate sample keys, the attestation check or the fog signature check will fail and it takes some time to work through this. If you are just trying to diagnose why a network is stopped, this is kind of a time suck. In the new revision, if there is no public address file and no spki provided, (only fog url), then we skip the normal validation pathway, and use the mc-attest-core types to parse the verification report (without validating it) and get the data of interest, without any possibility of failure due to IAS, attestation, certificate chains, and so on.

    Ideally, there would be some kind of dashboard that can provide this and other information without relying on a cli, but this is a decent starting point, and may help us diagnose problems later.

    opened by cbeck88 4
  • Uprev mobilecoin to latest master

    Uprev mobilecoin to latest master

    Motivation

    This brings forward the latest changes from the mobilecoin repository, including updates to aes-gcm, grpc, and mbedtls.

    In this PR

    • Uprev mobilecoin submodule
    • Remove aes-gcm cargo.io patch
    • Update sha2
    • Add patch for cpufeatures + feature-selection usage to enclaves
    opened by jcape 3
  • FOG-408: Make ingest peer uri filtering based on responder id

    FOG-408: Make ingest peer uri filtering based on responder id

    This fixes a bug that exists today in fog ingest deployments. I thought this was only a minor issue because, it would wrongly add the peer listen uri to the list of peer uris, but then filter it out and not connect to it. But because the active server replicates its peer list onto the backups continuously, they will all end up with this uri in their list, and there is no configuration that will fix this. Additionally, a server won't be able to filter out it's own (real) URI that the peers have in their lists, because it doesn't filter by responder id before this commit.

    opened by cbeck88 3
  • Fog postgres retries ii (#1352) (backport to nascent release-1.1.3 branch)

    Fog postgres retries ii (#1352) (backport to nascent release-1.1.3 branch)

    • This adds configurable retries to postgres operations

    Retries are added at the level of the SqlRecoveryDb object.

    We also adjust some retry logic for fog ingest controller

    • Redevelop previous per Eran's comment, to more systematically retry

    This adds the retries at the level of the SqlRecoveryDb object to systematically apply retries to all postgres operations.

    • fixup missing "should_retry()" calls

    • fix clippy

    This repository is no longer used, please rebase your PR against https://github.com/mobilecoinfoundation/mobilecoin.git.

    Thanks!

    opened by cbeck88 2
  • Update TERMS-OF-USE.md

    Update TERMS-OF-USE.md

    Soundtrack of this PR: Pump it Up - Network(1984)

    Motivation

    < The motivation for the changes in this PR. "Currently we...", "This is needed because..." >

    In this PR

    • < Additions, removals, fixes, features >

    < Ticket status, e.g. "fixes #issue number" >

    Future Work

    • < Out of scope non-goals for this PR >
    • < These should be links to tickets. If the tickets do not exist, make them. >
    opened by the-real-adammork 2
  • initial change to consolidate get watcher timestamp

    initial change to consolidate get watcher timestamp

    Soundtrack of this PR: link to song that really fits the mood of this PR

    Motivation

    Currently the watcher database provides an API for getting block signatures and from there we can get timestamps for a block. However, sometimes the watcher fails or gets stuck. Both fog ingest and fog ledger have code for handling these errors and retries. Because the clients need a timestamp on every piece of data in order to function, failing to get a timestamp blocks the service, and immediately escalates to a P0 issue. We now have the code for getting the timestamps from the watcher in two places — in the fog-ingest worker thread and in the fog ledger worker thread, and specifically a function "get_watcher_timestamp" .https://github.com/mobilecoinfoundation/fog/blob/5a776bd027e1e2cc5f4717f4d4f8f56f30ae0585/fog/ingest/server/src/worker.rs#L151 that is duplicated in both places.

    In this PR

    It would be better to have a crate like "fog-timestamps" to provides this function, and reconcile any differences between the two versions, and test this. So that we know it works the same way everywhere, and this will make it easier to debug if fog gets blocked on this in production (which has happened before, and will happen again).

    < Ticket status, e.g. "fixes #issue number" > https://app.asana.com/0/1200353042931237/1200688378834228/f

    Future Work

    • < Out of scope non-goals for this PR >
    • < These should be links to tickets. If the tickets do not exist, make them. >
    opened by tubi70 2
  • Bump mobilecoin from `631b144` to `2940fa4`

    Bump mobilecoin from `631b144` to `2940fa4`

    Bumps mobilecoin from 631b144 to 2940fa4.

    Commits

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies submodules 
    opened by dependabot[bot] 2
  • fog omits compressed commitment from TxOutRecord

    fog omits compressed commitment from TxOutRecord

    This updates TxOutRecord in a few ways:

    • amount_compressed_commitment_data is now optional, and omitted except for backwards compat. (If backwards compat is not needed, then that field could be deleted entirely.)
    • amount_compressed_commitment_data_crc32 is now present when that field is omitted. This is an IEEE crc32 of the omitted data.
    • The sample paykit is updated so that it attempts to reconstruct the compressed commitment using the view private key. (This was koe's idea.) Then it checks the crc32 to confirm correct recomputation. This saves ~30 bytes in fog view, which we can use for the memo.
    • A method is added to construct TxOutRecord more nicely, and then a bunch of test code and the enclave code is simplified.
    opened by cbeck88 2
  • Reduce an error level (1.1.2 branch)

    Reduce an error level (1.1.2 branch)

    Sometimes, we lose connection to the sql DB, and the report server write operation fails.

    This should not be logged as an error because it's not actionable and errors get converted to sentry alerts.

    opened by cbeck88 0
Releases(v1.1.3)

  • v1.1.3(Feb 15, 2022)

    This is a maintenance (non-enclave) release of Fog only.

    What's New and Different

    :construction_worker: Postgres retries

    This includes a patch to make our software automatically retry postgres connections and operations a few times if there are retriable connectivity issues.

    :construction_worker_woman: Configurable Oram size

    This includes a patch to replace a hard-coded constant in the untrusted side of fog view with a configurable parameter for the ORAM capacity of the server. This is necessary because the size of the blockchain is approaching the limit we launched with initially.

    Release Schedule and Advice

    We pushed this to testnet on 02-11-2021. We plan to push this to mainnet on 02-15-2021.

    Fog SGX Measurements

    The mainnet release of fog will produce the following enclave measurements:

    • Consensus:
      • MRENCLAVE: 0x65 0x32 0x28 0xaf 0xd2 0xb0 0x2a 0x6c 0x28 0xf1 0xdc 0x3b 0x10 0x8b 0x1d 0xfa 0x45 0x7d 0x17 0x0b 0x32 0xae 0x8e 0xc2 0x97 0x8f 0x94 0x1b 0xd1 0x65 0x5c 0x83
    • Ingest:
      • MRENCLAVE: 0xf3 0xf7 0xe9 0xa6 0x74 0xc5 0x5f 0xb2 0xaf 0x54 0x35 0x13 0x52 0x7b 0x6a 0x78 0x72 0xde 0x30 0x5b 0xac 0x17 0x17 0x83 0xf6 0x71 0x6a 0x0b 0xf6 0x91 0x94 0x99
    • Ledger:
      • MRENCLAVE: 0x89 0xdb 0x0d 0x16 0x84 0xfc 0xc9 0x82 0x58 0x29 0x5c 0x39 0xf4 0xab 0x68 0xf7 0xde 0x59 0x17 0xef 0x30 0xf0 0x00 0x4d 0x9a 0x86 0xf2 0x99 0x30 0xce 0xbb 0xbd
    • View:
      • MRENCLAVE: 0xdd 0x84 0xab 0xda 0x7f 0x05 0x11 0x6e 0x21 0xfc 0xd1 0xee 0x63 0x61 0xb0 0xec 0x29 0x44 0x5f 0xff 0x04 0x72 0x13 0x1e 0xaf 0x37 0xbf 0x06 0x25 0x5b 0x56 0x7a

    The testnet release of fog will produce the following enclave measurements:

    • Consensus:
      • MRSIGNER: 0xbf 0x7f 0xa9 0x57 0xa6 0xa9 0x4a 0xcb 0x58 0x88 0x51 0xbc 0x87 0x67 0xe0 0xca 0x57 0x70 0x6c 0x79 0xf4 0xfc 0x2a 0xa6 0xbc 0xb9 0x93 0x01 0x2c 0x3c 0x38 0x6c
      • MRENCLAVE: 0x96 0x59 0xea 0x73 0x82 0x75 0xb3 0x99 0x9b 0xf1 0x70 0x03 0x98 0xb6 0x02 0x81 0xbe 0x03 0xaf 0x5c 0xb3 0x99 0x73 0x8a 0x89 0xb4 0x9e 0xa2 0x49 0x65 0x95 0xaf
    • Ingest:
      • MRSIGNER: 0xbf 0x7f 0xa9 0x57 0xa6 0xa9 0x4a 0xcb 0x58 0x88 0x51 0xbc 0x87 0x67 0xe0 0xca 0x57 0x70 0x6c 0x79 0xf4 0xfc 0x2a 0xa6 0xbc 0xb9 0x93 0x01 0x2c 0x3c 0x38 0x6c
      • MRENCLAVE: 0xa4 0x76 0x43 0x46 0xf9 0x19 0x79 0xb4 0x90 0x6d 0x4c 0xe2 0x61 0x02 0x22 0x8e 0xfe 0x3a 0xba 0x39 0x21 0x6d 0xec 0x1e 0x7d 0x22 0xe6 0xb0 0x6f 0x91 0x9f 0x11
    • Ledger:
      • MRSIGNER: 0xbf 0x7f 0xa9 0x57 0xa6 0xa9 0x4a 0xcb 0x58 0x88 0x51 0xbc 0x87 0x67 0xe0 0xca 0x57 0x70 0x6c 0x79 0xf4 0xfc 0x2a 0xa6 0xbc 0xb9 0x93 0x01 0x2c 0x3c 0x38 0x6c
      • MRENCLAVE: 0x76 0x8f 0x7b 0xea 0x61 0x71 0xfb 0x83 0xd7 0x75 0xee 0x84 0x85 0xe4 0xb5 0xfc 0xeb 0xf5 0xf6 0x64 0xca 0x7e 0x8b 0x9c 0xee 0xf9 0xc7 0xc2 0x1e 0x9d 0x9b 0xf3
    • View:
      • MRSIGNER: 0xbf 0x7f 0xa9 0x57 0xa6 0xa9 0x4a 0xcb 0x58 0x88 0x51 0xbc 0x87 0x67 0xe0 0xca 0x57 0x70 0x6c 0x79 0xf4 0xfc 0x2a 0xa6 0xbc 0xb9 0x93 0x01 0x2c 0x3c 0x38 0x6c
      • MRENCLAVE: 0xe1 0x54 0xf1 0x08 0xc7 0x75 0x8b 0x5a 0xa7 0x16 0x1c 0x38 0x24 0xc1 0x76 0xf0 0xc2 0x0f 0x63 0x01 0x24 0x63 0xbf 0x3c 0xc5 0x65 0x1e 0x67 0x8f 0x02 0xfb 0x9e

    Independent clients which depend on those values (e.g. those doing MRENCLAVE in particular) should add the values included to their trust story (and accept Intel Attestation Verification Reports [AVRs] with SOFTWARE_HARDENING_NEEDED for INTEL-SA-00334, as those enclaves were built with the relevant hardening).

    The measurements of all enclaves are exactly the same as v1.1.0 release.

    Source code(tar.gz)
    Source code(zip)

  • v1.1.2(Dec 16, 2021)

    This is a maintenance (non-enclave) release of Fog only.

    What's New and Different

    :construction_worker: Better defaults and configuration for postgres connections

    We exposed many diesel parameters, which influence postgres connection timeouts, as environment variables and gave them better defaults. This may help us to make better connections to postgres.

    :construction_worker_woman: Adjustments to logging

    • Less logging around things that are not actionable (PERMISSION_DENIED)
    • More logging around different activities in fog ingest that help us debug it

    Release Schedule and Advice

    We are (tentatively) pushing out a release to the fog deployments tomorrow (Jan 21 2022). Consensus will not be touched and users should see no disruption.

    (We pushed this to testnet on Nov 19 2021)

    The measurements of all enclaves are exactly the same as v1.1.0 release.

    Source code(tar.gz)
    Source code(zip)

  • v1.1.2-pre1(Dec 14, 2021)

    This release contains fixes for:

    • Postgres connection settings not configurable
    • Insufficient info-level logging in fog ingest
    • Too much logging around permission denied / attestation errors that aren't actionable
    Source code(tar.gz)
    Source code(zip)

  • v1.1.2-pre0(Dec 14, 2021)

  • v1.1.1(Nov 19, 2021)

    This is the first bug fix release to Fog since it was publicly launched.

    What's New and Different

    :construction_worker: Bug fix for Fog-View error codes.

    Fixed a bug where Fog-view would return INTERNAL_ERROR instead of PERMISSION_DENIED when attestation fails. This will cause clients not to re-attest appropriately when attestation fails.

    :construction_worker_woman: Adjustments to logging

    We stopped logging PERMISSION_DENIED as this is not actionable, and we increases logging for the fog ingest worker loop to help debug when it is stuck

    Release Schedule and Advice

    We are may push out this release to the fog deployments tomorrow (Jan 21 2022). But there is also the possibility that it will be delayed. Consensus will not be touched and users should see no disruption.

    The measurements of all enclaves are exactly the same as v1.1.0 release.

    Source code(tar.gz)
    Source code(zip)

  • v1.1.1-testnet(Nov 17, 2021)

  • v1.1.1-pre0(Nov 10, 2021)

    This contains fixes for:

    • Fog view was not returning "PermissionDenied" rpc errors for attestation errors
    • Fog ingest was updating the report cache much more often than necessary
    Source code(tar.gz)
    Source code(zip)

  • v1.1.0(Jun 10, 2021)

    Hey all, this is the first incremental release of MobileCoin since launch of mainnet.

    What's New and Different

    :sparkles: Sticky Sessions for gRPC Clients

    We now support cookie-based load balancing at the gRPC layer when connecting to fog enclaves.

    :construction_worker: Newer Rust (nightly-2021-03-25)

    We've updated our supported rust version to one released after stable-0.51.0.

    :lock: :arrow_up: SGX 2.13.3

    We've updated the version of the SGX SDK we're using to 2.13.3, to address INTEL-SA-00477, which is a timing attack vulnerability in some Intel crypto code.

    Release Schedule and Advice

    We are pushing out a release today, and will be coordinating with network operators to deploy the new version of Consensus network and Fog servers (enclaves) on or before July 14, 2021 (exact date TBD).

    A more detailed changelog is also available.

    Fog SGX Measurements

    The production release of fog will produce the following enclave measurements:

    • Ingest:
      • MRSIGNER: 0x2c1a561c4ab64cbc04bfa445cdf7bed9b2ad6f6b04d38d3137f3622b29fdb30e
      • MRENCLAVE: 0xf3f7e9a674c55fb2af543513527b6a7872de305bac171783f6716a0bf6919499
    • Ledger:
      • MRSIGNER: 0x2c1a561c4ab64cbc04bfa445cdf7bed9b2ad6f6b04d38d3137f3622b29fdb30e
      • MRENCLAVE: 0x89db0d1684fcc98258295c39f4ab68f7de5917ef30f0004d9a86f29930cebbbd
    • View:
      • MRSIGNER: 0x2c1a561c4ab64cbc04bfa445cdf7bed9b2ad6f6b04d38d3137f3622b29fdb30e
      • MRENCLAVE: 0xdd84abda7f05116e21fcd1ee6361b0ec29445fff0472131eaf37bf06255b567a

    Independent clients which depend on those values (e.g. those doing MRENCLAVE in particular) should add the values included to their trust story (and accept Intel Attestation Verification Reports [AVRs] with SOFTWARE_HARDENING_NEEDED for INTEL-SA-00334, as those enclaves were built with the relevant hardening).

    Source code(tar.gz)
    Source code(zip)

  • v1.1.0-pre4(May 13, 2021)

  • 1.1.0-pre3(May 12, 2021)

  • v1.1.0-pre2(May 11, 2021)

  • v1.0.0(Apr 5, 2021)

  • v1.0.1-pre4(Apr 1, 2021)

    🐛 Bug Fixes

    • Fix setting hardening_advisory

    ✨ Features

    • BIP-39 mnemonics in android bindings
    • Restore BIP-39 entropy conversion in libmobilecoin
    Source code(tar.gz)
    Source code(zip)

  • v1.0.1-pre3(Mar 31, 2021)

    ✨ Features

    • Adds SLIP-10 account key generation in libmobilecoin

    💥 Breaking Changes

    • Removes previous entropy derivation for account keys from libmobilecoin
    Source code(tar.gz)
    Source code(zip)

  • v1.0.1-pre2(Mar 25, 2021)

  • v1.0.1-pre1(Mar 15, 2021)

  • v1.0.0-pre1(Mar 11, 2021)

Owner
MobileCoin Foundation
MobileCoin Foundation
GitHub
The Mullvad VPN client app for desktop and mobile

Mullvad VPN desktop and mobile app Welcome to the Mullvad VPN client app. This repository contains all the source code for the desktop and mobile vers

Mullvad VPN 3k Jan 2, 2023
RGB smart contracts: client-facing library & command-line for desktop and mobile

RGB smart contracts RGB is confidential & scalable client-validated smart contracts for Bitcoin & Lightning. It embraces the concepts of private & mut

RGB: scalable & private smart contracts for bitcoin & lightning 4 Mar 15, 2023
Radix Babylon vanity address finder allowing easy import into Radix mobile Wallet.

Rad Vanity address finder for Radix Babylon which you can import directly into your Radix Wallet using QR scanner using Import from a Legacy Wallet fe

Alexander Cyon 6 Nov 13, 2023
An extensible open-source framework for creating private/permissioned blockchain applications

Exonum Status: Project info: Community: Exonum is an extensible open-source framework for creating blockchain applications. Exonum can be used to crea

Exonum 1.2k Jan 1, 2023
✈️A private, authenticated, permissioned cargo registry

chartered a little dig at creating a private cargo repository with authenticated downloads, the plan is to have git connect to a git server we setup t

Jordan Doyle 121 Dec 26, 2022
Convert private keys to PKCS#8 format in pure Rust

topk8 Convert private keys to PKCS#8 format in pure Rust. The following formats are supported at the moment: PKCS#1 PEM (RSA PRIVATE KEY) SEC1 PEM (EC

kazk 1 Dec 10, 2021
Add Rust on private-isu

private-isu Rust実装 private-isuにRust実装を追加するためのリポジトリです． 現状，Docker Composeのみ対応しています． Using Rustで起動するためには以下の手順が必要です． private-isuのwebappに本リポジトリを追加する． cd pr

Romira 3 Jun 22, 2022
Rust implementation of Namada, a sovereign proof-of-stake blockchain that enables asset-agnostic private transfers

Namada Overview Namada is a sovereign proof-of-stake blockchain, using Tendermint BFT consensus, that enables multi-asset private transfers for any na

anoma 144 Jan 2, 2023
Kryptokrona SDK in Rust for building decentralized private communication and payment systems.

Kryptokrona Rust SDK Kryptokrona is a decentralized blockchain from the Nordic based on CryptoNote, which forms the basis for Monero, among others. Cr

null 5 May 25, 2023
a Solana program for granting friends permissions on your account without revealing your private key.

Delegatooooor Granting Permission: An account holder (the delegator) decides to grant permission to a delegate. They create and sign a transaction tha

0xGhostMac 3 Apr 3, 2024
Private key finder based on the (Bitcoin) secp256k1 elliptic curve.

keyripper keyripper is a powerful tool developed in Rust to assist in the recovery of Bitcoin private keys by leveraging the Baby-Step Giant-Step (BSG

Denzy 12 Sep 27, 2024
Scrub dm-integrity devices

Synopsis This tool attempts to read all logical sectors of a block device, overwriting any sector that cannot be read due to an I/O error with zeros.

Mikael 1 Feb 26, 2022
Left To My Own Devices - NT hash tools

ntcrack Left To My Own Devices - NT cracker A full writeup of how it works is available at the SensePost blog Invocation ./ntcrack <input hashlist> <w

SensePost 24 Nov 24, 2022
Bitcoin PSBT signer, descriptor exporter and more for offline devices.

KeeChain Description KeeChain is a Bitcoin application to transform your offline computer in an AirGap Signing Device (aka Hardware Wallet). Getting s

Yuki Kishimoto 3 Dec 15, 2022
Narrowlink securely connects devices and services together, even when both nodes are behind separate NAT

Narrowlink Narrowlink is a self-hosted platform that allows you to establish secure remote connections between devices within a network that may be hi

Narrowlink 355 Aug 17, 2023
Private payments for mobile devices.

Testing your first payment Please see TESTNET.md for instructions on participating in the TestNet! Sending your first payment Please see MAINNET.md fo

MobileCoin Foundation 1.1k Dec 30, 2022
Payments Engine is a simple toy payments engine

Payments Engine is a simple toy payments engine that reads a series of transactions from a CSV, updates client accounts, handles disputes and chargebacks, and then outputs the state of clients accounts as a CSV.

Bogdan Arabadzhi 0 Feb 3, 2022
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

null 294 Dec 23, 2022
Private swaps for Secret Network using a private entropy pool & differential privacy.

WIP SecretSwap: Anon Edition Private swaps for Secret Network! Uses private entropy pool for differential privacy when reporting pools sizes. Swap amo

Enigma 5 Apr 5, 2022
Private swaps for Secret Network using a private entropy pool & differential privacy.

WIP SecretSwap: Anon Edition Private swaps for Secret Network! Uses private entropy pool for differential privacy when reporting pools sizes. Swap amo

SCRT Labs 5 Apr 5, 2022