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

implement NEON backend #147

Open
isislovecruft opened this issue Jun 21, 2018 · 5 comments · May be fixed by #457
Open

implement NEON backend #147

isislovecruft opened this issue Jun 21, 2018 · 5 comments · May be fixed by #457

Comments

@isislovecruft
Copy link
Member

No description provided.

@hdevalence
Copy link
Contributor

As part of this I think it would be good to reorganize the structure of the source tree, if we're going to have multiple vector and serial backends. Right now the tree looks like

backend
├── avx2
│   ├── #edwards.rs#
│   ├── constants.rs
│   ├── edwards.rs
│   ├── field.rs
│   ├── mod.rs
│   └── scalar_mul
│       ├── mod.rs
│       ├── straus.rs
│       ├── variable_base.rs
│       └── vartime_double_base.rs
├── mod.rs
├── u32
│   ├── constants.rs
│   ├── field.rs
│   ├── mod.rs
│   └── scalar.rs
└── u64
    ├── constants.rs
    ├── field.rs
    ├── mod.rs
    └── scalar.rs

and there's a separate hierarchy for the curve_models and the scalar_mul code, which only have the serial algorithms.

I think it might be better to organize the code like

backend
├── mod.rs
├── serial
│   ├── curve_models
│   │   └── mod.rs
│   ├── scalar_mul
│   │   ├── mod.rs
│   │   ├── straus.rs
│   │   ├── variable_base.rs
│   │   ├── vartime_double_base.rs
│   │   └── window.rs
│   ├── u32
│   │   ├── constants.rs
│   │   ├── field.rs
│   │   ├── mod.rs
│   │   └── scalar.rs
│   └── u64
│       ├── constants.rs
│       ├── field.rs
│       ├── mod.rs
│       └── scalar.rs
└── vector
    ├── avx2
    │   ├── constants.rs
    │   ├── field.rs
    │   └── mod.rs
    ├── edwards.rs
    ├── neon
    │   ├── constants.rs
    │   ├── field.rs
    │   └── mod.rs
    └── scalar_mul
        ├── mod.rs
        ├── straus.rs
        ├── variable_base.rs
        └── vartime_double_base.rs

so that the module tree looks more like the actual structure of what parts are common and which aren't.

hdevalence added a commit to hdevalence/curve25519-dalek that referenced this issue Jul 16, 2018
@hdevalence
Copy link
Contributor

I typed the wrong issue number in a commit, this was closed spuriously.

@rubdos
Copy link
Contributor

rubdos commented Dec 14, 2018

Has there been any work on this back end yet? If not, I'm interested in taking a look.

@hdevalence
Copy link
Contributor

I think that @isislovecruft started working on it in the summer. Right now any work on it is blocked on merging #215, which restructures all of the backend code (e.g., making the changes above).

@rubdos
Copy link
Contributor

rubdos commented Dec 15, 2018

Agreed. Give me a ping if you want some man-hours spend on this. It would be very cool to have curve25519-dalek as the fastest library on all platforms :-)

@hdevalence hdevalence removed this from the 1.1 milestone Dec 29, 2018
@hdevalence hdevalence added this to the 1.3 milestone Jun 4, 2019
@isislovecruft isislovecruft removed their assignment Jan 7, 2021
@rubdos rubdos linked a pull request Dec 8, 2022 that will close this issue
5 tasks
pinkforest pushed a commit to pinkforest/curve25519-dalek that referenced this issue Jun 27, 2023
…rministic-batch-malleability

batch verification malleability issue when used with fully deterministic nonce generation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants