FFmpeg
Data Structures | Macros | Functions | Variables
sha.c File Reference
#include <string.h>
#include "attributes.h"
#include "avutil.h"
#include "bswap.h"
#include "sha.h"
#include "intreadwrite.h"
#include "mem.h"

Go to the source code of this file.

Data Structures

struct  AVSHA
 hash context More...
 

Macros

#define rol(value, bits)   (((value) << (bits)) | ((value) >> (32 - (bits))))
 
#define blk0(i)   (block[i] = AV_RB32(buffer + 4 * (i)))
 
#define blk(i)   (block[i] = rol(block[(i)-3] ^ block[(i)-8] ^ block[(i)-14] ^ block[(i)-16], 1))
 
#define R0(v, w, x, y, z, i)   z += (((w)&((x)^(y)))^(y)) + blk0(i) + 0x5A827999 + rol(v, 5); w = rol(w, 30);
 
#define R1(v, w, x, y, z, i)   z += (((w)&((x)^(y)))^(y)) + blk (i) + 0x5A827999 + rol(v, 5); w = rol(w, 30);
 
#define R2(v, w, x, y, z, i)   z += ( (w)^(x) ^(y)) + blk (i) + 0x6ED9EBA1 + rol(v, 5); w = rol(w, 30);
 
#define R3(v, w, x, y, z, i)   z += ((((w)|(x))&(y))|((w)&(x))) + blk (i) + 0x8F1BBCDC + rol(v, 5); w = rol(w, 30);
 
#define R4(v, w, x, y, z, i)   z += ( (w)^(x) ^(y)) + blk (i) + 0xCA62C1D6 + rol(v, 5); w = rol(w, 30);
 
#define R1_0
 
#define R1_20
 
#define R1_40
 
#define R1_60
 
#define Ch(x, y, z)   (((x) & ((y) ^ (z))) ^ (z))
 
#define Maj(z, y, x)   ((((x) | (y)) & (z)) | ((x) & (y)))
 
#define Sigma0_256(x)   (rol((x), 30) ^ rol((x), 19) ^ rol((x), 10))
 
#define Sigma1_256(x)   (rol((x), 26) ^ rol((x), 21) ^ rol((x), 7))
 
#define sigma0_256(x)   (rol((x), 25) ^ rol((x), 14) ^ ((x) >> 3))
 
#define sigma1_256(x)   (rol((x), 15) ^ rol((x), 13) ^ ((x) >> 10))
 
#define blk(i)
 
#define ROUND256(a, b, c, d, e, f, g, h)
 
#define ROUND256_0_TO_15(a, b, c, d, e, f, g, h)
 
#define ROUND256_16_TO_63(a, b, c, d, e, f, g, h)
 
#define R256_0
 
#define R256_16
 

Functions

struct AVSHAav_sha_alloc (void)
 Allocate an AVSHA context. More...
 
static void sha1_transform (uint32_t state[5], const uint8_t buffer[64])
 
static void sha256_transform (uint32_t *state, const uint8_t buffer[64])
 
av_cold int av_sha_init (AVSHA *ctx, int bits)
 Initialize SHA-1 or SHA-2 hashing. More...
 
void av_sha_update (struct AVSHA *ctx, const uint8_t *data, unsigned int len)
 Update hash value. More...
 
void av_sha_final (AVSHA *ctx, uint8_t *digest)
 Finish hashing and output digest value. More...
 

Variables

const int av_sha_size = sizeof(AVSHA)
 
static const uint32_t K256 [64]
 

Macro Definition Documentation

#define rol (   value,
  bits 
)    (((value) << (bits)) | ((value) >> (32 - (bits))))

Definition at line 50 of file sha.c.

Referenced by sha1_transform().

#define blk0 (   i)    (block[i] = AV_RB32(buffer + 4 * (i)))

Definition at line 53 of file sha.c.

Referenced by dct_unquantize_h263_intra_neon(), and sha256_transform().

