Documentation on OpenSSL engine programming / CUDAMRG
Johannes Gilger
I've recently started looking through the engine-cuda source code and
came up with some questions.
First of all I can't seem to find very good top-down documentation for
OpenSSL and it's engine. The reason I'm looking for an entry into the
project is that I'm planning to implement several symmetric and
pubkey-ciphers in CUDA, and using OpenSSL engines seems the most concise
way to implement ciphers which can be used by other people.
Updates on the source code would be greatly appreciated, especially it
it means adding some helpful comments (not overly verbose) and getting
rid of stale codepaths.
As for contributing, I'm wondering how patches would best reach the
author. I'm using git on the cudamrg repo, so for me, sending patches
via mail would be most natural ;)
Hope to hear from you guy(s),
greetings, Jojo
--
Johannes Gilger <hei...@hackvalue.de>
http://heipei.net
GPG-Key: 0xD47A7FFC
GPG-Fingerprint: 5441 D425 6D4A BD33 B580 618C 3CDC C4D0 D47A 7FFC
Paolo Margara
> Hi list,
>
> I've recently started looking through the engine-cuda source code and
> came up with some questions.
>
> First of all I can't seem to find very good top-down documentation for
> OpenSSL and it's engine. The reason I'm looking for an entry into the
> project is that I'm planning to implement several symmetric and
> pubkey-ciphers in CUDA, and using OpenSSL engines seems the most concise
> way to implement ciphers which can be used by other people.
>
> Updates on the source code would be greatly appreciated, especially it
> it means adding some helpful comments (not overly verbose) and getting
> rid of stale codepaths.
>
> As for contributing, I'm wondering how patches would best reach the
> author. I'm using git on the cudamrg repo, so for me, sending patches
> via mail would be most natural ;)
>
> Hope to hear from you guy(s),
> greetings, Jojo
>
>
I am very happy about your interest in this project.
If you are looking for a documentation about the OpenSSL API you can
found interesting section 3 of the man pages that usually come with the
OpenSSL's devel package, for example in Debian you could install
“libssl-dev” for having this man pages. If you are interested in engines
development you can found interesting the "engine" page, this and
related pages are the most useful documentation that I have read.
What symmetric and public key ciphers do you plan to implement in CUDA
and then into engine_cudamrg?
The engine_cudamrg source code is still under development, unfortunately
during the last three month I've been very busy at work and the
development has almost stopped.
You have seen the source code into the SVN repository or the one
contained into the tarball of release 0.1.0? The SVN version has many
improvement and a general code cleanup over version 0.1.0. In my opinion
the code is quite clear to understand also without comments but if they
are needed I could add them in the near future.
For contribute if you think that you could become a usual contributor I
can add you to the project as a "contributor" with the "commit"
privilege, in alternative if you prefer or if your contribution is only
occasional you could send me patches via mail and then I commit them.
Choose the one that you prefer.
Let me know,
Paolo Margara
Johannes Gilger
> What symmetric and public key ciphers do you plan to implement in CUDA
> and then into engine_cudamrg?
ciphers. Furthermore I plan to implement RSA, DSA, ElGamal and possibly
some hash algorithms like MD5, SHA1, SHA2 and maybe some SHA3
candidates. How much of that I'll actually achieve is still open, I
haven't programmed a lot of CUDA and only have a limited timeframe
(until March 2011) since I'm doing this for my diploma thesis. On top of
that the idea was to also use OpenCL and see how it compares to CUDA.
So, the focus is purely academic for myself, while I'm trying to
implement everything as reusable as possible, hence the idea to use the
OpenSSL engine framework, so other people can easily use this code in
their applications in a concise manner. I might underestimate the amount
of work needed on the one hand, on the other hand I have almost four
months for programming available
I've yet to talk to my supervisor if I'm even allowed to use other
peoples code and if it's OK to release my work under the GPL.
> You have seen the source code into the SVN repository or the one
> contained into the tarball of release 0.1.0? The SVN version has many
> improvement and a general code cleanup over version 0.1.0. In my opinion
> the code is quite clear to understand also without comments but if they
> are needed I could add them in the near future.
I'm using the SVN version and will rebase any changes I made. Frequent
commits on your part would obviously help, instead of single huge
commits which arrive only occasionally. I think I'll wrap my head around
the sourcecode if I only read it some more. Specific questions will
surely follow ;)
A general idea what is wanted would be nice. For example, are there any
algorithms you don't want included. I've also seen a lot of
preprocessor-checks for ancient CUDA runtime versions, which obviously
complicate the code. How important is backwards-compatibility to you?
For example, you often check for CUDART > 2.0, which is more than 2
years old by this point. Or device emulation, which isn't even supported
by 'nvcc' anymore.
> For contribute if you think that you could become a usual contributor I
> can add you to the project as a "contributor" with the "commit"
> privilege, in alternative if you prefer or if your contribution is only
> occasional you could send me patches via mail and then I commit them.
> Choose the one that you prefer.
I don't want to mess around with your repository, which is why I'm
probably going to send patches via mail and/or set up a public git repo
so can view/get my changes. In the worst case scenario I might
completely fork my repository, which I'd like to avoid.
Thanks for your quick reply!
Greetings,
Paolo Margara
> On 07/12/10 14:31, Paolo Margara wrote:
>
>> What symmetric and public key ciphers do you plan to implement in CUDA
>> and then into engine_cudamrg?
>>
> I'm planning to implement DES, Blowfish, IDEA, Serpent as symmetric
> ciphers. Furthermore I plan to implement RSA, DSA, ElGamal and possibly
> some hash algorithms like MD5, SHA1, SHA2 and maybe some SHA3
> candidates. How much of that I'll actually achieve is still open, I
> haven't programmed a lot of CUDA and only have a limited timeframe
> (until March 2011) since I'm doing this for my diploma thesis.
> On top of
> that the idea was to also use OpenCL and see how it compares to CUDA.
>
> So, the focus is purely academic for myself, while I'm trying to
> implement everything as reusable as possible, hence the idea to use the
> OpenSSL engine framework, so other people can easily use this code in
> their applications in a concise manner. I might underestimate the amount
> of work needed on the one hand, on the other hand I have almost four
> months for programming available
>
> I've yet to talk to my supervisor if I'm even allowed to use other
> peoples code and if it's OK to release my work under the GPL.
>
>
your thesis is over.
>> You have seen the source code into the SVN repository or the one
>> contained into the tarball of release 0.1.0? The SVN version has many
>> improvement and a general code cleanup over version 0.1.0. In my opinion
>> the code is quite clear to understand also without comments but if they
>> are needed I could add them in the near future.
>>
> I'm using the SVN version and will rebase any changes I made. Frequent
> commits on your part would obviously help, instead of single huge
> commits which arrive only occasionally. I think I'll wrap my head around
> the sourcecode if I only read it some more. Specific questions will
> surely follow ;)
>
> A general idea what is wanted would be nice. For example, are there any
> algorithms you don't want included.
give a significant speedup is welcome.
> I've also seen a lot of
> preprocessor-checks for ancient CUDA runtime versions, which obviously
> complicate the code. How important is backwards-compatibility to you?
>
> For example, you often check for CUDART> 2.0, which is more than 2
> years old by this point. Or device emulation, which isn't even supported
> by 'nvcc' anymore.
>
>
Device emulation is removed since revision r16 (Aug 26, 2010), make sure
that you are using a fresh copy of the SVN repository. I made many
changes from release 0.1.0.
>> For contribute if you think that you could become a usual contributor I
>> can add you to the project as a "contributor" with the "commit"
>> privilege, in alternative if you prefer or if your contribution is only
>> occasional you could send me patches via mail and then I commit them.
>> Choose the one that you prefer.
>>
> I don't want to mess around with your repository, which is why I'm
> probably going to send patches via mail and/or set up a public git repo
> so can view/get my changes. In the worst case scenario I might
> completely fork my repository, which I'd like to avoid.
>
repository of this project? In this way, you're free to do almost
anything you want on that branch and when the code is ready we can merge
your source code into the main trunk.
Obviously if you prefer you can always send me your changes via email,
but I prefer the previous option.
> Thanks for your quick reply!
>
> Greetings,
> Jojo
>
>