I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412,
and I am facing some (minor?) difficulties.

In old days, hadware (HW) can only do basic hash block operation,
so at the end it needed to finalize hash, and driver need to
write some bits into buffer to get message hash. Time passes,
and hardware (HW) was designed with improved cappabilities,
so it can add itself bits after message and calculate hash,
it can stop then export state, import and resume,
but ... it can not process null-length (or zero-length) ending.
So there is no more final method.

It must be feeded with at least one message byte to produce hash.

One more constrain is to process data in constant-sized chunks,
here it is 64 bytes, the same as for AES block,
i.e. it cannot stop and export state while in middle of block,
example - if we feed 16 bytes, we must then feed 48 bytes
to stop, but ideally we should feed it always 64 bytes.

Some crypto drivers with similar problem(s):

omap-sham.c - no final and blocksize needed,
broadcom bcm/spu.c - no final,
ccp/ccp-crypto-sha.c - no final,
nx/nx-sha256.c - blocksize needed,

One more thing - in algorithm description for methods:
final, finup, update, digest, export, import
there is note that finup is for those hardware 
that cannot do final, but again,

it looks like crypto framework is ignoring that and every finup
is translated into "update, final".

HW driver will do opposite - it will translate final into finup.

>From this follows that for every such HW crypto drivers authors
duplicate code for keeping at least blocksize cache of message.

One more point - use of block size in algo structure.
It is for informing framework about HW limitation, 
but seems to be ignored again...

Any suggestions ?

Can i keep some bytes unfeeded from ahash_request 
and return -EINPROGRESS ?
Should i set timer and copy rest bytes after some timeout,
where no more requests are incoming ? Or not ? cause it is 
async mode ? 
can i wait for more requests for processing waiting one ?

Best regards,
Kamil Konieczny
Samsung R&D Institute Poland

Reply via email to