Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view



----- Original Message -----

From: Marco GRELLA <[hidden email]>

Date: Monday, February 27, 2006 2:29 pm

Subject: Problems with OpenSSL Engine and hashing.

> Hello everybody,

> I have a problem in making our OpenSSL Engine that drives our HW
> accelerator work fine for hash (SHA1 in particular).
> The problem seems to be related to my "Digest_Copy" or (less likely)
> "Digest_Cleanup" implementation (I'll explain this further on).
> The Engine works fine for the Cipher algorithms (both just
> operating on
> a file and using s_client/s_server), and works fine for SHA1 when
> operating on a file.
> Trying to run an s_client / s_server session, I noticed that multiple
> context are used and the calls to "Digest_Update" function are
> mixed, so
> I have to maintain coherency in some way.
> - 1 -
> The easiest (and quickest) way to do this is to buffer the data
> that I
> receive at each call to "Digest_Update", for each context, and ask
> for a
> real hash operation only when I receive the "Digest_Final" for

> that context.
> Doing in this way, everything is ok, both operating on a single file
> (here only one context is used) and using s_client / s_server
> (multiplecontexts).
> In this scenario, in the "Digest_Copy" function I make a "memcopy" of
> the EVP_MD_CTX->md_data field where our data structure sits, and
> moreover I manually allocate and copy the buffer in which I am keeping
> the stored data.
> In the "Digest_Cleanup" I make a "free" of the buffer in which I keep
> the data (it is dynamically allocated) and I set to zero the counters
> used to keep track of its size and actual occupation.
> In this way, as I said, everything works.
> - 2 -
> The previous solution is mainly a workaround and has a big
> disadvantageif you want to hash large files or amount of data. So
> I decided to use

> the capability of our HW accelerator to save and restore the current
> context of the hash block. Here I have some problem, when using
> s_client/ s_server. Even if I implement it in the most trivial and
> inefficient way (RESTORE/UPDATE/SAVE at *each* call to update) it does
> not work.
> In this scenario, we have a buffer for the context in our data
> structure. I allocate this buffer at the first call to
> "Digest_Update",obviously not setting the RESTORE flag for this
> first call.
> I call "free" for this buffer and put it to NULL in the
> "Digest_Cleanup"function and, if this buffer is valid (not null) I
> copy it in the
> "Digest_Copy" function, by allocating a proper memory area in the "to"
> context.
> If I use this solution on a single file, it works, so the SAVE/RESTORE
> mechanism works fine (and it has been proved elsewhere). But it

> fails in
> the s_client/s_server test. As the main difference is that here the
> "Digest_Copy" and "Digest_Cleanup" function are called, I suppose the
> problem is here, even if I do not see many differences with the
> scenarionumber -1-
> What am I missing?
> Could you help me?
> Can someone point me to some useful resource or describe me
> exactly what
> has to be implemented in the Digest_Copy (and Digest_Cleanup)
> function?Or do you know another way to avoid the problem of "mixed
> context"? I mean:
> sha1_init(ctx_A)
> sha1_update(ctx_A)
> sha1_init(ctx_B)
> sha1_update(ctx_B)
> sha1_update(ctx_A)
> ....
> Thank you very much and best regards,
> Marco Grella
> ______________________________________________________________________
> OpenSSL Project
> User Support Mailing List [hidden email]
> Automated List Manager [hidden email]
> ______________________________________________________________________ OpenSSL Project User Support Mailing List [hidden email] Automated List Manager [hidden email]