#define blk (   i)    (block[i] = rol(block[(i)-3] ^ block[(i)-8] ^ block[(i)-14] ^ block[(i)-16], 1))
#define R0 (   v,
  w,
  x,
  y,
  z,
  i 
)    z += (((w)&((x)^(y)))^(y)) + blk0(i) + 0x5A827999 + rol(v, 5); w = rol(w, 30);

Definition at line 56 of file sha.c.

Referenced by ff_yuv2rgb_init_tables_ppc(), and sha1_transform().

#define R1 (   v,
  w,
  x,
  y,
  z,
  i 
)    z += (((w)&((x)^(y)))^(y)) + blk (i) + 0x5A827999 + rol(v, 5); w = rol(w, 30);

Definition at line 57 of file sha.c.

Referenced by sha1_transform().

#define R2 (   v,
  w,
  x,
  y,
  z,
  i 
)    z += ( (w)^(x) ^(y)) + blk (i) + 0x6ED9EBA1 + rol(v, 5); w = rol(w, 30);

Definition at line 58 of file sha.c.

#define R3 (   v,
  w,
  x,
  y,
  z,
  i 
)    z += ((((w)|(x))&(y))|((w)&(x))) + blk (i) + 0x8F1BBCDC + rol(v, 5); w = rol(w, 30);

Definition at line 59 of file sha.c.

#define R4 (   v,
  w,
  x,
  y,
  z,
  i 
)    z += ( (w)^(x) ^(y)) + blk (i) + 0xCA62C1D6 + rol(v, 5); w = rol(w, 30);

Definition at line 60 of file sha.c.

#define R1_0
Value:
R0(a, b, c, d, e, 0 + i); \
R0(e, a, b, c, d, 1 + i); \
R0(d, e, a, b, c, 2 + i); \
R0(c, d, e, a, b, 3 + i); \
R0(b, c, d, e, a, 4 + i); \
i += 5
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define R0(v, w, x, y, z, i)
Definition: sha.c:56
#define b
Definition: input.c:41

Referenced by sha1_transform().

#define R1_20
Value:
R2(a, b, c, d, e, 0 + i); \
R2(e, a, b, c, d, 1 + i); \
R2(d, e, a, b, c, 2 + i); \
R2(c, d, e, a, b, 3 + i); \
R2(b, c, d, e, a, 4 + i); \
i += 5
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41
#define R2(v, w, x, y, z, i)
Definition: sha.c:58

Referenced by sha1_transform().

#define R1_40
Value:
R3(a, b, c, d, e, 0 + i); \
R3(e, a, b, c, d, 1 + i); \
R3(d, e, a, b, c, 2 + i); \
R3(c, d, e, a, b, 3 + i); \
R3(b, c, d, e, a, 4 + i); \
i += 5
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define R3(v, w, x, y, z, i)
Definition: sha.c:59
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41

Referenced by sha1_transform().

#define R1_60
Value:
R4(a, b, c, d, e, 0 + i); \
R4(e, a, b, c, d, 1 + i); \
R4(d, e, a, b, c, 2 + i); \
R4(c, d, e, a, b, 3 + i); \
R4(b, c, d, e, a, 4 + i); \
i += 5
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define R4(v, w, x, y, z, i)
Definition: sha.c:60
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41

Referenced by sha1_transform().

#define Ch (   x,
  y,
 
)    (((x) & ((y) ^ (z))) ^ (z))

Definition at line 176 of file sha.c.

Referenced by sha256_transform().

#define Maj (   z,
  y,
 
)    ((((x) | (y)) & (z)) | ((x) & (y)))

Definition at line 177 of file sha.c.

Referenced by sha256_transform().

#define Sigma0_256 (   x)    (rol((x), 30) ^ rol((x), 19) ^ rol((x), 10))

Definition at line 179 of file sha.c.

Referenced by sha256_transform().

#define Sigma1_256 (   x)    (rol((x), 26) ^ rol((x), 21) ^ rol((x), 7))

Definition at line 180 of file sha.c.

Referenced by sha256_transform().

#define sigma0_256 (   x)    (rol((x), 25) ^ rol((x), 14) ^ ((x) >> 3))

Definition at line 181 of file sha.c.

