Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Implement Ed25519 to Curve25519 #54

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

f-person
Copy link

@f-person f-person force-pushed the feat/ed25519-to-curve25519 branch from 518d8ad to f719d16 Compare June 30, 2023 22:55
@Skycoder42
Copy link
Owner

Thank you for the PR. I will try to review it within the next few days!

@Skycoder42 Skycoder42 self-requested a review July 4, 2023 05:37
@Skycoder42 Skycoder42 self-assigned this Jul 4, 2023
@Skycoder42 Skycoder42 added the enhancement New feature or request label Jul 4, 2023
@f-person
Copy link
Author

f-person commented Jul 4, 2023

The tests are mostly copied from other methods in SignSumo and modified to fit. I wonder if it would be better to refactor them in a way to share the code or if it's fine the way it is :)

Copy link
Owner

@Skycoder42 Skycoder42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi. I finally found the time to take a look at your changes. Looks mostly fine, except that the crypto_sign_ed25519_sk_to_curve25519 converts a secret key to another secret key, which means the API should return a SecureKey instead of an Uint8List. Please take a look at my comments and fix the corresponding code.

Regarding the refactoring: Most of the code in this library looks very much alike, but with minor differences. For now, it is fine the way it is, as complex operations (like pointer management) have been extracted into their own classes and only the operations themselves remain. I personally would not extract the public key allocation, as it only moves the line somewhere else and at least in my opinion does not improve readability.

I am thinking about automating the code generation for the APIs on some abstract level, as that would streamline the implementations and allow me to easier implement the advanced APIs. However, as my time is limited, that is nothing I will investigate deeper in the near future.

Also, could you please rebase the PR? I think that should fix up the CI, so the pipeline can actually validate the PR is functionally correct ;)

/// Provides crypto_sign_ed25519_sk_to_curve25519.
///
/// See https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519
Uint8List skToCurve25519(SecureKey secretKey);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this method converts a secret key to a secret key, it should return SecureKey as well

@@ -46,8 +47,7 @@ class SignSumoFFI extends SignFFI implements SignSumo {
Uint8List skToPk(SecureKey secretKey) {
validateSecretKey(secretKey);

final publicKey =
SodiumPointer<UnsignedChar>.alloc(sodium, count: publicKeyBytes);
final publicKey = _allocatePublicKey();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think extracting a method for this one-liner is needed, as it does not increase readability here.

SodiumException.checkSucceededInt(result);

return Uint8List.fromList(curve25519PublicKey.asListView());
} finally {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not work properly. If _allocatePublicKey throws, then ed25519PublicKey will never be disposed. Instead, you should build this up similar to https://github.com/Skycoder42/libsodium_dart_bindings/blob/main/packages/sodium/lib/src/ffi/api/sign_ffi.dart#L105


return Uint8List.fromList(publicKey.asListView());
} finally {
publicKey.dispose();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is fine here, as here there is only a single pointer to be disposed

Uint8List skToCurve25519(SecureKey secretKey) {
validateSecretKey(secretKey);

final publicKey = _allocatePublicKey();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As commented in the api file, this should be a SecureKeyFFI, not a Uint8List

Uint8List skToCurve25519(SecureKey secretKey) {
validateSecretKey(secretKey);

return jsErrorWrap(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, return a SecretKeyJS here

]);
});

test('returns the public key of the secret key', () {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... returns the Curve25519 secret key of the ...

);
});

test('returns the curve25519 secret key of the ed25519 secret key', () {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Named correctly here, but still the wrong type

@f-person
Copy link
Author

Hi! Somehow I missed your reply and only noticed it when configuring a shortcut(?) in the GitHub mobile app :D

Thanks for the review! I'll take a look soon and fix the code!
Have a lovely day!

@Skycoder42
Copy link
Owner

Hi @f-person. I wanted to ask if you need any help with the PR?

@f-person
Copy link
Author

Hi, Felix!
Unfortunately, I lost interest in the project for which I needed this function implemented and have been busy recently.
"Allow edits by maintainers" is enabled, so feel free to edit or close the PR; both are fine by me :).

@rhbrunetto
Copy link

@Skycoder42 are you working on this PR? If not I can try to find some time to help.

@Skycoder42
Copy link
Owner

@rhbrunetto No, I am currently not actively working on it. Feel free to continue the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants