On Thu, Oct 27, 2011 at 10:55 PM, rajesh banginwar < [email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
