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

Go to the source code of this file.

Data Structures

struct  AVSHA512
 hash context More...
 

Macros

#define ror(value, bits)   (((value) >> (bits)) | ((value) << (64 - (bits))))
 
#define Ch(x, y, z)   (((x) & ((y) ^ (z))) ^ (z))
 
#define Maj(z, y, x)   ((((x) | (y)) & (z)) | ((x) & (y)))
 
#define Sigma0_512(x)   (ror((x), 28) ^ ror((x), 34) ^ ror((x), 39))
 
#define Sigma1_512(x)   (ror((x), 14) ^ ror((x), 18) ^ ror((x), 41))
 
#define sigma0_512(x)   (ror((x), 1) ^ ror((x), 8) ^ ((x) >> 7))
 
#define sigma1_512(x)   (ror((x), 19) ^ ror((x), 61) ^ ((x) >> 6))
 
#define blk0(i)   (block[i] = AV_RB64(buffer + 8 * (i)))
 
#define blk(i)
 
#define ROUND512(a, b, c, d, e, f, g, h)
 
#define ROUND512_0_TO_15(a, b, c, d, e, f, g, h)
 
#define ROUND512_16_TO_80(a, b, c, d, e, f, g, h)
 
#define R512_0
 
#define R512_16
 

Functions

struct AVSHA512 * av_sha512_alloc (void)
 Allocate an AVSHA512 context. More...
 
static void sha512_transform (uint64_t *state, const uint8_t buffer[128])
 
av_cold int av_sha512_init (AVSHA512 *ctx, int bits)
 Initialize SHA-2 512 hashing. More...
 
void av_sha512_update (AVSHA512 *ctx, const uint8_t *data, unsigned int len)
 Update hash value. More...
 
void av_sha512_final (AVSHA512 *ctx, uint8_t *digest)
 Finish hashing and output digest value. More...
 

Variables

const int av_sha512_size = sizeof(AVSHA512)
 
static const uint64_t K512 [80]
 

Macro Definition Documentation

#define ror (   value,
  bits 
)    (((value) >> (bits)) | ((value) << (64 - (bits))))

Definition at line 91 of file sha512.c.

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

Definition at line 93 of file sha512.c.

Referenced by sha512_transform().

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

Definition at line 94 of file sha512.c.

Referenced by sha512_transform().

#define Sigma0_512 (   x)    (ror((x), 28) ^ ror((x), 34) ^ ror((x), 39))

Definition at line 96 of file sha512.c.

Referenced by sha512_transform().

#define Sigma1_512 (   x)    (ror((x), 14) ^ ror((x), 18) ^ ror((x), 41))

Definition at line 97 of file sha512.c.

Referenced by sha512_transform().

#define sigma0_512 (   x)    (ror((x), 1) ^ ror((x), 8) ^ ((x) >> 7))

Definition at line 98 of file sha512.c.

#define sigma1_512 (   x)    (ror((x), 19) ^ ror((x), 61) ^ ((x) >> 6))

Definition at line 99 of file sha512.c.

#define blk0 (   i)    (block[i] = AV_RB64(buffer + 8 * (i)))

Definition at line 101 of file sha512.c.

Referenced by sha512_transform().

#define blk (   i)
Value:
(block[i] = block[i - 16] + sigma0_512(block[i - 15]) + \
sigma1_512(block[i - 2]) + block[i - 7])
block
The exact code depends on how similar the blocks are and how related they are to the block
Definition: filter_design.txt:207
i
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
sigma1_512
#define sigma1_512(x)
Definition: sha512.c:99
sigma0_512
#define sigma0_512(x)
Definition: sha512.c:98

Definition at line 102 of file sha512.c.

Referenced by sha512_transform().

#define ROUND512 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 += (h) + Sigma1_512(e) + Ch((e), (f), (g)) + K512[i]; \
(d) += T1; \
(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)); \
i++
h
h
Definition: vp9dsp_template.c:2038
K512
static const uint64_t K512[80]
Definition: sha512.c:48
g
const char * g
Definition: vf_curves.c:115
a
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
Sigma1_512
#define Sigma1_512(x)
Definition: sha512.c:97
f
#define f(width, name)
Definition: cbs_vp9.c:255
c
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
Ch
#define Ch(x, y, z)
Definition: sha512.c:93
i
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
Sigma0_512
#define Sigma0_512(x)
Definition: sha512.c:96
b
#define b
Definition: input.c:41
Maj
#define Maj(z, y, x)
Definition: sha512.c:94

