|
|
|
|
/* Copyright (c) 2019, Google Inc.
|
|
|
|
|
*
|
|
|
|
|
* Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
|
* purpose with or without fee is hereby granted, provided that the above
|
|
|
|
|
* copyright notice and this permission notice appear in all copies.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
|
|
|
|
|
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
|
|
|
|
|
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
|
|
|
|
|
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
|
|
|
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
|
|
|
|
|
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
|
|
|
|
|
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
|
|
|
|
|
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
|
|
#include <openssl/siphash.h>
|
|
|
|
|
|
|
|
|
|
#include "../internal.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void siphash_round(uint64_t v[4]) {
|
|
|
|
|
v[0] += v[1];
|
|
|
|
|
v[2] += v[3];
|
Extract common rotl/rotr functions.
We have a ton of per-file rotation functions, often with generic names
that do not tell you whether they are uint32_t vs uint64_t, or rotl vs
rotr.
Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0.
(x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what
cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC
doesn't. MSVC does, however, provide functions for this.
We usually rotate by a non-zero constant, which makes this moot, but
rotation comes up often enough that it's worth extracting out. Some
particular changes to call out:
- I've switched sha256.c from rotl to rotr. There was a comment
explaining why it differed from the specification. Now that we have
both functions, it's simpler to just match the specification.
- I've dropped all the inline assembly from sha512.c. Compilers should
be able to recognize rotations in 2021.
Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
v[1] = CRYPTO_rotl_u64(v[1], 13);
|
|
|
|
|
v[3] = CRYPTO_rotl_u64(v[3], 16);
|
|
|
|
|
v[1] ^= v[0];
|
|
|
|
|
v[3] ^= v[2];
|
Extract common rotl/rotr functions.
We have a ton of per-file rotation functions, often with generic names
that do not tell you whether they are uint32_t vs uint64_t, or rotl vs
rotr.
Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0.
(x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what
cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC
doesn't. MSVC does, however, provide functions for this.
We usually rotate by a non-zero constant, which makes this moot, but
rotation comes up often enough that it's worth extracting out. Some
particular changes to call out:
- I've switched sha256.c from rotl to rotr. There was a comment
explaining why it differed from the specification. Now that we have
both functions, it's simpler to just match the specification.
- I've dropped all the inline assembly from sha512.c. Compilers should
be able to recognize rotations in 2021.
Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
v[0] = CRYPTO_rotl_u64(v[0], 32);
|
|
|
|
|
v[2] += v[1];
|
|
|
|
|
v[0] += v[3];
|
Extract common rotl/rotr functions.
We have a ton of per-file rotation functions, often with generic names
that do not tell you whether they are uint32_t vs uint64_t, or rotl vs
rotr.
Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0.
(x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what
cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC
doesn't. MSVC does, however, provide functions for this.
We usually rotate by a non-zero constant, which makes this moot, but
rotation comes up often enough that it's worth extracting out. Some
particular changes to call out:
- I've switched sha256.c from rotl to rotr. There was a comment
explaining why it differed from the specification. Now that we have
both functions, it's simpler to just match the specification.
- I've dropped all the inline assembly from sha512.c. Compilers should
be able to recognize rotations in 2021.
Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
v[1] = CRYPTO_rotl_u64(v[1], 17);
|
|
|
|
|
v[3] = CRYPTO_rotl_u64(v[3], 21);
|
|
|
|
|
v[1] ^= v[2];
|
|
|
|
|
v[3] ^= v[0];
|
Extract common rotl/rotr functions.
We have a ton of per-file rotation functions, often with generic names
that do not tell you whether they are uint32_t vs uint64_t, or rotl vs
rotr.
Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0.
(x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what
cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC
doesn't. MSVC does, however, provide functions for this.
We usually rotate by a non-zero constant, which makes this moot, but
rotation comes up often enough that it's worth extracting out. Some
particular changes to call out:
- I've switched sha256.c from rotl to rotr. There was a comment
explaining why it differed from the specification. Now that we have
both functions, it's simpler to just match the specification.
- I've dropped all the inline assembly from sha512.c. Compilers should
be able to recognize rotations in 2021.
Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765
Reviewed-by: Adam Langley <agl@google.com>
3 years ago
|
|
|
v[2] = CRYPTO_rotl_u64(v[2], 32);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint64_t SIPHASH_24(const uint64_t key[2], const uint8_t *input,
|
|
|
|
|
size_t input_len) {
|
|
|
|
|
const size_t orig_input_len = input_len;
|
|
|
|
|
|
|
|
|
|
uint64_t v[4];
|
|
|
|
|
v[0] = key[0] ^ UINT64_C(0x736f6d6570736575);
|
|
|
|
|
v[1] = key[1] ^ UINT64_C(0x646f72616e646f6d);
|
|
|
|
|
v[2] = key[0] ^ UINT64_C(0x6c7967656e657261);
|
|
|
|
|
v[3] = key[1] ^ UINT64_C(0x7465646279746573);
|
|
|
|
|
|
|
|
|
|
while (input_len >= sizeof(uint64_t)) {
|
|
|
|
|
uint64_t m;
|
|
|
|
|
memcpy(&m, input, sizeof(m));
|
|
|
|
|
v[3] ^= m;
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
v[0] ^= m;
|
|
|
|
|
|
|
|
|
|
input += sizeof(uint64_t);
|
|
|
|
|
input_len -= sizeof(uint64_t);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
union {
|
|
|
|
|
uint8_t bytes[8];
|
|
|
|
|
uint64_t word;
|
|
|
|
|
} last_block;
|
|
|
|
|
last_block.word = 0;
|
|
|
|
|
OPENSSL_memcpy(last_block.bytes, input, input_len);
|
|
|
|
|
last_block.bytes[7] = orig_input_len & 0xff;
|
|
|
|
|
|
|
|
|
|
v[3] ^= last_block.word;
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
v[0] ^= last_block.word;
|
|
|
|
|
|
|
|
|
|
v[2] ^= 0xff;
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
siphash_round(v);
|
|
|
|
|
|
|
|
|
|
return v[0] ^ v[1] ^ v[2] ^ v[3];
|
|
|
|
|
}
|
