Re: FIPS module Algorithm tests failure.
FYI, My Build system and target system have similar OS. Build System: x86_64 x86_64 x86_64 GNU/Linux Target System: x86_64 GNU/Linux -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-module-Algorithm-tests-failure-tp44420p9.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
:o*@nn-idol*::D __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[no subject]
:o*@nn-idol*::D __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
???: Re: OpenSSL Wiki (docbook and...)
:o*@nn-idol*::D -Original Message- From: Pierre DELAAGE Sent: 3/19/2013 11:49:24 PM To: openssl-dev@openssl.org Cc: Steve Marquess Subject: Re: OpenSSL Wiki (docbook and...) Hi Steve, My own experience in my company is that OpenOffice is perfectly suited for track changes in a collaborative env. Ok, allright, it cannot offer a line by line diff as in cvs systems, and return to specific version and so on, but the track changes can help. In my company, we were using latex...and track changes was in fact even more complicated with it. Not talking about "tables" and "graphics" that were painful. OpenOffice gives the advantages of various worlds : wisywyg, open format, quite robust for big doc compared to other similar products,.. xml based... Be careful before going away back to some raw xml format...even if it is better than latex. a question : Are you thinking to use "LyX" editor to produce Docbook ? Anyway I have 2 comments : 1/ fips guide seems good like it is : regularly updated and maintained. I do not think that people claimed for a wiki on that, so I think it can stay as it is. 2/ wiki was called by some of us to improve some old doc that do not seem to evolve regularly and that miss some details, explanations, samples. For the moment I would recommend that the wiki focuses on lib doc and command line doc, and not on fips guide. Well...now a question : I am not an expert with mediawiki format, but will you have also that "version control" issue with that format ? how to solve it then... or maybe it is not relevant for the wiki, but only for the fips guide... Regards, Pierre Le 20/03/2013 00:16, Steve Marquess a écrit : > On 03/19/2013 04:04 PM, Pierre DELAAGE wrote: >> hmm, Steve I highly suggest that we have a look at ...OpenOffice and its >> various export filters. >> >> for mediawiki it is there : >> http://extensions.services.openoffice.org/fr/node/738 >> >> for Docbook the filter is embedded (never tested by myself..). >> >> Does it help ? > Well, I haven't specifically tried Libreoffice filters for ODF to > markdown but the OpenSSL FIPS User Guide is currently in ODF and that's > what I'm trying to get away from. > > A major drawback of ODF is that is can't easily be version controlled in > a collaborative setting. Now that there are several people contributing > content to that document the ODF format is very limiting, hence the > ongoing attempt to convert to docbook. That has turned out to be a bit > of a challenge but I'm still hoping to pull it off. > > -Steve M. > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
???: Re: OpenSSL Wiki (docbook and...)
:o*@nn-idol*::D -Original Message- From: Pierre DELAAGE Sent: 3/19/2013 11:49:24 PM To: openssl-dev@openssl.org Cc: Steve Marquess Subject: Re: OpenSSL Wiki (docbook and...) Hi Steve, My own experience in my company is that OpenOffice is perfectly suited for track changes in a collaborative env. Ok, allright, it cannot offer a line by line diff as in cvs systems, and return to specific version and so on, but the track changes can help. In my company, we were using latex...and track changes was in fact even more complicated with it. Not talking about "tables" and "graphics" that were painful. OpenOffice gives the advantages of various worlds : wisywyg, open format, quite robust for big doc compared to other similar products,.. xml based... Be careful before going away back to some raw xml format...even if it is better than latex. a question : Are you thinking to use "LyX" editor to produce Docbook ? Anyway I have 2 comments : 1/ fips guide seems good like it is : regularly updated and maintained. I do not think that people claimed for a wiki on that, so I think it can stay as it is. 2/ wiki was called by some of us to improve some old doc that do not seem to evolve regularly and that miss some details, explanations, samples. For the moment I would recommend that the wiki focuses on lib doc and command line doc, and not on fips guide. Well...now a question : I am not an expert with mediawiki format, but will you have also that "version control" issue with that format ? how to solve it then... or maybe it is not relevant for the wiki, but only for the fips guide... Regards, Pierre Le 20/03/2013 00:16, Steve Marquess a écrit : > On 03/19/2013 04:04 PM, Pierre DELAAGE wrote: >> hmm, Steve I highly suggest that we have a look at ...OpenOffice and its >> various export filters. >> >> for mediawiki it is there : >> http://extensions.services.openoffice.org/fr/node/738 >> >> for Docbook the filter is embedded (never tested by myself..). >> >> Does it help ? > Well, I haven't specifically tried Libreoffice filters for ODF to > markdown but the OpenSSL FIPS User Guide is currently in ODF and that's > what I'm trying to get away from. > > A major drawback of ODF is that is can't easily be version controlled in > a collaborative setting. Now that there are several people contributing > content to that document the ODF format is very limiting, hence the > ongoing attempt to convert to docbook. That has turned out to be a bit > of a challenge but I'm still hoping to pull it off. > > -Steve M. > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (docbook and...)
Hi Steve, My own experience in my company is that OpenOffice is perfectly suited for track changes in a collaborative env. Ok, allright, it cannot offer a line by line diff as in cvs systems, and return to specific version and so on, but the track changes can help. In my company, we were using latex...and track changes was in fact even more complicated with it. Not talking about "tables" and "graphics" that were painful. OpenOffice gives the advantages of various worlds : wisywyg, open format, quite robust for big doc compared to other similar products,.. xml based... Be careful before going away back to some raw xml format...even if it is better than latex. a question : Are you thinking to use "LyX" editor to produce Docbook ? Anyway I have 2 comments : 1/ fips guide seems good like it is : regularly updated and maintained. I do not think that people claimed for a wiki on that, so I think it can stay as it is. 2/ wiki was called by some of us to improve some old doc that do not seem to evolve regularly and that miss some details, explanations, samples. For the moment I would recommend that the wiki focuses on lib doc and command line doc, and not on fips guide. Well...now a question : I am not an expert with mediawiki format, but will you have also that "version control" issue with that format ? how to solve it then... or maybe it is not relevant for the wiki, but only for the fips guide... Regards, Pierre Le 20/03/2013 00:16, Steve Marquess a écrit : On 03/19/2013 04:04 PM, Pierre DELAAGE wrote: hmm, Steve I highly suggest that we have a look at ...OpenOffice and its various export filters. for mediawiki it is there : http://extensions.services.openoffice.org/fr/node/738 for Docbook the filter is embedded (never tested by myself..). Does it help ? Well, I haven't specifically tried Libreoffice filters for ODF to markdown but the OpenSSL FIPS User Guide is currently in ODF and that's what I'm trying to get away from. A major drawback of ODF is that is can't easily be version controlled in a collaborative setting. Now that there are several people contributing content to that document the ODF format is very limiting, hence the ongoing attempt to convert to docbook. That has turned out to be a bit of a challenge but I'm still hoping to pull it off. -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 04:59 PM, Matt Caswell wrote: > On 19 March 2013 19:38, Steve Marquess wrote: >> I took a quick look to see what utilities might be available to convert >> between pod and mediawiki markup formats. "pod2markdown" (CPAN) is close >> but not quite there. > > The pod markup language is pretty basic. If something isn't already > out there I would have thought a bit of clever regex search and > replace would do the job. Yes, I think in principle conversion both ways is feasible, though by the time we automate the database I/O it gets complicated. The harder issue is how the markdown and pod content will be synchronized. > What I'm not clear on is if you imported them onto the wiki how that > would work in practice. It's kind of a one way operation - I can't > really see how you could keep both the pod version and the wiki > version going - they would inevitably start to divergeunless you > could somehow keep wiki as the master and then import them back in > again?? Alternatively we just ditch pod altogether - but that would > lose the ability to create man pages (does anyone still read man > pages)? That is the dilemma. Currently most of the documentation content at openssl.org is generated from source files in the repository, so there is no ready mechanism for feeding any changes back to that source. If the wiki works out we could conceivably drop the repository controlled files entirely. That approach hasn't been proven viable yet. So perhaps a content page in the wiki consisting of a link to the openssl.org static content so the talk page could collect commentary? BTW I still read man pages daily ... I have CRS syndrome (Can't Remember Sh^h^hStuff). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (docbook and...)
On 03/19/2013 04:04 PM, Pierre DELAAGE wrote: > hmm, Steve I highly suggest that we have a look at ...OpenOffice and its > various export filters. > > for mediawiki it is there : > http://extensions.services.openoffice.org/fr/node/738 > > for Docbook the filter is embedded (never tested by myself..). > > Does it help ? Well, I haven't specifically tried Libreoffice filters for ODF to markdown but the OpenSSL FIPS User Guide is currently in ODF and that's what I'm trying to get away from. A major drawback of ODF is that is can't easily be version controlled in a collaborative setting. Now that there are several people contributing content to that document the ODF format is very limiting, hence the ongoing attempt to convert to docbook. That has turned out to be a bit of a challenge but I'm still hoping to pull it off. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 19 March 2013 10:22, Leon Brits wrote: > I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits > curves (233-571 bit). I then convert the keys to PEM using the same method > which I used successfully for RSA and DSA which only calls > PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never > specified in my functions. What is interesting now is that if I test the EC > PEM files, using the openssl command line tool, all the keys generated for > the NIST Prime curves is successfully parsed while the others fails with the > following error: I have just tested this with no problems using NID_sect233k1. What version of openssl are you using? Please see attached PEM file. Are you able to read that with openssl ec? Please send me a sample PEM that you are having difficulty with and I will see if I can read it. Matt out.pem Description: Binary data
Re: OpenSSL Wiki
On Tue, 19 Mar 2013, Matt Caswell wrote: > Alternatively we just ditch pod altogether - but that would > lose the ability to create man pages (does anyone still read man > pages)? Yes, some of us still do. -- Tim RiceMultitalents t...@multitalents.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3002] Communication problems with 1.0.1e
On Mon, Mar 18, 2013 at 07:43:41PM +0100, Andy Polyakov via RT wrote: > Anyway, other users confirm that > http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ab3ce124616cb12bd39c6aa1e1bde0f46969b29 > > solves the problem. Thanks for additional information. I also got 1 confirmation that it fixes the problem. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 19 March 2013 19:38, Steve Marquess wrote: > I took a quick look to see what utilities might be available to convert > between pod and mediawiki markup formats. "pod2markdown" (CPAN) is close > but not quite there. The pod markup language is pretty basic. If something isn't already out there I would have thought a bit of clever regex search and replace would do the job. What I'm not clear on is if you imported them onto the wiki how that would work in practice. It's kind of a one way operation - I can't really see how you could keep both the pod version and the wiki version going - they would inevitably start to divergeunless you could somehow keep wiki as the master and then import them back in again?? Alternatively we just ditch pod altogether - but that would lose the ability to create man pages (does anyone still read man pages)? Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (docbook and...)
hmm, Steve I highly suggest that we have a look at ...OpenOffice and its various export filters. for mediawiki it is there : http://extensions.services.openoffice.org/fr/node/738 for Docbook the filter is embedded (never tested by myself..). Does it help ? Pierre Le 19/03/2013 20:38, Steve Marquess a écrit : On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be "fed" at the beginning by all the Documents available at "http://www.openssl.org/docs/";. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a "man page". And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... ... I took a quick look to see what utilities might be available to convert between pod and mediawiki markup formats. "pod2markdown" (CPAN) is close but not quite there. Side note: we're in the process of converting the OpenSSL FIPS Object Module User Guide (all 200 min-numbing pages) to docbook format. So if anyone has any brilliant insights on the smart way to manage documentation that wants to be in all three formats I'd love to hear it. -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (export back to orig docs)
Dear Ben and Steve, I think that once the wiki is at least fed by the docs, the docs space should link directly to the wiki, to avoid duplication... The purpose of the wiki is to get more people involved in the doc, and hopefully to get a more up-to-date doc, and I would say : to prevent experts from repeating themselves years after years in the mailing lists... So if the wiki succeeds to be more complete than the present doc, it "should" replace it. If it fails...it will disappear... By the mechanism of "administrators" of the wiki, it may be possible to restrict modifications of some core docs coming from the dev team, to the dev team. And to allow adds at the end of the core chapters as "comments"...by ordinary contributors... Just to mention: I do NOT think that the wiki should have any "openssl-dev" purpose : only a purpose to "use" openssl. I mean that dev-team should have its own doc space as usual, away from the wiki. Yours sincerely, Pierre Le 19/03/2013 20:15, Ben Laurie a écrit : On 19 March 2013 18:53, Steve Marquess wrote: On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be "fed" at the beginning by all the Documents available at "http://www.openssl.org/docs/";. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a "man page". And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. Seems like a good idea to me. It does raise the question of how you export back to the docs tho... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
Dear Steve, I am pleased you found something useful in my comments. Just to mention : Yes I suggest something like you said "...three major divisions: reference, programming, and didactic.". I would just add : "programming/...using", I am thinking about the command line tools... although, as they can be called in bash scripts, they can be seen also as a kind of "system lib". Ok, I will do my best to help. I already contributed a little to WCE porting, I will be pleased to contribute on the command line part of the doc set. Following your suggestion I suggest something like this : At the top of the organization, 3 chapters : - didactic on cryptography and the interest of openssl - the LIB(s) : then reference, and programmer's manual (a set of howto, use cases...) - the command line tools : then reference, and "usage manual" (eg to produce certs & manage them (check validity, renew, revoke, import/export...), sample scripts ) *** Something else : I also suggest that some expert, when dealing with answers to the users list, decide either to answer to the list as usual or to answer via the wiki by opening another topic or updating an existing one. Just to avoid that useful info be lost in the depth of the mails... In fact I think that, today, we are all using the mails archives as a wiki... but it lacks organization as you said, and at a time, the info is lost because it is not so simple to take many mails together to understand clearly a pb and its solution. With the wiki, I think that info will never get lost. Yours sincerely, Pierre Le 19/03/2013 19:53, Steve Marquess a écrit : On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be "fed" at the beginning by all the Documents available at "http://www.openssl.org/docs/";. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a "man page". And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. ... Moreover, for the lib, I suggest to separate the "reference manual", describing and commenting each api call, from a kind of "programmers' manual", that could describe how to use the lib for various purposes: such manuals were available for various programming tools in the past, and I have always been happy with those 2 complementary set of docs. For the command line set, and general config/install of the tool I suggest to do the same : - reference doc of each command and conf file - advanced users' manual covering install/config/and usage for various purposes. For example : I am using the command line tools as a very basic pki system to create certificate for my company. Those certs are produced by openssl to be used by openssl based applications such as stunnel or Apache: those usage are very common and should be documented in an advanced users manual. Sometime those certs have to be imported in client apps such as Mozilla Firefox or Thunderbird, or M$ Ie and outllook : I think the wiki/adv users manual could be a good repository for all this. And of course, although openssl is for advanced users, I think some pedagogic material on cryptography and its usage, and the benefit of using openssl to fulfill those needs, could be very useful. So you're suggest three major divisions: reference, programming, and didactic. Also an interesting suggestion. Well, in fact I am wondering about the best way to structure the chapters of the wiki : depending on that, we can hope to have something as clear and useful as possible, instead of being a bazaar of various things. I think that is the major part of the challenge: organization. On the other hand useful material can always be organized later. Personnally I can contribute to some command line tools usage case, although I have to admit that I feel a little bit intimidated to publish something on this prestigious wiki... Now that made me laugh :-) You're already contributed something with your thoughtful comments, don't stop now. -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: > Dear Steve, > I was wondering whether the wiki could be "fed" at the beginning by all > the Documents available at "http://www.openssl.org/docs/";. > > Very often people are able to comment, eg, a command page with some > samples or error comments, > instead of rewriting from scratch a "man page". > > And this could be a way to only have one unique set of docs to maintain, > and to refer to, instead of having two... > ... I took a quick look to see what utilities might be available to convert between pod and mediawiki markup formats. "pod2markdown" (CPAN) is close but not quite there. Side note: we're in the process of converting the OpenSSL FIPS Object Module User Guide (all 200 min-numbing pages) to docbook format. So if anyone has any brilliant insights on the smart way to manage documentation that wants to be in all three formats I'd love to hear it. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
Dear Ben and Steve, I think that once the wiki is at least fed by the docs, the docs space should link directly to the wiki, to avoid duplication... The purpose of the wiki is to get more people involved in the doc, and hopefully to get a more up-to-date doc, and I would say : to prevent experts from repeating themselves years after years in the mailing lists... So if the wiki succeeds to be more complete than the present doc, it "should" replace it. If it fails...it will disappear... By the mechanism of "administrators" of the wiki, it may be possible to restrict modifications of some core docs coming from the dev team, to the dev team. And to allow adds at the end of the core chapters as "comments"...by ordinary contributors... Just to mention: I do NOT think that the wiki should have any "openssl-dev" purpose : only a purpose to "use" openssl. I mean that dev-team should have its own doc space as usual, away from the wiki. Yours sincerely, Pierre Le 19/03/2013 20:15, Ben Laurie a écrit : On 19 March 2013 18:53, Steve Marquess wrote: On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be "fed" at the beginning by all the Documents available at "http://www.openssl.org/docs/";. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a "man page". And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. Seems like a good idea to me. It does raise the question of how you export back to the docs tho... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: > Dear Steve, I was wondering whether the wiki could be "fed" at the > beginning by all the Documents available at > "http://www.openssl.org/docs/";. > > Very often people are able to comment, eg, a command page with some > samples or error comments, instead of rewriting from scratch a "man > page". > > And this could be a way to only have one unique set of docs to > maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. > ... > > Moreover, for the lib, I suggest to separate the "reference manual", > describing and commenting each api call, from a kind of > "programmers' manual", that could describe how to use the lib for > various purposes: such manuals were available for various programming > tools in the past, and I have always been happy with those 2 > complementary set of docs. > > > For the command line set, and general config/install of the tool I > suggest to do the same : - reference doc of each command and conf > file - advanced users' manual covering install/config/and usage for > various purposes. > > For example : I am using the command line tools as a very basic pki > system to create certificate for my company. Those certs are > produced by openssl to be used by openssl based applications such as > stunnel or Apache: those usage are very common and should be > documented in an advanced users manual. Sometime those certs have to > be imported in client apps such as Mozilla Firefox or Thunderbird, or > M$ Ie and outllook : I think the wiki/adv users manual could be a > good repository for all this. > > And of course, although openssl is for advanced users, I think some > pedagogic material on cryptography and its usage, and the benefit of > using openssl to fulfill those needs, could be very useful. So you're suggest three major divisions: reference, programming, and didactic. Also an interesting suggestion. > > Well, in fact I am wondering about the best way to structure the > chapters of the wiki : depending on that, we can hope to have > something as clear and useful as possible, instead of being a bazaar > of various things. I think that is the major part of the challenge: organization. On the other hand useful material can always be organized later. > Personnally I can contribute to some command line tools usage case, > although I have to admit that I feel a little bit intimidated to > publish something on this prestigious wiki... Now that made me laugh :-) You're already contributed something with your thoughtful comments, don't stop now. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 19 March 2013 10:22, Leon Brits wrote: > Matt / List, > > > > Thanks for the example. It sure helped a lot. But I am still stuck at the EC > key generation. > > > > I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits > curves (233-571 bit). I then convert the keys to PEM using the same method > which I used successfully for RSA and DSA which only calls > PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never > specified in my functions. What is interesting now is that if I test the EC > PEM files, using the openssl command line tool, all the keys generated for > the NIST Prime curves is successfully parsed while the others fails with the > following error: > Can you send me an offending PEM file? > > I’ve noticed that writing the PEM files using the above mentioned mechanism > does not add the letters “EC” to the PEM header and footer of the private > key (e.g. -BEGIN EC PRIVATE KEY-- misses the “EC”). The spec seems > to say it must have these two characters. If I add the “EC” manually, I get > the following parsing error: They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 > > Also can someone shed some light on the naming of the curves: Take for > example “NID_secp224r1”. From the bits I can see that it is a NIST prime > curve which is also indicated by the ‘p’ (right?), which then makes me > wonder why all the binary curves has a ‘t’ (e.g. NID_sect233r1). Next, to > distinguish between the NIST binary curves and the Kolbitz curves the only > indication is that the Kolbitz curve names ends with a ‘k1’ - is this > correct? And if so what is the ‘r’ for then in the NIST prime and NIST > binary numbers? And finally, why is there not a NID_sect256r1, but rather a > NID_X9_62_prime256v1? The "sec" ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an "r" indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
openssl online docs, broken links
Some broken links on online pages : at http://www.openssl.org/related/ : "openssl / related / OpenSSL/SSLeay " web page : broken links are : MS Dev Studio workspace for OpenSSL http://openssl.governmentsecurity.org/ SSLeay Doc: FAQ List http://www.psy.uq.oz.au/~ftp/Crypto/ SSLeay Doc: Documentation Archive http://www.columbia.edu/~ariel/ssleay/ SSLeay Certificate Cookbook http://www.ultranet.com/~fhirsch/Papers/cook/ssl_cook.html SSL Certificates HOWTO http://www.gtlib.cc.gatech.edu/pub/linux/docs/HOWTO/other-formats/html_single/SSL-Certificates-HOWTO.html "openssl / related / SSL/TLS " web page : SSL Patent http://www.cygnus.com/~gnu/ssl.patent.5657390 SSLv1 Protocol Specification (obsolete) http://www.consensus.com/ietf-tls/tls-ssh-00.txt SSLv2 Protocol Specification (obsolete) http://www.netscape.com/eng/security/SSL_2.html SSLv3 Internet Draft (obsolete) ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ssl-version3-00.txt SSLv3 Protocol Specification http://www.netscape.com/eng/ssl3/ SSLv3 to TLSv1: Modifications http://www.consensus.com/ietf-tls/tls-ssl-mods-00.txt TLSv1 Proposed Standard, RFC2246 ftp://ftp.isi.edu/in-notes/rfc2246.txt HTTP over TLS ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-https-02.txt Tunneling TCP based protocols through Web proxy servers http://www.www.alternic.org/drafts/drafts-l-m/draft-luotonen-web-proxy-tunneling-01.txt !!! even by removing the extra "www" in the url, it is still broken. Analysis of the SSL 3.0 Protocol http://www.counterpane.com/ssl.html Internet X.509 Public Key Infrastructure (PKIX) http://www.imc.org/ietf-pkix/ SSL/TLS Presentation http://www.aus.rsa.com/rsa99/ssl-tls.pdf * Toolkits tab page : RSA BSAFE SSL-C http://www.aus.rsa.com/products/sslc/ SSLPlus http://www.consensus.com/sslplus/ Spyrus TLS Gold Toolkit http://www.spyrus.com/content/products/ssl/tlsgold/ SSLRef ftp://ftp.replay.com/pub/crypto/SSL/ Oscar http://oscar.dstc.qut.edu.au/ * Application tab : Net::SSLeay http://www.bacus.pt/Net_SSLeay/index.html SMIMEUtil http://www.bacus.pt/Net_SSLeay/smime.html jonama http://www.multimania.com/jonama/ stunnel and stunnel-p are now merged to be official stunnel web page. tlswrap http://tlswrap.sunsite.dk/ sslfd http://www.quick.com.au/ftp/pub/sjg/help/sslfd.html sNFS http://www.quick.com.au/ftp/pub/sjg/help/sNFS.html WN/SSL http://www.freestone.net/soft/ ... Well, alright, I will continue at another time, most are broken in that "app page"... So, could those lonks be removed from the page or updated ? Yours sincerely, Pierre __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FIPS module Algorithm tests failure.
I am cross compiling FIPS object module as per FIPS user guide 2.0. After creating fipscanister.o, i tried *make build_tests* to generate *fips_test_suite file*, which i could run successfully(both in build system and target system). But When i try running *perl fipsalgtest.pl --dir=fips-2.0-testvectors/* in the Target system, I get this: Running DSA tests Running DSA2 tests Running ECDSA tests Running ECDSA2 tests Running RSA tests Running SHA tests No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA1LongMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA1Monte.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA1ShortMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA224LongMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA224Monte.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA224ShortMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA256LongMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA256Monte.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA256ShortMsg.tst No FIPS_SHA support ERROR: can't open output file fips-2.0-testvectors//OSF_2464_OE4/SHA/resp/SHA384LongMsg.tst . . ALGORITHM TEST VERIFY SUMMARY REPORT: Tests skipped due to missing files:0 Algorithm test program execution failures: 0 Test comparisons successful: 229 Test comparisons failed: 15 Test sanity checks successful: 15 Test sanity checks failed: 0 Sanity check program execution failures: 0 ***TEST FAILURE*** I dont see this error when i run same script on my build system(I am cross compiling). I dont understand why SHA tests are failing in the target system? (FYI, i copied ./test directory, fipsalgtest.pl, fips_test_suite and fips-2.0-tv.tar.gz to the target machine) Also, when i try running *./fips_hmactest -v fips_hmactest.c* , i get a *FATAL input initialization error* message(even in my build system) which is my second concern. Thanks, Cipher -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-module-Algorithm-tests-failure-tp44420.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
Dear Steve,
I was wondering whether the wiki could be "fed" at the beginning by all
the Documents available at "http://www.openssl.org/docs/";.
Very often people are able to comment, eg, a command page with some
samples or error comments,
instead of rewriting from scratch a "man page".
And this could be a way to only have one unique set of docs to maintain,
and to refer to, instead of having two...
Personnally I think the present doc is not so bad, but, as it seems from
the mailing list,
sometime some command or api call miss a clarification or a sample.
Moreover, for the lib, I suggest to separate the "reference manual",
describing and commenting each api call,
from a kind of "programmers' manual", that could describe how to use the
lib for various purposes:
such manuals were available for various programming tools in the past,
and I have always been happy with those 2 complementary set of docs.
For the command line set, and general config/install of the tool I
suggest to do the same :
- reference doc of each command and conf file
- advanced users' manual covering install/config/and usage for various
purposes.
For example : I am using the command line tools as a very basic pki
system to create certificate for my company. Those certs are produced by
openssl to be used by openssl based applications such as stunnel or
Apache: those usage are very common and should be documented in an
advanced users manual.
Sometime those certs have to be imported in client apps such as Mozilla
Firefox or Thunderbird, or M$ Ie and outllook :
I think the wiki/adv users manual could be a good repository for all this.
And of course, although openssl is for advanced users, I think some
pedagogic material on cryptography and its usage, and the benefit of
using openssl to fulfill those needs,
could be very useful.
Well, in fact I am wondering about the best way to structure the
chapters of the wiki : depending on that, we can hope to have something
as clear and useful as possible, instead of being a bazaar of various
things.
Personnally I can contribute to some command line tools usage case,
although I have to admit that I feel a little bit intimidated to publish
something on this prestigious wiki...
although I was wishing it myself...
Yours sincerely,
Pierre
Le 19/03/2013 13:51, Steve Marquess a écrit :
With some trepidation, and considerable assistance from a small group of
earlier adopters, I hereby unleash a new OpenSSL Wiki on an unsuspecting
world:
http://wiki.opensslfoundation.com/
There is a need for more and better OpenSSL documentation, and the
hopeful theory here is that this Wiki will serve as a focal point for
collecting useful content that over time will converge into a useful and
comprehensive resource.
Since I and some of the initial collaborators are still learning about
Wiki management it will remain on a separate server and the
opensslfoundation.com domain for an indeterminate trial period. If it
evolves into a useful resource, and once we're comfortable with all the
security and technical implications, then we will migrate it to a
wiki.openssl.org domain. We're still in the process of migrating the
legacy openssl.org server to a new home and this Wiki is another
complication we don't need right now.
There is some content already but new contributions are welcome. We'll
be wanting to add some more administrators ("sysops") too.
-Steve M.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: OpenSSL Wiki
> http://wiki.opensslfoundation.com/ Great. It would be good to have a link pointing to this on the documents tab on openssl.org -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Wiki
With some trepidation, and considerable assistance from a small group of
earlier adopters, I hereby unleash a new OpenSSL Wiki on an unsuspecting
world:
http://wiki.opensslfoundation.com/
There is a need for more and better OpenSSL documentation, and the
hopeful theory here is that this Wiki will serve as a focal point for
collecting useful content that over time will converge into a useful and
comprehensive resource.
Since I and some of the initial collaborators are still learning about
Wiki management it will remain on a separate server and the
opensslfoundation.com domain for an indeterminate trial period. If it
evolves into a useful resource, and once we're comfortable with all the
security and technical implications, then we will migrate it to a
wiki.openssl.org domain. We're still in the process of migrating the
legacy openssl.org server to a new home and this Wiki is another
complication we don't need right now.
There is some content already but new contributions are welcome. We'll
be wanting to add some more administrators ("sysops") too.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Matt / List,
Thanks for the example. It sure helped a lot. But I am still stuck at the EC
key generation.
I've created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves
(233-571 bit). I then convert the keys to PEM using the same method which I
used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey()
and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What
is interesting now is that if I test the EC PEM files, using the openssl
command line tool, all the keys generated for the NIST Prime curves is
successfully parsed while the others fails with the following error:
$openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
139742524995232:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
139742524995232:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
139742524995232:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
139742524995232:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
I've noticed that writing the PEM files using the above mentioned mechanism
does not add the letters "EC" to the PEM header and footer of the private key
(e.g. -BEGIN EC PRIVATE KEY-- misses the "EC"). The spec seems to say
it must have these two characters. If I add the "EC" manually, I get the
following parsing error:
$ openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
140357067445920:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:tasn_dec.c:1319:
140357067445920:error:0D06C03A:asn1 encoding
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:831:
140357067445920:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:751:Field=privateKey, Type=EC_PRIVATEKEY
140357067445920:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC
lib:ec_asn1.c:1130:
140357067445920:error:100DE08E:elliptic curve
routines:OLD_EC_PRIV_DECODE:decode error:ec_ameth.c:565:
140357067445920:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
140357067445920:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
140357067445920:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
140357067445920:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
Any suggestions on why my binary curve keys are not validated?
Also can someone shed some light on the naming of the curves: Take for example
"NID_secp224r1". From the bits I can see that it is a NIST prime curve which is
also indicated by the 'p' (right?), which then makes me wonder why all the
binary curves has a 't' (e.g. NID_sect233r1). Next, to distinguish between the
NIST binary curves and the Kolbitz curves the only indication is that the
Kolbitz curve names ends with a 'k1' - is this correct? And if so what is the
'r' for then in the NIST prime and NIST binary numbers? And finally, why is
there not a NID_sect256r1, but rather a NID_X9_62_prime256v1?
Thanks again for a great mailing list
Leon Brits
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Matt Caswell
Sent: 15 March 2013 02:05 AM
To: openssl-dev@openssl.org
Subject: Re: EVP and Elliptic curve
On Thu, Mar 14, 2013, Leon Brits wrote:
> Hi List,
>
> I just want to verify: Elliptic curve functions are not encapsulated by the
> EVP functions - correct? If so, what is the
> EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT so,
> then please help with an example since I could only find the normal
> EC_{KEY,GROUP}* type of example code?
>
> I am required to perform ECDSA and was hoping I could use EVP which is now
> working for DSA and RSA (sans the padding problem).
>
As Steve has said, yes you can use ECDSA using EVP. The
EVP_PKEY_CTX_set_ec_paramgen_curve_nid is used during parameter generation.
Here is some sample code that uses it. Once you have an EVP_PKEY set up with a
type of EVP_PKEY_EC, then the code to do signatures should be pretty much
identical for DSA and ECDSA. This code generates a new key but you can equally
set it directly using EVP_PKEY_set1_EC_KEY. See the man page for further
details:
http://www.openssl.org/docs/crypto/EVP_PKEY_set1_RSA.html
EVP_PKEY *generate_key(int type)
{
EVP_PKEY_CTX *pctx = NULL, *kctx = NULL;
EVP_PKEY *params = NULL, *key = NULL;
/* Check whether we need to generate parameters first */
if(type == EVP_PKEY_EC || type == EVP_PKEY_DSA || type == EVP_PKEY_DH)
{
/* Create the context for generating the parameters */
if(!(pctx = EVP_PKEY_CTX_new_id(type, NULL))) goto err;
if(!EVP_PKEY_paramgen_init(pctx)) goto err;
/* Set the paramgen parameters according to the type */
switch(type)
{
case EVP_PKEY_EC:
Re: TPM decryption
Thanks Kent. I was able to modify create_tpm_key.c in the TPM engine project to set the PCR's for the new key. Tested fine using openssl s_server, then I extended one of the PCR's used to seal the key and tried s_server again, and it correctly failed to load the private key when attempting to accept an incoming connection. The TPM Engine uses Tspi_Data_Unbind for the RSA decryption during the handshake, which is perfect for what I'm doing. Jonathan On Mar 4, 2013, at 7:29 AM, Kent Yoder wrote: > On Sat, Mar 2, 2013 at 10:36 PM, Jonathan Buhacoff > wrote: >> Hi, >> >> I have a school project to make use of a TPM to store the server's RSA >> private key for use with openssl. Specifically, that private key would be >> sealed to certain PCR values that are also encoded in the X509 certificate >> so that, when clients make a TLS connection to the server, clients trusting >> that particular X509 certificate know that a connection can only be >> established if the server's state corresponds to the what is on the >> certificate. >> >> When a server needs to decrypt the client challenge in order to prepare the >> server-verify message, instead of loading its private key from disk and >> performing an RSA decryption, in this project the server would use the >> trousers library to pass the material to be decrypted to the TPM and get the >> results. Everything before and after this step should stay the same. >> >> I think the relevant code is in ssl3_get_client_key_exchange, because it >> calls RSA_private_decrypt. >> >> My question is - should I be writing a patch for the default engine to >> allow this option to keep the private key in the TPM? or should I be >> writing a new engine that is essentially a copy of the default engine except >> for this one change? What makes more sense if I'm going to contribute the >> code after my project is done? > > We have a TPM engine available on the trousers site: > > https://sourceforge.net/projects/trousers/files/OpenSSL%20TPM%20Engine/0.4.2/ > > We may not have a utility that lets you generate a key with PCRs > though. You can find lots of sample code in the testsuite, available > in git: > > git://trousers.git.sourceforge.net/gitroot/trousers/testsuite > > Kent > >> A related consideration is that the configuration would need to accommodate >> this option, either by allowing another format for the private key file >> option or by creating a new custom option. >> >> All opinions welcome... >> >> Thanks, >> >> Jonathan >> >> >> __ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org