Definition at line 105 of file sha512.c.

#define ROUND512_0_TO_15 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 = blk0(i); \
ROUND512(a,b,c,d,e,f,g,h)
ROUND512
#define ROUND512(a, b, c, d, e, f, g, h)
Definition: sha512.c:105
h
h
Definition: vp9dsp_template.c:2038
g
const char * g
Definition: vf_curves.c:115
a
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
f
#define f(width, name)
Definition: cbs_vp9.c:255
c
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
blk0
#define blk0(i)
Definition: sha512.c:101
i
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
b
#define b
Definition: input.c:41

Definition at line 111 of file sha512.c.

#define ROUND512_16_TO_80 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
T1 = blk(i); \
ROUND512(a,b,c,d,e,f,g,h)
ROUND512
#define ROUND512(a, b, c, d, e, f, g, h)
Definition: sha512.c:105
blk
#define blk(i)
Definition: sha512.c:102
h
h
Definition: vp9dsp_template.c:2038
g
const char * g
Definition: vf_curves.c:115
a
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
f
#define f(width, name)
Definition: cbs_vp9.c:255
c
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
i
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
b
#define b
Definition: input.c:41

Definition at line 115 of file sha512.c.

#define R512_0
Value:
ROUND512_0_TO_15(a, b, c, d, e, f, g, h); \
ROUND512_0_TO_15(h, a, b, c, d, e, f, g); \
ROUND512_0_TO_15(g, h, a, b, c, d, e, f); \
ROUND512_0_TO_15(f, g, h, a, b, c, d, e); \
ROUND512_0_TO_15(e, f, g, h, a, b, c, d); \
ROUND512_0_TO_15(d, e, f, g, h, a, b, c); \
ROUND512_0_TO_15(c, d, e, f, g, h, a, b); \
ROUND512_0_TO_15(b, c, d, e, f, g, h, a)
ROUND512_0_TO_15
#define ROUND512_0_TO_15(a, b, c, d, e, f, g, h)
Definition: sha512.c:111
h
h
Definition: vp9dsp_template.c:2038
g
const char * g
Definition: vf_curves.c:115
a
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
f
#define f(width, name)
Definition: cbs_vp9.c:255
c
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
b
#define b
Definition: input.c:41

Referenced by sha512_transform().

#define R512_16
Value:
ROUND512_16_TO_80(a, b, c, d, e, f, g, h); \
ROUND512_16_TO_80(h, a, b, c, d, e, f, g); \
ROUND512_16_TO_80(g, h, a, b, c, d, e, f); \
ROUND512_16_TO_80(f, g, h, a, b, c, d, e); \
ROUND512_16_TO_80(e, f, g, h, a, b, c, d); \
ROUND512_16_TO_80(d, e, f, g, h, a, b, c); \
ROUND512_16_TO_80(c, d, e, f, g, h, a, b); \
ROUND512_16_TO_80(b, c, d, e, f, g, h, a)
h
h
Definition: vp9dsp_template.c:2038
ROUND512_16_TO_80
#define ROUND512_16_TO_80(a, b, c, d, e, f, g, h)
Definition: sha512.c:115
g
const char * g
Definition: vf_curves.c:115
a
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
f
#define f(width, name)
Definition: cbs_vp9.c:255
c
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
b
#define b
Definition: input.c:41

Referenced by sha512_transform().

Function Documentation

static void sha512_transform ( uint64_t *  state,
const uint8_t  buffer[128] 
)
static

Definition at line 119 of file sha512.c.

Referenced by av_sha512_update().

Variable Documentation

const uint64_t K512[80]
static

Definition at line 48 of file sha512.c.

Referenced by sha512_transform().

Generated on Fri Dec 6 2019 19:22:30 for FFmpeg by   doxygen 1.8.11