[FFmpeg-devel] [PATCH] SHA-256 support
Michael Niedermayer
michaelni
Tue Jun 9 21:16:10 CEST 2009
On Tue, Jun 09, 2009 at 09:32:24PM +0300, Kostya wrote:
> On Tue, Jun 09, 2009 at 04:47:09PM +0200, Michael Niedermayer wrote:
> > On Tue, Jun 09, 2009 at 08:13:40AM +0300, Kostya wrote:
> [...]
> > > /* Hash a single 512-bit block. This is the core of the algorithm. */
> > >
> > > static void transform(uint32_t state[5], const uint8_t buffer[64])
> >
> > doxy?
>
> no
make it a yes please
>
> > > {
> > > unsigned int i, a, b, c, d, e, f, g, h;
> > > uint32_t block[80];
> > > uint32_t T1, T2;
> > >
> > > a = state[0];
> > > b = state[1];
> > > c = state[2];
> > > d = state[3];
> > > e = state[4];
> > > f = state[5];
> > > g = state[6];
> > > h = state[7];
> > >
> > > for (i = 0; i < 64; i++) {
> > > if (i < 16) {
> > > T1 = block[i] = be2me_32(((const uint32_t*)buffer)[i]);
> > > } else {
> > > block[i & 0xF] += block[(i + 9) & 0xF]
> > > + sigma0_256(block[(i + 1) & 0xF])
> > > + sigma1_256(block[(i + 14) & 0xF]);
> > > T1 = block[i & 0xF];
> > > }
> >
> > you have lost some optimizations from our sha1 here,
> >
> > also sha224 should be supported because its almost identical
>
> Here you are. Seems to work fine on x86, should be fine on BE systems as
> well (will test tomorrow).
>
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> Makefile | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 9f3b5755dfe516571ef2196e1460c648e15423b1 sha2.patch
> Index: libavutil/Makefile
> ===================================================================
> --- libavutil/Makefile (revision 18770)
> +++ libavutil/Makefile (working copy)
> @@ -17,7 +17,8 @@
> mem.h \
> pixfmt.h \
> rational.h \
> - sha1.h
> + sha1.h \
> + sha2.h
the sha2.h should also have a \ at the end so future patches are dont need to
move the lack of a \ down
>
> OBJS = adler32.o \
> aes.o \
> @@ -38,10 +39,11 @@
> rational.o \
> rc4.o \
> sha1.o \
> + sha2.o \
> tree.o \
> utils.o \
>
> -TESTPROGS = adler32 aes base64 crc des lls md5 pca sha1 softfloat tree
> +TESTPROGS = adler32 aes base64 crc des lls md5 pca sha1 sha2 softfloat tree
> TESTPROGS-$(HAVE_LZO1X_999_COMPRESS) += lzo
>
> DIRS = arm bfin sh4 x86
> /*
> * Copyright (C) 2009 Konstantin Shishkov
> *
> * This file is part of FFmpeg.
> *
> * FFmpeg is free software; you can redistribute it and/or
> * modify it under the terms of the GNU Lesser General Public
> * License as published by the Free Software Foundation; either
> * version 2.1 of the License, or (at your option) any later version.
> *
> * FFmpeg is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> * Lesser General Public License for more details.
> *
> * You should have received a copy of the GNU Lesser General Public
> * License along with FFmpeg; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> */
>
> #ifndef AVUTIL_SHA2_H
> #define AVUTIL_SHA2_H
>
> #include <stdint.h>
>
> extern const int av_sha256_size;
>
> struct AVSHA256;
>
> void av_sha224_init(struct AVSHA256* context);
> #define av_sha224_update av_sha_256_update
> void av_sha224_final(struct AVSHA256* context, uint8_t digest[28]);
>
> void av_sha256_init(struct AVSHA256* context);
> void av_sha256_update(struct AVSHA256* context, const uint8_t* data, unsigned int len);
> void av_sha256_final(struct AVSHA256* context, uint8_t digest[32]);
i think a int bits is nicer than 2 sets of functions
it also might safe you from some comments about code duplication
[...]
> static void transform(uint32_t state[5], const uint8_t buffer[64])
> {
> unsigned int i, a, b, c, d, e, f, g, h;
> uint32_t block[16];
> uint32_t T1, T2;
>
> a = state[0];
> b = state[1];
> c = state[2];
> d = state[3];
> e = state[4];
> f = state[5];
> g = state[6];
> h = state[7];
> #if CONFIG_SMALL
> for (i = 0; i < 64; i++) {
> if (i < 16) {
> T1 = block[i] = be2me_32(((const uint32_t*)buffer)[i]);
> } else {
> block[i & 0xF] += block[(i + 9) & 0xF]
> + sigma0_256(block[(i + 1) & 0xF])
> + sigma1_256(block[(i + 14) & 0xF]);
> T1 = block[i & 0xF];
now you removed the other part of the optimization
please restore the size of the block array and get rid of the & 0xF
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090609/3635752e/attachment.pgp>
More information about the ffmpeg-devel
mailing list