2014-06-20 20:00:00 +01:00
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 2008 The OpenSSL Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* openssl-core@openssl.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ==================================================================== */
|
|
|
|
|
2015-09-30 23:24:05 +01:00
|
|
|
#include <openssl/type_check.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
#include <assert.h>
|
2015-01-31 01:08:37 +00:00
|
|
|
#include <string.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
2018-10-24 23:08:00 +01:00
|
|
|
OPENSSL_STATIC_ASSERT(16 % sizeof(size_t) == 0,
|
|
|
|
"block cannot be divided into size_t");
|
2015-09-30 23:24:05 +01:00
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
void CRYPTO_cfb128_encrypt(const uint8_t *in, uint8_t *out, size_t len,
|
Fix undefined block128_f, etc., casts.
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
2018-09-23 02:37:01 +01:00
|
|
|
const AES_KEY *key, uint8_t ivec[16], unsigned *num,
|
2016-04-16 20:20:07 +01:00
|
|
|
int enc, block128_f block) {
|
2014-06-20 20:00:00 +01:00
|
|
|
size_t l = 0;
|
|
|
|
|
|
|
|
assert(in && out && key && ivec && num);
|
|
|
|
|
2016-04-16 20:20:07 +01:00
|
|
|
unsigned n = *num;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
if (enc) {
|
|
|
|
while (n && len) {
|
|
|
|
*(out++) = ivec[n] ^= *(in++);
|
|
|
|
--len;
|
|
|
|
n = (n + 1) % 16;
|
|
|
|
}
|
2015-01-29 00:20:02 +00:00
|
|
|
#if STRICT_ALIGNMENT
|
2017-11-07 22:24:10 +00:00
|
|
|
if (((uintptr_t)in | (uintptr_t)out | (uintptr_t)ivec) % sizeof(size_t) !=
|
|
|
|
0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
while (l < len) {
|
|
|
|
if (n == 0) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
}
|
|
|
|
out[l] = ivec[n] ^= in[l];
|
|
|
|
++l;
|
|
|
|
n = (n + 1) % 16;
|
|
|
|
}
|
|
|
|
*num = n;
|
|
|
|
return;
|
|
|
|
}
|
2015-01-29 00:20:02 +00:00
|
|
|
#endif
|
2014-06-20 20:00:00 +01:00
|
|
|
while (len >= 16) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
for (; n < 16; n += sizeof(size_t)) {
|
2017-11-07 22:24:10 +00:00
|
|
|
size_t tmp = load_word_le(ivec + n) ^ load_word_le(in + n);
|
|
|
|
store_word_le(ivec + n, tmp);
|
|
|
|
store_word_le(out + n, tmp);
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
len -= 16;
|
|
|
|
out += 16;
|
|
|
|
in += 16;
|
|
|
|
n = 0;
|
|
|
|
}
|
|
|
|
if (len) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
while (len--) {
|
|
|
|
out[n] = ivec[n] ^= in[n];
|
|
|
|
++n;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*num = n;
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
while (n && len) {
|
|
|
|
uint8_t c;
|
|
|
|
*(out++) = ivec[n] ^ (c = *(in++));
|
|
|
|
ivec[n] = c;
|
|
|
|
--len;
|
|
|
|
n = (n + 1) % 16;
|
|
|
|
}
|
2017-11-07 22:24:10 +00:00
|
|
|
if (STRICT_ALIGNMENT &&
|
|
|
|
((uintptr_t)in | (uintptr_t)out | (uintptr_t)ivec) % sizeof(size_t) !=
|
|
|
|
0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
while (l < len) {
|
2017-11-07 22:24:10 +00:00
|
|
|
uint8_t c;
|
2014-06-20 20:00:00 +01:00
|
|
|
if (n == 0) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
}
|
|
|
|
out[l] = ivec[n] ^ (c = in[l]);
|
|
|
|
ivec[n] = c;
|
|
|
|
++l;
|
|
|
|
n = (n + 1) % 16;
|
|
|
|
}
|
|
|
|
*num = n;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
while (len >= 16) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
for (; n < 16; n += sizeof(size_t)) {
|
2017-11-07 22:24:10 +00:00
|
|
|
size_t t = load_word_le(in + n);
|
|
|
|
store_word_le(out + n, load_word_le(ivec + n) ^ t);
|
|
|
|
store_word_le(ivec + n, t);
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
len -= 16;
|
|
|
|
out += 16;
|
|
|
|
in += 16;
|
|
|
|
n = 0;
|
|
|
|
}
|
|
|
|
if (len) {
|
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
while (len--) {
|
|
|
|
uint8_t c;
|
|
|
|
out[n] = ivec[n] ^ (c = in[n]);
|
|
|
|
ivec[n] = c;
|
|
|
|
++n;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*num = n;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* This expects a single block of size nbits for both in and out. Note that
|
|
|
|
it corrupts any extra bits in the last byte of out */
|
|
|
|
static void cfbr_encrypt_block(const uint8_t *in, uint8_t *out, unsigned nbits,
|
Fix undefined block128_f, etc., casts.
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
2018-09-23 02:37:01 +01:00
|
|
|
const AES_KEY *key, uint8_t ivec[16], int enc,
|
2014-06-20 20:00:00 +01:00
|
|
|
block128_f block) {
|
|
|
|
int n, rem, num;
|
|
|
|
uint8_t ovec[16 * 2 + 1]; /* +1 because we dererefence (but don't use) one
|
|
|
|
byte off the end */
|
|
|
|
|
|
|
|
if (nbits <= 0 || nbits > 128) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// fill in the first half of the new IV with the current IV
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ovec, ivec, 16);
|
2017-08-18 19:06:02 +01:00
|
|
|
// construct the new IV
|
2014-06-20 20:00:00 +01:00
|
|
|
(*block)(ivec, ivec, key);
|
|
|
|
num = (nbits + 7) / 8;
|
|
|
|
if (enc) {
|
2017-08-18 19:06:02 +01:00
|
|
|
// encrypt the input
|
2014-06-20 20:00:00 +01:00
|
|
|
for (n = 0; n < num; ++n) {
|
|
|
|
out[n] = (ovec[16 + n] = in[n] ^ ivec[n]);
|
|
|
|
}
|
|
|
|
} else {
|
2017-08-18 19:06:02 +01:00
|
|
|
// decrypt the input
|
2014-06-20 20:00:00 +01:00
|
|
|
for (n = 0; n < num; ++n) {
|
|
|
|
out[n] = (ovec[16 + n] = in[n]) ^ ivec[n];
|
|
|
|
}
|
|
|
|
}
|
2017-08-18 19:06:02 +01:00
|
|
|
// shift ovec left...
|
2014-06-20 20:00:00 +01:00
|
|
|
rem = nbits % 8;
|
|
|
|
num = nbits / 8;
|
|
|
|
if (rem == 0) {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ivec, ovec + num, 16);
|
2014-06-20 20:00:00 +01:00
|
|
|
} else {
|
|
|
|
for (n = 0; n < 16; ++n) {
|
|
|
|
ivec[n] = ovec[n + num] << rem | ovec[n + num + 1] >> (8 - rem);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// it is not necessary to cleanse ovec, since the IV is not secret
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// N.B. This expects the input to be packed, MS bit first
|
2014-06-20 20:00:00 +01:00
|
|
|
void CRYPTO_cfb128_1_encrypt(const uint8_t *in, uint8_t *out, size_t bits,
|
Fix undefined block128_f, etc., casts.
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
2018-09-23 02:37:01 +01:00
|
|
|
const AES_KEY *key, uint8_t ivec[16],
|
|
|
|
unsigned *num, int enc, block128_f block) {
|
2014-06-20 20:00:00 +01:00
|
|
|
size_t n;
|
|
|
|
uint8_t c[1], d[1];
|
|
|
|
|
|
|
|
assert(in && out && key && ivec && num);
|
|
|
|
assert(*num == 0);
|
|
|
|
|
|
|
|
for (n = 0; n < bits; ++n) {
|
|
|
|
c[0] = (in[n / 8] & (1 << (7 - n % 8))) ? 0x80 : 0;
|
|
|
|
cfbr_encrypt_block(c, d, 1, key, ivec, enc, block);
|
|
|
|
out[n / 8] = (out[n / 8] & ~(1 << (unsigned int)(7 - n % 8))) |
|
|
|
|
((d[0] & 0x80) >> (unsigned int)(n % 8));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CRYPTO_cfb128_8_encrypt(const unsigned char *in, unsigned char *out,
|
Fix undefined block128_f, etc., casts.
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
2018-09-23 02:37:01 +01:00
|
|
|
size_t length, const AES_KEY *key,
|
2016-04-16 20:20:07 +01:00
|
|
|
unsigned char ivec[16], unsigned *num, int enc,
|
2014-06-20 20:00:00 +01:00
|
|
|
block128_f block) {
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
assert(in && out && key && ivec && num);
|
|
|
|
assert(*num == 0);
|
|
|
|
|
|
|
|
for (n = 0; n < length; ++n) {
|
|
|
|
cfbr_encrypt_block(&in[n], &out[n], 8, key, ivec, enc, block);
|
|
|
|
}
|
|
|
|
}
|