[openssl-dev] [crypto engine]: API users try to find separate external library for new engine
I'm trying to make a new crypto engine. Any application that tries to use my custom OpenSSL library that includes my engine gives me an error trying to find an external library for my new engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my engine), although if I run a "grep -R 'hwrng' . " in the install folder it finds references in the libcrypto.so . I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of times and in the same files. What could I be missing that cryptodev is loaded "naturally" (it knows it's inside libcrypto.so), but engine hwrng is seen as being something totally external? Cata ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine
Hi Cata, We solved this problem in our project: https://github.com/AtmelCSO/cryptoauth-openssl-engine I may be wrong but I think it was done using "export LD_LIBRARY_PATH=". Try it. If it will not work then you dig into our engine. Regards, Alex Gostrer On Wed, Feb 3, 2016 at 9:00 AM, Catalin Vasile <cata.vas...@nxp.com> wrote: > > > I'm trying to make a new crypto engine. > > Any application that tries to use my custom OpenSSL library that includes > my engine gives me an error trying to find an external library for my new > engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my > engine), although if I run a "grep -R 'hwrng' . " in the install folder it > finds references in the libcrypto.so . > > I have done a "grep -R 'cryptodev' ." and it is referenced the same amount > of times and in the same files. > What could I be missing that cryptodev is loaded "naturally" (it knows > it's inside libcrypto.so), but engine hwrng is seen as being something > totally external? > > > Cata > > > > ___ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [crypto engine]: API users try to find separate external library for new engine
I'm trying to make a new crypto engine. Any application that tries to use my custom OpenSSL library that includes my engine gives me an error trying to find an external library for my new engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my engine), although if I run a "grep -R 'hwrng' . " in the install folder it finds references in the libcrypto.so . I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of times and in the same files. What could I be missing that cryptodev is loaded "naturally" (it knows it's inside libcrypto.so), but engine hwrng is seen as being something totally external? Cata ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] procedure for adding new engine registration
If your engine's 'destroy' isn't being invoked, you might want to have a look at what ENGINE_remove() does, and ultimately, engine_free_util() (found in crypto/engine/eng_lib.c). Those should be called as part of ENGINE_cleanup(). Cheers, Richard In message <by1pr0301mb1238bbc6da68672c825a070488...@by1pr0301mb1238.namprd03.prod.outlook.com> on Wed, 9 Dec 2015 06:10:13 +, Vemulapalli Jyothi <jyoth...@freescale.com> said: jyothi.v> Hi Matt, jyothi.v> jyothi.v> We could successfully execute dynamic engine support. jyothi.v> Thanks for help. jyothi.v> jyothi.v> One issue regarding cleanup. jyothi.v> When I gone through openssl cleanup (ie apps_shutdown() or engine interface cleanup ) functionality, I see that there are two function pointers that can set to ENGINE interface: destroy and finish. jyothi.v> jyothi.v> But after completion of openssl command execution or when invoking quit from openssl utility, these function pointers are not getting invoked. jyothi.v> In apps_shutdown(), I can see the call to ENGINE_cleanup(). But this cleanup is internal to openssl library. How can we set our engine de-init function pointer to openssl, where it should be invoked part of apps_shutdown() call. jyothi.v> jyothi.v> We are using openssl-1.0.1g version. jyothi.v> jyothi.v> Can you please give us some data on this. jyothi.v> jyothi.v> Thank you, jyothi.v> Jyothi jyothi.v> jyothi.v> jyothi.v> jyothi.v> -Original Message- jyothi.v> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell jyothi.v> Sent: Friday, November 13, 2015 5:14 PM jyothi.v> To: openssl-dev@openssl.org jyothi.v> Subject: Re: [openssl-dev] procedure for adding new engine registration jyothi.v> jyothi.v> jyothi.v> jyothi.v> On 13/11/15 11:16, Vemulapalli Jyothi wrote: jyothi.v> > Hi Matt, jyothi.v> > jyothi.v> > Very useful information. jyothi.v> > jyothi.v> > I too agree with you that we need not have a new engine distribution. jyothi.v> > jyothi.v> > I see some options like dynamic engines and static engine support. jyothi.v> > jyothi.v> > If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. jyothi.v> jyothi.v> As follows (on Linux): jyothi.v> jyothi.v> OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine jyothi.v> jyothi.v> jyothi.v> Matt jyothi.v> jyothi.v> ___ jyothi.v> openssl-dev mailing list jyothi.v> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev jyothi.v> ___ jyothi.v> openssl-dev mailing list jyothi.v> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev jyothi.v> ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] procedure for adding new engine registration
Thanks Matt. We will try. Best regards Jyothi -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 13, 2015 5:14 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] procedure for adding new engine registration On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface, how can we do speed > test using openssl speed command. As follows (on Linux): OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] procedure for adding new engine registration
Hi Matt, Very useful information. I too agree with you that we need not have a new engine distribution. I see some options like dynamic engines and static engine support. If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. Thanks Jyothi -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 13, 2015 3:25 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] procedure for adding new engine registration On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not getting compiled. > > Do we need to give some additional options. Can you please help. Its not clear to me whether your asking "how do I create my own engine for my own purposes?" or "how do I create an engine that I want to get incorporated into the OpenSSL source and be distributed as part of OpenSSL?". The answers to these two questions are slightly different. For the former question I suggest you start with these two links: https://www.openssl.org/blog/blog/2015/10/07/engine-school/ https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ There's also some content on the wiki on this topic: https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms For the latter question the technical procedure is essentially the same as above. However I am personally not keen on the introduction of new engines that do not have a broad applicability to large groups of users. That would typically rule out the introduction of manufacturer specific engines requiring the presence of additional hardware. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] procedure for adding new engine registration
On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface, how can we do speed > test using openssl speed command. As follows (on Linux): OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] procedure for adding new engine registration
On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not getting compiled. > > Do we need to give some additional options. Can you please help. Its not clear to me whether your asking "how do I create my own engine for my own purposes?" or "how do I create an engine that I want to get incorporated into the OpenSSL source and be distributed as part of OpenSSL?". The answers to these two questions are slightly different. For the former question I suggest you start with these two links: https://www.openssl.org/blog/blog/2015/10/07/engine-school/ https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ There's also some content on the wiki on this topic: https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms For the latter question the technical procedure is essentially the same as above. However I am personally not keen on the introduction of new engines that do not have a broad applicability to large groups of users. That would typically rule out the introduction of manufacturer specific engines requiring the presence of additional hardware. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] procedure for adding new engine registration
Hi all, We would like to add a new engine registration to openssl. Can you please explain a procedure? When we gone through the code, we could find an engines directory in openssl , but those files are not getting compiled. Do we need to give some additional options. Can you please help. Thanks Jyothi ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Adding a new Engine to OpenSSL
My understanding is as there are some similarities between my device and cryptodev device, i may follow the cryptodev. Is it right? If we want to take reference from any other engine iam not getting any similarity between my engine and any one from already implemented. If i go through with pkcs11 then please suggest any url or share any documents which will help me as i am new to this. Thanks Animesh Das On 15 May 2015 22:18, David Woodhouse dw...@infradead.org wrote: On Fri, 2015-05-15 at 17:17 +0530, Animesh Das wrote: I have a new hardware crypto engine. The device can be accessed from user space application opening the device like /dev/mydevice. There are also some IOCTLs which can be used from user space. I want to add that device as one of the engines of OpenSSL so that the encryption/decryption process can be offloaded to that device. I have new to OpenSSL. Could you please help me giving ideas/steps to add that engine in OpenSSL. My first inclination is to say don't. Make it a PKCS#11 provider instead, and let OpenSSL use it through engine_pkcs11. (OpenSSL really ought to gain first-class support for PKCS#11 too, FWIW). -- dwmw2 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Adding a new Engine to OpenSSL
On 15/05/15 12:47, Animesh Das wrote: Hi, I have a new hardware crypto engine. The device can be accessed from user space application opening the device like /dev/mydevice. There are also some IOCTLs which can be used from user space. I want to add that device as one of the engines of OpenSSL so that the encryption/decryption process can be offloaded to that device. I have new to OpenSSL. Could you please help me giving ideas/steps to add that engine in OpenSSL. Take a look at: demos/engines/rsaref/rsaref.c Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Adding a new Engine to OpenSSL
On Fri, 2015-05-15 at 17:17 +0530, Animesh Das wrote: I have a new hardware crypto engine. The device can be accessed from user space application opening the device like /dev/mydevice. There are also some IOCTLs which can be used from user space. I want to add that device as one of the engines of OpenSSL so that the encryption/decryption process can be offloaded to that device. I have new to OpenSSL. Could you please help me giving ideas/steps to add that engine in OpenSSL. My first inclination is to say don't. Make it a PKCS#11 provider instead, and let OpenSSL use it through engine_pkcs11. (OpenSSL really ought to gain first-class support for PKCS#11 too, FWIW). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
RE: adding a new engine
Hello Jim, You can look at sample engines located under src/openssl-0.9.8h/engines e.g. e_atalla.c e_chil.c etc. You would get an idea about the framework and overriding the default methods. -Sitanshu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Gibbons Sent: Sunday, November 23, 2008 4:45 AM To: openssl-dev@openssl.org Subject: adding a new engine Is there documentation and/or an example of this? If this is a question better suited for the users group, please let me know. Thanks for your help. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
adding a new engine
Is there documentation and/or an example of this? If this is a question better suited for the users group, please let me know. Thanks for your help. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
New Engine
Hi, When adding a new engine to openssl, is it necessary to add an entry to engine_internal_check in engine_list.c and rebuild, or is there some way to dynamically add a new engine. Thanks, Diarmuid. _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: New Engine
From: "Diarmuid Oneill" [EMAIL PROTECTED] diarmuidoneill When adding a new engine to openssl, is it necessary diarmuidoneill to add an entry to engine_internal_check in diarmuidoneill engine_list.c and rebuild, or is there some way to diarmuidoneill dynamically add a new engine. ENGINE_new() followed by a number of ENGINE_set_*() followed by ENGINE_add(engine). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Geoff Thorpe wrote: On Tue, 31 Oct 2000, Ben Laurie wrote: Yes, your answer is satisfactory. If I understand then I can't use openssl.exe main application for testing my new engine (of course after compilation of openssl with new engine features). Exactly, and this is wrong and bad. We should fix it. Enough of the one liners already - go ahead and fix it! Sheesh! Well, the main point is to decide how it should be fixed - once that's done it should be easy, right? This is not *that* big a deal anyhow. Anything that could be assumed as far as default values for initialising an ENGINE can be set by the author of the implementation. Anything that needs to be pulled out of some kind of environment specific to the ENGINE (eg. registry or configs relating to the engine-specific "thing") can also be pulled out by the implementation (and its author). Which leaves us with the only worthwhile point made in this little exchange so far, namely, that it should be possible to set various things inside OpenSSL config files that could be passed into the ENGINEs like a batch file. This *can* be done, but it depends how you choose syntatically to do it ... numerically isn't so hot except for "generic" parameter types that can be defined in OpenSSL once and stay fixed (which is not likely to be the case often IMHO). On the other hand, doing it string based might be ugly too. Anyway, some way of batching a series of ENGINE_ctrl() functions by way of config files could be done. The case that started this deals with some kind of engine implementation that requires a hostname, username, and password. That's hardly typical for engines (so far) - and if any such thing as "default values" for those settings exists on that system, it's very likely they're stored somewhere in the environment that controls (or administers) the stuff that engine deals with. So the "requirement" that they be specified by OpenSSL config files is at best a nice-to-have, but hardly a showstopper. Your comment that; Leaves me with one - if specific engines have to be initialised "by hand", then we haven't got much in the way of abstraction, have we? Is there a better way? Config files? External programs? is a little simplisitic, as have been most of the bite(yte)-sized comments thus far; "to make the engine go" (as you said in another post) requires whatever the engine's purpose dictates and whatever the environment it operates in dictates. If defaults can be assumed, then by definition they can be used inside the engine implementation to obviate the need for ENGINE_ctrl()ing. Likewise if the defaults *exist* somewhere, they can equally be pulled out automatically. The only issue is whether this can or should be driven by generic OpenSSL-based settings rather than ENGINE-specific settings. Well, the point is that if I have some application that uses OpenSSL to provide crypto, I shouldn't have to modify the application in order to be able to use a specific engine, in an ideal world. Other possible cases of engines requiring settings are equally likely to require smart cards, paths, one-time-pad keys, retina-scans, filenames, network addresses, challenge-response variants, hardware settings, system settings, system limitations (eg. RAM, disk caching, whatever), UIDs, PINs, IRQs, DMAs, and probably a tonne of other things. There should be some way to feed arbitrary name-value pairs into an ENGINE perhaps, maybe an ENGINE_ctrl_ext() or some such variant, but the lack of that feature thus far is hardly "not much in the way of abstraction", and likewise the addition of that feature is not going to make such a general problem go away. BTW: Right now, all the existing engine implementations typically work immediately without any "setup" beyond what they work out for themselves before, during, or after initialisation. This is true. But clearly there are other engines where this isn't the case. Anyway, I think the idea of driving ENGINE_ctrl()s from the configuration isn't so good, because it leads to obscure configuration. Probably its better to pass a configuration handle into the ENGINE_init() and let it pick up whatever it needs from there itself? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Geoff Thorpe wrote:
On Tue, 31 Oct 2000, Ben Laurie wrote:
BTW: Right now, all the existing engine implementations typically work
immediately without any "setup" beyond what they work out for themselves
before, during, or after initialisation.
Indeed, but its possible to imagine various engines that require rather
complex settings possibly on a per instance basis. Lets say for example
we have a PKCS#11 engine. It might need to know the location of the
PKCS#11 library, whether to login immediately and probably a bunch of
other things I haven't thought of yet. We might also have multiple
instances using separate PKCS#11 libraries too.
IMHO a situation to avoid is one where this kind of thing is handled
only via engine specific ENGINE_ctrl() functions such that an engine
aware application needs to be modified to handle newer engines.
I can think of several ways of handling this. One is to just give the
engine access to a config file and let it decide how to interpret it. At
an application level we could have (say) an ENGINE_load_config() high
level function that can be used to decide which engines to load, some
things like default methods to override and sections containing engine
specific configuration.
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
Would carve the way to store the engine configuration in stone...
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
or you can encode the parameters into string and pass this string around.
file-based configuration is not always the best.
every engine will have two APIs: common and private. private API is for
configuration. for example in case of pkcs#11 engine the private API
allows one to select pkcs#11 library to be loaded, enumerate slots, tokens
and keys. finally there is function which will encode the parameters into
string (like d:\program files\smart card vendor\pkcs11\api.dll,0,0,"the
key"). this string is then passed to application which will use it to
access private key in uniform fashion by passing the string through common
API to engine, which will decode it and act appropriately.
the private API is useful for GUI applications which may want to allow
browsing through your keys and it is optional. if the selector-string
encoding is documented then you can create this string manualy.
arne
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
The reason I suggested a handle instead of a filename was so that the
data could come from elsewhere.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit."
Robert Woodruff
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
Ben Laurie wrote:
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
The reason I suggested a handle instead of a filename was so that the
data could come from elsewhere.
Well whatever... I was just using that as an example. The whole point is
that if an application writer doesn't want or have time to look into how
ENGINEs work they can make a simple call and some basic functionality
(crypto acceleration for example) is supported.
Arne Ansper wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
or you can encode the parameters into string and pass this string around.
file-based configuration is not always the best.
No it isn't always the best but having a simple string could get very
messy if lots of information needs to be passed around. Maybe something
a bit like the extension code. You can pass a simple string but if that
isn't sufficient the engine can access other information from the CONF
pointer (which need not refer to a config file).
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: new engine
On Tue, 31 Oct 2000, Libor Krystek wrote: I'am creating new engine for other hardware. This hardware must be initialized before using but for its initialization I need input some parameters (e.g. hostname, username, password). Function ENGINE_init(ENGINE *e) call engine function init() and it have no input parameters. How can I do it? Do you have any conception? ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. ENGINE_init() is used to get a "functional" reference, not just a "structural" one. Eg. ENGINE_by_id() returns only a structural reference - so using that you can call ENGINE_ctrl() to initialise whatever you need. It is only when a structural reference is required that the ENGINE's "init" handler will be called to try and make the ENGINE actually get ready to work. This typically happens by calling ENGINE_init() directly, or something implicit like "ENGINE_set_default()" that requires the ENGINE be "working". For structural references, the ENGINE's own functions are never called - that's so that you can still look around the various ENGINEs available even though many of them won't be supported on your host system (because of lack of drivers, vendor libraries, etc). Does that answer your question? Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Geoff Thorpe wrote: ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. ENGINE_init() is used to get a "functional" reference, not just a "structural" one. Eg. ENGINE_by_id() returns only a structural reference - so using that you can call ENGINE_ctrl() to initialise whatever you need. It is only when a structural reference is required that the ENGINE's "init" handler will be called to try and make the ENGINE actually get ready to work. This typically happens by calling ENGINE_init() directly, or something implicit like "ENGINE_set_default()" that requires the ENGINE be "working". For structural references, the ENGINE's own functions are never called - that's so that you can still look around the various ENGINEs available even though many of them won't be supported on your host system (because of lack of drivers, vendor libraries, etc). Does that answer your question? Yes, your answer is satisfactory. If I understand then I can't use openssl.exe main application for testing my new engine (of course after compilation of openssl with new engine features). Bye. -- Libor Krystek PVT, a.s., Radnicka 14, 602 00 Brno, Czech Republic email: [EMAIL PROTECTED] tel.: +420-5-42217380 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Geoff Thorpe wrote: On Tue, 31 Oct 2000, Libor Krystek wrote: I'am creating new engine for other hardware. This hardware must be initialized before using but for its initialization I need input some parameters (e.g. hostname, username, password). Function ENGINE_init(ENGINE *e) call engine function init() and it have no input parameters. How can I do it? Do you have any conception? ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. ENGINE_init() is used to get a "functional" reference, not just a "structural" one. Eg. ENGINE_by_id() returns only a structural reference - so using that you can call ENGINE_ctrl() to initialise whatever you need. It is only when a structural reference is required that the ENGINE's "init" handler will be called to try and make the ENGINE actually get ready to work. This typically happens by calling ENGINE_init() directly, or something implicit like "ENGINE_set_default()" that requires the ENGINE be "working". For structural references, the ENGINE's own functions are never called - that's so that you can still look around the various ENGINEs available even though many of them won't be supported on your host system (because of lack of drivers, vendor libraries, etc). Does that answer your question? Leaves me with one - if specific engines have to be initialised "by hand", then we haven't got much in the way of abstraction, have we? Is there a better way? Config files? External programs? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
From: Ben Laurie [EMAIL PROTECTED] ben Does that answer your question? ben ben Leaves me with one - if specific engines have to be initialised "by ben hand", then we haven't got much in the way of abstraction, have we? Is ben there a better way? Config files? External programs? Depends on what you mean. Each engine will probably come with it's own set of programs to handle it (for example, with CHIL, you have to create private keys in the box with the programs that come with said box, there's no way OpenSSL can support that operation), so external programs is one answer... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Ben Laurie wrote: Geoff Thorpe wrote: On Tue, 31 Oct 2000, Libor Krystek wrote: I'am creating new engine for other hardware. This hardware must be initialized before using but for its initialization I need input some parameters (e.g. hostname, username, password). Function ENGINE_init(ENGINE *e) call engine function init() and it have no input parameters. How can I do it? Do you have any conception? ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. [...] Leaves me with one - if specific engines have to be initialised "by hand", then we haven't got much in the way of abstraction, have we? Is there a better way? Config files? External programs? something like [ENGINE_ENTRY_xyz] ctrl_0 = 1234,LONG:42 ctrl_1 = 0xff,DATA:hex_data [...] resulting in something like: ... ENGINE_ctrl(engine,1234,42,0,0); ENGINE_ctrl(engine,0xff,0,data,0); ... By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Goetz Babin-Ebell wrote: Ben Laurie wrote: Geoff Thorpe wrote: On Tue, 31 Oct 2000, Libor Krystek wrote: I'am creating new engine for other hardware. This hardware must be initialized before using but for its initialization I need input some parameters (e.g. hostname, username, password). Function ENGINE_init(ENGINE *e) call engine function init() and it have no input parameters. How can I do it? Do you have any conception? ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. [...] Leaves me with one - if specific engines have to be initialised "by hand", then we haven't got much in the way of abstraction, have we? Is there a better way? Config files? External programs? something like [ENGINE_ENTRY_xyz] ctrl_0 = 1234,LONG:42 ctrl_1 = 0xff,DATA:hex_data [...] resulting in something like: ... ENGINE_ctrl(engine,1234,42,0,0); ENGINE_ctrl(engine,0xff,0,data,0); ... That's the kind of thing I had in mind - or, better, engines could define their own config fields. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Richard Levitte - VMS Whacker wrote: From: Ben Laurie [EMAIL PROTECTED] ben Does that answer your question? ben ben Leaves me with one - if specific engines have to be initialised "by ben hand", then we haven't got much in the way of abstraction, have we? Is ben there a better way? Config files? External programs? Depends on what you mean. Each engine will probably come with it's own set of programs to handle it (for example, with CHIL, you have to create private keys in the box with the programs that come with said box, there's no way OpenSSL can support that operation), so external programs is one answer... No, I meant stuff that needs to be done within OpenSSL to make the engine go. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
Libor Krystek wrote: Geoff Thorpe wrote: ENGINE_ctrl(); make your "init()" handler fail (setting an explanatory error) unless ENGINE_ctrl() has already been called to pass in everything you need. ENGINE_init() is used to get a "functional" reference, not just a "structural" one. Eg. ENGINE_by_id() returns only a structural reference - so using that you can call ENGINE_ctrl() to initialise whatever you need. It is only when a structural reference is required that the ENGINE's "init" handler will be called to try and make the ENGINE actually get ready to work. This typically happens by calling ENGINE_init() directly, or something implicit like "ENGINE_set_default()" that requires the ENGINE be "working". For structural references, the ENGINE's own functions are never called - that's so that you can still look around the various ENGINEs available even though many of them won't be supported on your host system (because of lack of drivers, vendor libraries, etc). Does that answer your question? Yes, your answer is satisfactory. If I understand then I can't use openssl.exe main application for testing my new engine (of course after compilation of openssl with new engine features). Exactly, and this is wrong and bad. We should fix it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new engine
On Tue, 31 Oct 2000, Ben Laurie wrote: Yes, your answer is satisfactory. If I understand then I can't use openssl.exe main application for testing my new engine (of course after compilation of openssl with new engine features). Exactly, and this is wrong and bad. We should fix it. Enough of the one liners already - go ahead and fix it! Sheesh! This is not *that* big a deal anyhow. Anything that could be assumed as far as default values for initialising an ENGINE can be set by the author of the implementation. Anything that needs to be pulled out of some kind of environment specific to the ENGINE (eg. registry or configs relating to the engine-specific "thing") can also be pulled out by the implementation (and its author). Which leaves us with the only worthwhile point made in this little exchange so far, namely, that it should be possible to set various things inside OpenSSL config files that could be passed into the ENGINEs like a batch file. This *can* be done, but it depends how you choose syntatically to do it ... numerically isn't so hot except for "generic" parameter types that can be defined in OpenSSL once and stay fixed (which is not likely to be the case often IMHO). On the other hand, doing it string based might be ugly too. Anyway, some way of batching a series of ENGINE_ctrl() functions by way of config files could be done. The case that started this deals with some kind of engine implementation that requires a hostname, username, and password. That's hardly typical for engines (so far) - and if any such thing as "default values" for those settings exists on that system, it's very likely they're stored somewhere in the environment that controls (or administers) the stuff that engine deals with. So the "requirement" that they be specified by OpenSSL config files is at best a nice-to-have, but hardly a showstopper. Your comment that; Leaves me with one - if specific engines have to be initialised "by hand", then we haven't got much in the way of abstraction, have we? Is there a better way? Config files? External programs? is a little simplisitic, as have been most of the bite(yte)-sized comments thus far; "to make the engine go" (as you said in another post) requires whatever the engine's purpose dictates and whatever the environment it operates in dictates. If defaults can be assumed, then by definition they can be used inside the engine implementation to obviate the need for ENGINE_ctrl()ing. Likewise if the defaults *exist* somewhere, they can equally be pulled out automatically. The only issue is whether this can or should be driven by generic OpenSSL-based settings rather than ENGINE-specific settings. Other possible cases of engines requiring settings are equally likely to require smart cards, paths, one-time-pad keys, retina-scans, filenames, network addresses, challenge-response variants, hardware settings, system settings, system limitations (eg. RAM, disk caching, whatever), UIDs, PINs, IRQs, DMAs, and probably a tonne of other things. There should be some way to feed arbitrary name-value pairs into an ENGINE perhaps, maybe an ENGINE_ctrl_ext() or some such variant, but the lack of that feature thus far is hardly "not much in the way of abstraction", and likewise the addition of that feature is not going to make such a general problem go away. BTW: Right now, all the existing engine implementations typically work immediately without any "setup" beyond what they work out for themselves before, during, or after initialisation. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
