contribution
Hello, we are a team of the department of Computer Science at the University of Perugia (Italy). Recently, we have developed an engine that implements AES in OpenCL ( http://www.khronos.org/opencl/). This engine allows to perform AES on many-multi core devices (CPU or GPU). The group's activities will focus on the consolidation of this engine and on the development of new ones. We would like to release it as a contribution to openssl community. What is the correct practices to do it? -- Dott. Flavio Vella Department of Mathematics and Computer Science
Re: contribution
Hi, Contribution are usually done by sending a patch to r...@openssl.org. The subject of the email must start with [PATCH]. The patch should be against the latest stable sources or CVS head of the branch/branches you are targeting (0.9.8x, 1.0.0x or 1.0.1x). I hope this will help you enrich OpenSSL with this interesting engine. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 11/26/2010 10:11 AM, flavio vella wrote: Hello, we are a team of the department of Computer Science at the University of Perugia (Italy). Recently, we have developed an engine that implements AES in OpenCL (http://www.khronos.org/opencl/). This engine allows to perform AES on many-multi core devices (CPU or GPU). The group's activities will focus on the consolidation of this engine and on the development of new ones. We would like to release it as a contribution to openssl community. What is the correct practices to do it? -- Dott. Flavio Vella Department of Mathematics and Computer Science __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Documentation (was: contribution)
On Fri, Nov 26, 2010 at 11:20:36AM +0100, Mounir IDRASSI wrote: Contribution are usually done by sending a patch to r...@openssl.org. The subject of the email must start with [PATCH]. The patch should be against the latest stable sources or CVS head of the branch/branches you are targeting (0.9.8x, 1.0.0x or 1.0.1x). I hope this will help you enrich OpenSSL with this interesting engine. A comment on code contributions. The pace at which OpenSSL's code has evolved has far outstipped the evolution of the documentation. I think this needs to stop. Therefore, in my humble view, contributions that introduce new public interfaces, or features should not be adopted into the OpenSSL code-base as a matter of policy unless said contributions include documentation contributions that fully describe the new interfaces or features. There should also be some effort to organically fill in the documentation gaps for past interfaces and features, but the starting point is to ensure that no new gaps are introduced. So I hope that the OpenCL engine contribution includes appropropriate documentation both public and internal. I have to reason to assume one way or the other, but *if* the software is not sufficiently documented I propose that it not be adopted unless someone on the OpenSSL team decides that the code is sufficiently compelling for him or her to take ownership and complete the documentation. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: HOWTO Contribution
Please check www.tldp.org SSL Certificates HOWTO Cheers. On Mon, 2002-12-30 at 15:15, William Michael Grim wrote: Hi there, I just signed up for openssl-users today because I was going to ask a question but then think I figured out what I needed to figure out. Anyway, I created a HOWTO that isn't on the web site about how to create signed certificates, etc. It is a rough draft, and I would apreciate any feedback, but could you get it posted on the OpenSSL.org site? It took me hours of screwing with the man pages and things to get this information compiled. Thanks a ton! William Michael Grim Student, Southern Illinois University at Edwardsville Unix System Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] Author: William Michael Grim Date: 12/29/2002 Topic: How to generate private keys and matching, self-signed certificates for use on your server. Updated copies of this document: The latest and greatest of this document are kept at http://solar.cs.siue.edu/ (umm, once I figure out a spot on the server I'll put the rest of the link in here). Okay, I hope everyone is doing well. I'm sure many of you have questions about creating OpenSSL certificates just the same way I did (and still do). So, if you have any updates, fixes, or expansions of this document, PLEASE let me know so I can get this updated. Also, at the end of this document you will find questions from myself that I would like to have answered if anyone wouldn't mind doing so (and they'll get put in this HOWTO). Now, on to business. This document currently outlines how to generate a dsa parameter file, a dsa private key, a certificate request, and finally, a self-signed certificate. SOME IMPORTANT NOTES: For the first three steps, you'll also want to do something like chmod 0600 on the files generated so they're not world-readable. There is no reason they need to be world-readable, and they all have something to do with your private key. You do NOT want your private key getting out into the world. On the last step where you create your certificate, leave the generated file world-readable. Quick steps to creating a private key and matching certificate: openssl dsaparam -out dsa_param.pem 1024 openssl gendsa -des3 -out privkey.pem dsa_params.pem openssl req -new -key privkey.pem -out cert_req.pem openssl x509 -req -in cert_req.pem -out cert.pem -trustout -signkey privkey.pem Understanding the quick steps: The first thing someone needs to do to create a private key is generate a dsa parameter file. Actually, private keys can be made on the fly without this file, but once you have one of these files, future generation of extra private keys is faster, because the computer doesn't have to calculate as many numbers. Plus, the next command after this one prefers a dsaparam file. The format of the dsaparam command: - openssl dsaparam -out file.pem num_of_bits Basically, all files are output in the PEM format unless otherwise specified. So, this command generates a parameter file with the specified number of bits. EXAMPLE USAGE: openssl dsaparam -out dsa_param.pem 1024 The next step you need to perform is actually generating your private key. The format of the gendsa command: - openssl gendsa [-des3] -out file.pem dsaparam-file It's easy to understand that this command is generating a key using a dsa parameter file you previously created, but what may not be familiar is the [-des3] optioon. This is just an option to use for encrypting your private key. I've noticed that if you encrypt a key and use it with Apache upon bootup, the server will hang until it has the private key password. You can probably leave the option off as long as you make sure not to let the key be world readable (should be locked anyway if you followed my security advice at the beginning). EXAMPLE USAGE: openssl gendsa -des3 -out privkey.pem dsa_params.pem After you create a new private key, you need to generate a new certificate request, signed with your private key. A certificate request is what you give to your certificate authority (CA) to have them create a certificate and send back to you. Inside your certificate request, it will have information such as the issuer of the request, such as the country, state, company, email, etc. The request also has the private key, which is used by the CA to confirm your identity. Format of the req command for a new certificate: - openssl req -new -key private_key.pem -out file.pem EXAMPLE USAGE: openssl req -new -key privkey.pem -out cert_req.pem Now, if you wanted to just create a request and send it to a commercial CA, this is the point you should stop and follow the steps your CA provides for you. However, if you want to sign your own certificate request, because you are like me and only run personal servers and/or do not have the money to pay a CA, please continue reading. NOTE: Some CAs need requests/keys/etc to be in
HOWTO Contribution
Hi there, I just signed up for openssl-users today because I was going to ask a question but then think I figured out what I needed to figure out. Anyway, I created a HOWTO that isn't on the web site about how to create signed certificates, etc. It is a rough draft, and I would apreciate any feedback, but could you get it posted on the OpenSSL.org site? It took me hours of screwing with the man pages and things to get this information compiled. Thanks a ton! William Michael Grim Student, Southern Illinois University at Edwardsville Unix System Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] Author: William Michael Grim Date: 12/29/2002 Topic: How to generate private keys and matching, self-signed certificates for use on your server. Updated copies of this document: The latest and greatest of this document are kept at http://solar.cs.siue.edu/ (umm, once I figure out a spot on the server I'll put the rest of the link in here). Okay, I hope everyone is doing well. I'm sure many of you have questions about creating OpenSSL certificates just the same way I did (and still do). So, if you have any updates, fixes, or expansions of this document, PLEASE let me know so I can get this updated. Also, at the end of this document you will find questions from myself that I would like to have answered if anyone wouldn't mind doing so (and they'll get put in this HOWTO). Now, on to business. This document currently outlines how to generate a dsa parameter file, a dsa private key, a certificate request, and finally, a self-signed certificate. SOME IMPORTANT NOTES: For the first three steps, you'll also want to do something like chmod 0600 on the files generated so they're not world-readable. There is no reason they need to be world-readable, and they all have something to do with your private key. You do NOT want your private key getting out into the world. On the last step where you create your certificate, leave the generated file world-readable. Quick steps to creating a private key and matching certificate: openssl dsaparam -out dsa_param.pem 1024 openssl gendsa -des3 -out privkey.pem dsa_params.pem openssl req -new -key privkey.pem -out cert_req.pem openssl x509 -req -in cert_req.pem -out cert.pem -trustout -signkey privkey.pem Understanding the quick steps: The first thing someone needs to do to create a private key is generate a dsa parameter file. Actually, private keys can be made on the fly without this file, but once you have one of these files, future generation of extra private keys is faster, because the computer doesn't have to calculate as many numbers. Plus, the next command after this one prefers a dsaparam file. The format of the dsaparam command: - openssl dsaparam -out file.pem num_of_bits Basically, all files are output in the PEM format unless otherwise specified. So, this command generates a parameter file with the specified number of bits. EXAMPLE USAGE: openssl dsaparam -out dsa_param.pem 1024 The next step you need to perform is actually generating your private key. The format of the gendsa command: - openssl gendsa [-des3] -out file.pem dsaparam-file It's easy to understand that this command is generating a key using a dsa parameter file you previously created, but what may not be familiar is the [-des3] optioon. This is just an option to use for encrypting your private key. I've noticed that if you encrypt a key and use it with Apache upon bootup, the server will hang until it has the private key password. You can probably leave the option off as long as you make sure not to let the key be world readable (should be locked anyway if you followed my security advice at the beginning). EXAMPLE USAGE: openssl gendsa -des3 -out privkey.pem dsa_params.pem After you create a new private key, you need to generate a new certificate request, signed with your private key. A certificate request is what you give to your certificate authority (CA) to have them create a certificate and send back to you. Inside your certificate request, it will have information such as the issuer of the request, such as the country, state, company, email, etc. The request also has the private key, which is used by the CA to confirm your identity. Format of the req command for a new certificate: - openssl req -new -key private_key.pem -out file.pem EXAMPLE USAGE: openssl req -new -key privkey.pem -out cert_req.pem Now, if you wanted to just create a request and send it to a commercial CA, this is the point you should stop and follow the steps your CA provides for you. However, if you want to sign your own certificate request, because you are like me and only run personal servers and/or do not have the money to pay a CA, please continue reading. NOTE: Some CAs need requests/keys/etc to be in the DER format, not PEM. If this is the case, look through
