feat: Add ed25519 support #574

speeddragon · 2025-11-27T14:13:43Z

Add support for ed25519 signing algorithm on:

ar_wallet (create, sign, and verify).
ar_bundles (L2 transactions).

Notes

Some transactions that use ed25519 might not be verified, because the GraphQL endpoint doesn't provide the anchor information required for validation. Eg: 1rTy7gQuK9lJydlKqCEhtGLp2WWG-GOrVo5JdiCmaxs

JamesPiechota · 2025-11-28T21:10:59Z

src/ar_bundles.erl

    ?assertEqual(Item1#tx.data, (maps:get(<<"key1">>, BundleItem#tx.data))#tx.data),
    ?assert(verify_item(BundleItem)).

+eddsa_cases_test() -> 


I think it might be worth adding a test which deserializes and verifies a real eddsa data item pulled from the weave. You can download the raw dataitem and stick it in the test directory and then read/deserialize/verify in a test.

Earlier in our ans104 support we had only these sort of circular tests (use HB to generate and verify dataitems) and they all passed. But as soon as we started pulling real data from the weave everything broke (e.g. due to the little- vs big- encoding issue, or due to slight discrepancies in how the specs are handled). We still have an open issue due to HB and Arweave implementing ECDSA differently and incompatibly. Adding one test on real data should help avoid many of these issues or future regressions.

Unless maybe you already have that in the hb_gateway_client test? I see that it is querying an ID - does it also verify the data?

The first test I created, it used 1rTy7gQuK9lJydlKqCEhtGLp2WWG-GOrVo5JdiCmaxs information to verify the signature, but because the anchor isn't available, I provided it manually. But decided that since I was focus on testing the verify_item, I could just create a mock transaction signed with EDDSA, and it should be the same.

The only reason I removed it was because of the anchor, but I can add it back by providing the anchor and calling verify_item.

The test on the hb_gateway_client only checks other parameters of an ED25519 transaction, but doesn't verify it.

Yep, I think this is what is being done in l2_dataitem_ed25519_test, @JamesPiechota . A sample (or a few) in the test/ directory and an associated eunit test sounds like a good idea in general, though.

@speeddragon : I don't see a hb_message:verify call on that test, I think? We should verify that a few validate correctly and that at least one form of invalid signature (ex: take a valid one, modify a bit in the body) fails.

You're right, I think I focus too much on the transaction verify function and forgot to check the support for the hb_message. I will take a look into it.

The tests on hb_gateway_client don't validate the message, so I didn't add it. There are tests under dev_message that do the validations, I will look into them.

There are tests under dev_message that do the validations, I will look into them.

The main codec tests are in the hb_message_test_vectors module. The dev_message ones are only really to verify that the calls to the codecs are hooked up correctly. Could you setup a new codec definition (with type: NEW_SIG_SCHEME?) in the test vectors, then we can just check that all of those tests pass? The suite is quite exhaustive at this point.

I've modified the dev_message:verify_test to support both wallets. I don't think modifying hb_message_test_vectors would make sense for this case.

Also added the data item of 1rTy7gQuK9lJydlKqCEhtGLp2WWG-GOrVo5JdiCmaxs which I extracted from the bundle. This has the anchor information, and we can deserialize and verify it.

samcamwilliams · 2025-11-28T21:52:11Z

src/hb_gateway_client.erl

+    ID = <<"oyo3_hCczcU7uYhfByFZ3h0ELfeMMzNacT-KpRoJK6g">>,
+    {ok, Res} = read(ID, #{}),
    ?event(gateway, {l2_dataitem, Res}),
+    CommitmentType = hb_util:deep_get([<<"commitments">>, ID, <<"type">>], Res, not_found),


Please always pass an Opts when making calls to the hb_* modules. If you don't, you can often lose validity of the data you have in-context because lazy links will be resolved against the wrong store.

samcamwilliams · 2025-11-28T21:59:46Z

src/hb_gateway_client.erl

 l2_dataitem_test() ->
    _Node = hb_http_server:start_node(#{}),
-    {ok, Res} = read(<<"oyo3_hCczcU7uYhfByFZ3h0ELfeMMzNacT-KpRoJK6g">>, #{}),
+    ID = <<"oyo3_hCczcU7uYhfByFZ3h0ELfeMMzNacT-KpRoJK6g">>,


Why unwrap this?

I added a test to validate commitment type in l2_dataitem_ed25519_test. Since I didn't find any test with the RSA key, I've also added this check on one of the other tests. Since I need the ID to access to the value inside the message, I decided to extract the binary to a variable to only write the ID value once.

{ok, Res} = read(ID = <<"oyo3_hCczcU7uYhfByFZ3h0ELfeMMzNacT-KpRoJK6g">>, #{}), is the general way we do things like this, if the lines don't become unwieldy.

src/ar_bundles.erl

JamesPiechota · 2025-12-02T13:32:33Z

src/ar_wallet.erl


+to_eddsa_address(PubKey) ->
+    Hash = crypto:hash(sha256, PubKey),
+    base64:encode(Hash, #{padding => false, mode => urlsafe}).


I just noticed that we don't encode the RSA address, but it looks like we do encode EDDSA and maybe ECDSA? Any idea if this is intentional? I could see the ambiguity creating problems downstream

The right way is without the encode. Most of the cases when ar_wallet:to_address is used are followed by hb_util:human_id, which calls b64fast:encode. I will fix it, thanks!

EDIT: Regarding ECDSA, I will not change anything for now. I would need to investigate this further, and there are high-priority tasks I need to attend to.

JamesPiechota · 2025-12-02T13:36:28Z

src/ar_wallet.erl

        }
    );
+sign({KeyType = {KeyAlg, Curve}, Priv, _Pub}, Data, _DigestType) when KeyType =:= {?EDDSA_SIGN_ALG, ed25519} ->
+    crypto:sign(KeyAlg, none, Data, [Priv, Curve]);


I'm not super familiar with crypto:sign, do you know why we aren't passing DigestType into crypto:sign?

Great question. ed25519 digest the message in its raw form. Providing none or sha256 doesn't affect the output.

From Google AI:

EdDSA uses two main digest types: PureEdDSA and HashEdDSA. PureEdDSA signs the message directly without a prior hash, while HashEdDSA first hashes the message using a collision-resistant hash function (like SHA-512).

HashEdDSA can be ed25519ph.

Co-authored-by: JamesPiechota <piechota@gmail.com>

speeddragon mentioned this pull request Nov 28, 2025

fix: Do not crash on unsuported signature types #571

Closed

speeddragon marked this pull request as ready for review November 28, 2025 20:22

JamesPiechota reviewed Nov 28, 2025

View reviewed changes

samcamwilliams reviewed Nov 28, 2025

View reviewed changes

speeddragon changed the title ~~Add ed25519 support~~ feat: Add ed25519 support Dec 2, 2025

JamesPiechota reviewed Dec 2, 2025

View reviewed changes

src/ar_bundles.erl Show resolved Hide resolved

JamesPiechota reviewed Dec 2, 2025

View reviewed changes

speeddragon and others added 17 commits December 17, 2025 10:33

wip: Add ed25519 signature validation

de0a197

fix: Remove solana and injected_aptos

12059a2

fix: Add sign capability, add test to data item

cadd5db

fix: ed25519 sign and verify

3240eed

test: Remove test

0021a2b

test: Add test where some fields are removed

c7e20bd

test: Remove check for unsuported 64 bytes signature

ef92568

fix: Improvements

8423d54

fix: Cleanup

85b8a43

fix: Ignore digest type on ed25519

13a1556

impr: Add test to committer value for ed25519

b3f0235

fix: Add opts to deep_get call

e91e62a

fix: Add test to verify message with ed25519

8b022c2

test: Improve test code style

09789a0

test: Add ed25519 real data item

acd918b

Update src/ar_bundles.erl

d118eaa

Co-authored-by: JamesPiechota <piechota@gmail.com>

fix: Test and address encoding

21936fc

speeddragon force-pushed the verify_ed25519_messages branch from 3d08950 to 21936fc Compare December 17, 2025 10:35

feat: Add ed25519 support #574

Are you sure you want to change the base?

feat: Add ed25519 support #574

Conversation

speeddragon commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Notes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

speeddragon Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

speeddragon commented Nov 27, 2025 •

edited

Loading

speeddragon Dec 2, 2025 •

edited

Loading