This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: exporting sha256 sha512
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Shawn Landden <shawnlandden at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 25 Mar 2015 12:57:44 +0100
- Subject: Re: RFC: exporting sha256 sha512
- Authentication-results: sourceware.org; auth=none
- References: <CAJusiZVeSiuBJ1NuWw9KU2fboKcz6-9s6YhiTHVga5GyW-bbFw at mail dot gmail dot com>
* Shawn Landden:
> we already have this in crypt
> proposed public header <sha2.h> below
>
> even git does not use Intel processor extensions. This stuff in
> non-trivial and there is lots of duplicated work being done. Makes
> sense for glibc to be "high performance" as advertised and collect
> this performance work.
>
> would a patch for this be considered?
>
> #pragma once
Installed headers cannot use âpragma #onceâ.
> #include <stdint.h>
>
> typedef struct {
> char __internal_state[104];
> } sha256_ctx;
This needs some alignment declaration.
> 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.
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.