AntonKueltz / fastecdsa

Python library for fast elliptic curve crypto
https://pypi.python.org/pypi/fastecdsa
The Unlicense
264 stars 77 forks source link

Updates to the setup and installer portion #9

Closed marchon closed 7 years ago

marchon commented 7 years ago

I hope you don't mind and are not offended, but my first impression of your library was "it's broken".

I wanted to see how it worked, so I made it work for myself, and then fixed the packaging to make it work for others right out of the box.

These changes to the imports and setup make it run better in place when you first install it.

I could not get any of your demos to work due to path issues.

If there is something you don;t like about them lets discuss, but my goal was to make it so that someone had a first class experience from the instant that they did the install.

Thank you for all of the hard work.

Now that I can get it to install properly, I am going to go play with it a bit.

It seems like a great piece of work.

George.

AntonKueltz commented 7 years ago

I think you misunderstand how python packages should be structured and how they are built. If you want to use the library please use pip install fastecdsa (you do not need to clone the repo, the pip command will suffice). If you wish to modify the code base, then feel free to clone the repo and make changes, but please be aware that relative imports should be used in this case.

CI is also indicating errors so I am not going to accept this pull request. Please let me know if you have further questions.

Cheers, Anton

marchon commented 7 years ago

no problem sir. Thank you for all of your hard work.

G.

On Wed, May 3, 2017 at 4:30 PM, Anton Kueltz notifications@github.com wrote:

I think you misunderstand how python packages should be structured and how they are built. If you want to use the library please use pip install fastecdsa (you do not need to clone the repo, the pip command will suffice). If you wish to modify the code base, then feel free to clone the repo and make changes, but please be aware that relative imports should be used in this case.

CI is also indicating errors so I am not going to accept this pull request. Please let me know if you have further questions.

Cheers, Anton

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AntonKueltz/fastecdsa/pull/9#issuecomment-299026211, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOjoAugPFDfBr8xfPX7qDvNi5z-XlQiks5r2OPwgaJpZM4NP5sw .

-- P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its attachments are confidential and solely for the intended addressee(s). Do not share or use them without approval. If received in error, contact the sender and delete them.

AntonKueltz commented 7 years ago

Note that if you want to do development you can use the following steps:

$ git clone <your fork>
$ cd fastecdsa
$ pip install -e .
$ python setup.py test

From there modify whatever you like and run the tests to verify changes didn't break anything,

marchon commented 7 years ago

It looks like a very cool library, and I was just trying to help out.

Have you thought about making it so that it uses opencl as well ?

On Wed, May 3, 2017 at 4:38 PM, Anton Kueltz notifications@github.com wrote:

Closed #9 https://github.com/AntonKueltz/fastecdsa/pull/9.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AntonKueltz/fastecdsa/pull/9#event-1067950909, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOjoFLoCVXAhBnHRCAkdy9fqsbuT5Mhks5r2OWzgaJpZM4NP5sw .

-- P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its attachments are confidential and solely for the intended addressee(s). Do not share or use them without approval. If received in error, contact the sender and delete them.

AntonKueltz commented 7 years ago

Thanks, and no worries.

How do you see OpenCL fitting into this project? Currently all underlying math is handled with GMP, which lends itself quite nicely to modular arithmetic in large finite fields, and as far as I'm aware OpenCL doesn't really support arbitrary size integer arithmetic of this sort (rather OpenCL would lend itself to floating point arithmetic, taking advantage of specialized hardware like a GPU).

marchon commented 7 years ago

That was what I was researching when I found your library.

This is a block of text from the ErikBoss paper

Intuitively, SIMD (Single Instruction, Multiple Data) simply means that we execute the same instruction of many different inputs at once. This is what a GPU excels at. OpenCL is the first open standard for doing such parallel programming on a wide variety of devices, including GPUs [14]. Its primary competitor is NVIDIA’s CUDA [23] platform. As we mention in the introduction, however, we are looking for a solution that is independent of the GPU vendor and as such OpenCL is a natural choice. Let us introduce the relevant terminology. In OpenCL we have the notion of a compute kernel, which is a small unit of execution that can be executed in parallel on a multiple independent input streams [8]. These kernels are written in a C-derivative2 and are compiled separately from the rest of the program. To execute a kernel, we enqueue it to the device. The device has several compute units, each with their own memory and processing capabilities. A given instance of a kernel executing on a compute unit is called a work item and multiple work items are bundled in work groups. All work items in the same group execute on the same compute unit. In OpenCL, we configure the total number of work items as well as the size of an individual work group. In effect, every work item has its own input stream. Furthermore, we have the notion of a wavefront, which the smallest scheduling unit. It consists of of a number of work items which execute their instructions in lockstep. Specifically, we have 32 work items per wavefront for NVIDIA GPUs and 64 work items is typical for recent AMD GPUs. For each work group, the GPU spawns the required number of wavefronts for each compute unit, which are then scheduled. If two work items within a wavefront execute separate branches within the code, we get diverging instructions that need to be executed. In practice, this will likely mean we execute both branches on every work item all the time and thus is a massive drag on performance. There are always ways to work around branches, however.

https://eprint.iacr.org/2014/198.pdf