> > But after examining SSL code I've realized that SSL layer *always* feeds
> > libcrypto with *unaligned* data:-( So I'm considering to tweak the SSL
> > code so that message payload gets aligned at 64-bit boundary. But before
> > I do so I'd like to hear opinions on this.
>
> Sounds like a good idea, so long as it is optional... why? Coz people
> keep wanting to cram it into embedded systems where space is at a
> premium.
>
> It ought to be easy to provide an aligned_malloc() function that is
> optionally just malloc(), right?
Well, it probably ought to be called unaligned_malloc() then. Let me
explain it a little bit better. As we know malloc() always returns a
pointer "suitably aligned for any use." Now let's say I have SSLv3
connection negotiated. I've allocated a buffer with malloc, it's (at
least) 64 bit aligned, I read/write chunks of data... Now the point is
that SSLv3 header is 5 bytes long and the rest is the message to be
decrypted/encrypted which makes it (pointer argument passed to
libcrypto.a) unaligned. My idea is to adjust pointer to buffer I
read/write data to/from so that ptr+5 will be 64-bit aligned instead of
ptr. Yes, I'll have to pass SSL3_RT_MAX_PACKET_SIZE+3 to malloc)_. But
would it increase memory consumption? Absolutely not because malloc()
shall *pad* SSL3_RT_MAX_PACKET_SIZE up to the size I'm asking for
anyway! The only penalties I face here would be those arising from
copying between unaligned buffer in the user space and aligned buffer in
the kernel space in read/write system calls. And that's what I'll have
to weight against each other. I mean penalties from unaligned<->aligned
copy and gains from faster encryption/decryption pass. On the other hand
one unaligned<->aligned copy is very likely to take place already,
because (let's take receive case) after decryption plain text message
gets copied to user supplied buffer which is very likely to be aligned,
right? Now the latter copy becomes aligned<->aligned, i.e. penalties are
simply get shifted to kernel mode...
SSLv2 is more tricky as the header is of variable length... And as a
matter of fact I haven't look at it very close yet. As an alternative
(to looking at it:-) we can simply declare SSLv3 as "high performance
protocol" and one to be prefered to SSLv2 now even for performance
reasons:-)
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
