lkml.org 
[lkml]   [2003]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH CIFS] use CryptoAPI MD4/MD5
On Sat, 4 Oct 2003, Matt Mackall wrote:

> On Sat, Oct 04, 2003 at 11:00:01AM -0700, dean gaudet wrote:
> > what about CryptoAPI is so expensive that you can't use a stack-based
> > context?
>
> The alloc functions hide a bunch of module lookup details and the size
> of the context structures vary from one alg to the next. They also
> tend to hide block-sized buffers to deal with fragments. So it's a
> little ugly but not insurmountable.

by "block-sized" you mean like 64 bytes for MD5 and SHA1, 16 bytes for
AES, and so forth? if so that's no biggie, those are already present
in most simple library implementations of these algos. but if "block"
means 4096 bytes then, aiee.

if module lookup is expensive then perhaps a much better api would be one
which yields a module handle -- and the module handle can be used in a
much less expensive allocator to create contexts where they're required.
it seems that the module handle could be a read-only structure and
therefore shared without locking.


> > this seems pretty dumb converting a stack-based md5 context to multiple
> > instances in multiple structures.
> >
> > the stack is almost guaranteed to be in L1 cache.
> >
> > multiplying that structure by N connections is just a waste of memory
> > bandwidth. not to mention the locking crud you seem to need to do... the
> > stack is implicitly locked.
> >
> > is CryptoAPI really this broken?
>
> It's a bit inflexible in this regard, yes.

this really sounds like two steps backwards and one step forward.

this CIFS patch alone replaces 89 lines with 250 lines of code! the new
code does not look anywhere near as readable as the original. but perhaps
that's just because i've dealt with the same trivial MD5Init/Update/Final
API for years.

i gather a lot of this comes from the desire to have run-time selectable
sw and hw implementations of various algorithms for "optimal" performance.
but there generally isn't an optimal algorithm for all situations.
for small short digests like passwords it's probably more overhead to
use the cryptoapi than is saved from any blindingly fast implementation
behind the scenes.

-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.378 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site