This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: exporting sha256 sha512
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Shawn Landden <shawnlandden at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 25 Mar 2015 12:12:29 -0400
- Subject: Re: RFC: exporting sha256 sha512
- Authentication-results: sourceware.org; auth=none
- References: <CAJusiZVeSiuBJ1NuWw9KU2fboKcz6-9s6YhiTHVga5GyW-bbFw at mail dot gmail dot com> <87mw31thl3 dot fsf at mid dot deneb dot enyo dot de>
On Wed, Mar 25, 2015 at 12:57:44PM +0100, Florian Weimer wrote:
> > #include <stdint.h>
> >
> > typedef struct {
> > char __internal_state[104];
> > } sha256_ctx;
>
> This needs some alignment declaration.
Agreed. And possibly some additional working room.
> > void *sha256(const void *d, size_t n, void *md);
> > void sha256_init(sha256_ctx *s);
> > void sha256_push(sha256_ctx *s, const void *d, size_t n);
> > void sha256_finish(sha256_ctx *s, void *md);
>
> push/finish is usually update/final.
Yes.
> To be more general, the context would have to be allocated on the
> heap, deallocation and clone functions would be required, and the
> functions need to return error values. Some hardware acceleration
> might need a larger state than 104 bytes.
Why should the caller not be allowed to manage the lifetime of the
context? The context is fixed-size, small, and has no compelling
reason it should need to be in allocated storage. As-designed (with
caller managing lifetime), there is no possibility of failure, and
thus no need for an API that can report failure (which would be much
harder to use correctly).
Rich