#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.
|
#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 |
|
#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)) |
Value:The exact code depends on how similar the blocks are and how related they are to the block
Definition at line 102 of file sha512.c.
Referenced by sha512_transform().
#define ROUND512 |
( |
|
a, |
|
|
|
b, |
|
|
|
c, |
|
|
|
d, |
|
|
|
e, |
|
|
|
f, |
|
|
|
g, |
|
|
|
h |
|
) |
| |
Value: (d) += T1; \
static const uint64_t K512[80]
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
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 at line 105 of file sha512.c.
#define ROUND512_0_TO_15 |
( |
|
a, |
|
|
|
b, |
|
|
|
c, |
|
|
|
d, |
|
|
|
e, |
|
|
|
f, |
|
|
|
g, |
|
|
|
h |
|
) |
| |
Value:#define ROUND512(a, b, c, d, e, f, g, h)
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
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 at line 111 of file sha512.c.
#define ROUND512_16_TO_80 |
( |
|
a, |
|
|
|
b, |
|
|
|
c, |
|
|
|
d, |
|
|
|
e, |
|
|
|
f, |
|
|
|
g, |
|
|
|
h |
|
) |
| |
Value:#define ROUND512(a, b, c, d, e, f, g, h)
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
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 at line 115 of file sha512.c.
Value:#define ROUND512_0_TO_15(a, b, c, d, e, f, g, h)
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
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
Referenced by sha512_transform().
Value:
#define ROUND512_16_TO_80(a, b, c, d, e, f, g, h)
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
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
Referenced by sha512_transform().
static void sha512_transform |
( |
uint64_t * |
state, |
|
|
const uint8_t |
buffer[128] |
|
) |
| |
|
static |