[Dovecot] Solaris hardware crypto engines

Chris Hoogendyk hoogendyk at bio.umass.edu
Tue Apr 19 00:18:41 EEST 2011


The attachment made the message too long for the forum. So I canceled the original. If you want the 
Sun article, you can google 05071387.pdf. The original went through to Martin.

On 4/18/11 5:02 PM, Chris Hoogendyk wrote:
> On 4/18/11 6:30 AM, Martin Preen wrote:
>> Hello,
>> I tried to find out how about to use the hardware crypto engines under
>> Solaris (Sun Fire T2000). It seems, that its not just a compilation issue:
>>
>>> For operations that are to be offloaded, it is necessary to restrict use to subset
>> > of OpenSSL functions (the EVP_ functions) and explicitly indicate the use of the PKCS11
>> > engine; something like the following works for bulk ciphers (the process for RSA is similar):
>>>
>>> ENGINE *e;
>>> ENGINE_load_builtin_engines();
>>> e = ENGINE_by_id("pkcs11");
>>> ENGINE_set_default_ciphers(e);
>>> EVP_CIPHER_CTX_init (&ctx);
>>> EVP_EncryptInit (&ctx, EVP_des_cbc (), key, iv);
>>> EVP_EncryptUpdate (.....);
>>
>> Since I'm not familiar with SSL programming, I wonder if it's possible to
>> modify the dovecot 1.2.x source code. Maybe someone has already tried this
>> or can give me hint.
>
> You don't want to do that.
>
> The objective is for the ssl engine to be low level and basically invisible to layers of 
> application above that use it. So, build openssl properly and it just works for everything else.
>
> I'm not at work today, so I don't have reference to my notes. Ah, just found an email I sent to my 
> colleagues -- copied it below.

-- 
---------------

Chris Hoogendyk

-
    O__  ---- Systems Administrator
   c/ /'_ --- Biology&  Geology Departments
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

<hoogendyk at bio.umass.edu>

---------------

Erdös 4



-------- Original Message --------
Subject:     building apps with ssl
Date:     Thu, 18 Mar 2010 11:30:42 -0400
From:     Chris Hoogendyk<hoogendyk at bio.umass.edu>


cool. I've got things working now so that I can build applications with
the openssl built by Sun to tap into the cryptographic accelerators on
the T2. It turns out that the /opt/coolstack stuff related to openssl is
actually symlinks to /usr/sfw. So, in the Makefile, if I set the openssl
directory to /usr/sfw, rather than the default /usr/local/openssl, it
finds the includes, the libraries, and the binaries that are needed.
Then I specifically point the certs directory (in the Makefile) to
/usr/local/openssl/certs for local control. Then, for the example of
uw-imap, everything builds just fine. This should simply apply to
anything we need to build with openssl on any of the T5220s. One side
note is that this was a custom Makefile. Applications that use
./configure would presumably find the openssl through the paths provided
in /usr/local/src/env.

In the process of figuring that out, I also found that one of the most
recent Solaris 10 kernel patches that we have on imladris specifically
addresses awareness of the crypto accelerators and included patches to
the openssl related items in /usr/sfw. So, I'm pretty confident that
everything is alright.

It's interesting too that in the paper presented at ACM by Sun last year
they said that a couple of classes of attacks on crypto processes were
negated by running it directly on the CPU. One of them had to do with
timing. I should forward that paper to you as well. OK, just attached it.



-- 
---------------

Chris Hoogendyk

-
    O__  ---- Systems Administrator
   c/ /'_ --- Biology&  Geology Departments
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

<hoogendyk at bio.umass.edu>

---------------

Erdös 4



More information about the dovecot mailing list