Wallet openssl ed25519

[supermassive]

Resolves brave/brave-browser#42579
SecReview: https://github.com/brave/reviews/issues/1808

• Drop dependency on ed25519-dalek-bip32 and some related crates.
• Use ED25519_* functions from OpenSSL as a replacement.
• Implement SLIP-10 child key derivation scheme.
• To be done in a follow up PR: support Cardano derivation scheme(SLIP-23) based on this PR

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[github-actions]

[puLL-Merge] - brave/brave-core@26770

Here's my review of the pull request:

Description

This PR refactors the Ed25519 key derivation implementation to use the ed25519-dalek-bip32 Rust crate instead of a custom implementation. It updates the HDKeyEd25519 struct and related functions to use the new crate's functionality. The changes aim to improve the security and reliability of the Ed25519 key derivation process by leveraging a well-maintained external library.

Changes

Changes

components/brave_wallet/browser/BUILD.gn:

• Moved rust_lib dependency from deps to public_deps in hd_keyring target

components/brave_wallet/browser/internal/BUILD.gn:

• Removed hd_key_utils.cc and hd_key_utils.h from sources
• Added rust_lib to public_deps in hd_key target

components/brave_wallet/browser/internal/hd_key.cc:

• Replaced custom HMAC-SHA512 implementation with OpenSSL's HMAC function
• Updated key derivation logic to use the new Rust-based implementation

components/brave_wallet/browser/internal/hd_key_ed25519.cc and .h:

• Completely refactored to use the ed25519-dalek-bip32 Rust crate
• Updated method signatures and implementations to work with the new Rust types

components/brave_wallet/browser/solana_keyring.cc:

• Updated to work with the refactored HDKeyEd25519 implementation

components/brave_wallet/common/hash_utils.h and .cc:

• Removed HmacSha512 function

components/brave_wallet/rust/BUILD.gn:

• Added dependency on ed25519-dalek-bip32 Rust crate

components/brave_wallet/rust/lib.rs:

• Added new Rust functions to interface with ed25519-dalek-bip32 crate

sequenceDiagram
    participant Client
    participant HDKeyEd25519
    participant RustLib
    participant Ed25519DalekBip32

    Client->>HDKeyEd25519: Generate from seed
    HDKeyEd25519->>RustLib: generate_ed25519_extended_secret_key_from_seed
    RustLib->>Ed25519DalekBip32: ExtendedSigningKey::from_seed
    Ed25519DalekBip32-->>RustLib: ExtendedSigningKey
    RustLib-->>HDKeyEd25519: Ed25519DalekExtendedSecretKey
    HDKeyEd25519-->>Client: HDKeyEd25519 instance

    Client->>HDKeyEd25519: Derive child
    HDKeyEd25519->>RustLib: derive_hardened_child
    RustLib->>Ed25519DalekBip32: derive_child
    Ed25519DalekBip32-->>RustLib: ExtendedSigningKey
    RustLib-->>HDKeyEd25519: Ed25519DalekExtendedSecretKey
    HDKeyEd25519-->>Client: HDKeyEd25519 instance

    Client->>HDKeyEd25519: Sign message
    HDKeyEd25519->>RustLib: sign
    RustLib->>Ed25519DalekBip32: try_sign
    Ed25519DalekBip32-->>RustLib: Signature
    RustLib-->>HDKeyEd25519: Ed25519DalekSignature
    HDKeyEd25519-->>Client: Signature bytes

Loading

Possible Issues

1. The change from a custom implementation to an external library may introduce compatibility issues with existing code that relies on the previous behavior.
2. Performance implications of the new implementation should be carefully evaluated.

Security Hotspots

1. The key derivation process is a critical security component. While using a well-maintained library is generally good for security, any changes in this area should be thoroughly reviewed and tested.
2. The removal of the custom HMAC-SHA512 implementation in favor of OpenSSL's version should be verified to ensure it doesn't introduce any vulnerabilities.