#define sigma1_256 (   x)    (rol((x), 15) ^ rol((x), 13) ^ ((x) >> 10))

Definition at line 182 of file sha.c.

#define blk (   i)
Value:
(block[i] = block[i - 16] + sigma0_256(block[i - 15]) + \
sigma1_256(block[i - 2]) + block[i - 7])
#define sigma1_256(x)
Definition: sha.c:182
The exact code depends on how similar the blocks are and how related they are to the block
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define sigma0_256(x)
Definition: sha.c:181

Definition at line 185 of file sha.c.

#define ROUND256 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 += (h) + Sigma1_256(e) + Ch((e), (f), (g)) + K256[i]; \
(d) += T1; \
(h) = T1 + Sigma0_256(a) + Maj((a), (b), (c)); \
i++
const char * g
Definition: vf_curves.c:115
#define Sigma1_256(x)
Definition: sha.c:180
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41
#define Maj(z, y, x)
Definition: sha.c:177
static const uint32_t K256[64]
Definition: sha.c:156
#define Sigma0_256(x)
Definition: sha.c:179
#define Ch(x, y, z)
Definition: sha.c:176

Definition at line 188 of file sha.c.

#define ROUND256_0_TO_15 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 = blk0(i); \
ROUND256(a,b,c,d,e,f,g,h)
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define ROUND256(a, b, c, d, e, f, g, h)
Definition: sha.c:188
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41
#define blk0(i)
Definition: sha.c:53

Definition at line 194 of file sha.c.

#define ROUND256_16_TO_63 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 = blk(i); \
ROUND256(a,b,c,d,e,f,g,h)
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define blk(i)
Definition: sha.c:185
#define ROUND256(a, b, c, d, e, f, g, h)
Definition: sha.c:188
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41

Definition at line 198 of file sha.c.

#define R256_0
Value:
ROUND256_0_TO_15(a, b, c, d, e, f, g, h); \
ROUND256_0_TO_15(h, a, b, c, d, e, f, g); \
ROUND256_0_TO_15(g, h, a, b, c, d, e, f); \
ROUND256_0_TO_15(f, g, h, a, b, c, d, e); \
ROUND256_0_TO_15(e, f, g, h, a, b, c, d); \
ROUND256_0_TO_15(d, e, f, g, h, a, b, c); \
ROUND256_0_TO_15(c, d, e, f, g, h, a, b); \
ROUND256_0_TO_15(b, c, d, e, f, g, h, a)
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define ROUND256_0_TO_15(a, b, c, d, e, f, g, h)
Definition: sha.c:194
#define b
Definition: input.c:41

Referenced by sha256_transform().

#define R256_16
Value:
ROUND256_16_TO_63(a, b, c, d, e, f, g, h); \
ROUND256_16_TO_63(h, a, b, c, d, e, f, g); \
ROUND256_16_TO_63(g, h, a, b, c, d, e, f); \
ROUND256_16_TO_63(f, g, h, a, b, c, d, e); \
ROUND256_16_TO_63(e, f, g, h, a, b, c, d); \
ROUND256_16_TO_63(d, e, f, g, h, a, b, c); \
ROUND256_16_TO_63(c, d, e, f, g, h, a, b); \
ROUND256_16_TO_63(b, c, d, e, f, g, h, a)
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define b
Definition: input.c:41
#define ROUND256_16_TO_63(a, b, c, d, e, f, g, h)
Definition: sha.c:198

Referenced by sha256_transform().

Function Documentation

static void sha1_transform ( uint32_t  state[5],
const uint8_t  buffer[64] 
)
static

Definition at line 64 of file sha.c.

Referenced by av_sha_init().

static void sha256_transform ( uint32_t *  state,
const uint8_t  buffer[64] 
)
static

Definition at line 202 of file sha.c.

Referenced by av_sha_init().

Variable Documentation

const uint32_t K256[64]
static
Initial value:
= {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5,
0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3,
0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7,
0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13,
0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3,
0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5,
0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
}

Definition at line 156 of file sha.c.

Referenced by sha256_transform().