ENGINE has been enabled by default in OpenSSL in Android since 4.1 jellybean. I think it was on in cupcake, donut, eclair as well, but off for froyo, gingerbread, honeycomb, and ICS just because it wasn't needed. it is not likely to go off again since the hardware keystore support relies on it.
I've lost the context here, but if you are doing platform work, you could always have changed the openssl build options anyway. if you are bundling this in an app, you need to bundle your open openssl anyway since its not part of the NDK and not a stable API, and then you can build openssl anyway you want. -bri On Tue, Aug 27, 2013 at 10:12 AM, tera tellence <tellt...@googlemail.com> wrote: > Just a note here Brian, > > Is ENGINE enabled by default in OpenSSL in Android? I think not! > Which means I have to recompile it on Android. Also what about Security > Providers? Should they not be added to the core.jar and rebuilt? > > -TT > > > On Fri, Oct 28, 2011 at 8:22 AM, Brian Carlstrom <b...@google.com> wrote: >> >> On Thu, Oct 27, 2011 at 10:55 PM, rajesh banginwar >> <rajeshbangin...@yahoo.com> wrote: >>> >>> So, I see two options to expose my HW crypto accelerators to apps. >> >> >> a third option is it make it available to the kernel >> >>> >>> One is thr' openSSL engine interface >> >> >> i would do this, there is a lot of native code for vpn, wifi, etc, which >> all are using openssl >> >>> >>> and other is Android crypto service provider. I am trying to understand >>> which option is better or is openSSL engine sufficient? >> >> >> if you did the openssl work, then you could write the provide wrappers. >> >>> specifically talking about crypto: how often AES or SHA is used for >>> example by Marketplace apps? >> >> >> I don't know, but again I've seen no issues. SHA1 et al are already backed >> by OpenSSL. What would they be using AES for? if its for network traffic, >> they are using SSLSocket backed by OpenSSL. if its for local crypto, why are >> they doing that? >> >>> >>> Since these don't go thr' openSSL (bouncy castle has java based native >>> implementation), have you heard about performance complaints here? >> >> >> SHA1 does go through OpenSSL. native is C/C++/assembly, so I don't know >> what you mean here, unless you are saying some of the bouncycastle code >> calls into native code for openssl. >> >> I haven't heard complaints, but if it was a problem for a market app, the >> presumably used something like openssl via the NDK, especially since they >> will want it to have worked on existing devices. >> >> -bri >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Android Security Discussions" group. >> To post to this group, send email to >> android-security-discuss@googlegroups.com. >> To unsubscribe from this group, send email to >> android-security-discuss+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/android-security-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscr...@googlegroups.com. To post to this group, send email to android-security-discuss@googlegroups.com. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/groups/opt_out.
