agievich / bee2

A cryptographic library

Bee2: a cryptographic library

What is Bee2?

Bee2 is a cryptographic library which implements cryptographic algorithm and protocols standardized in Belarus.

Bee2 fully supports the following standards (see apmi.bsu.by/resources/std.html):

1. STB 34.101.31 (belt): data encryption and integrity algorithms.
2. STB 34.101.45 (bign): digital signature and key transport algorithms over elliptic curves.
3. STB 34.101.47 (brng): cryptographic algorithms of pseudorandom number generation + one-time passwords.
4. STB 34.101.60 (bels): secret sharing algorithms.
5. STB 34.101.66 (bake): key establishment protocols over elliptic curves.
6. STB 34.101.77 (bash): sponge-based algorithms.

Bee2 partially supports cryptographic mechanisms and data formats defined in the following standards:

7. STB 34.101.78 (bpki): a PKI profile.
8. STB 34.101.79 (btok): cryptographic tokens.

Additionally, Bee2 implements digital signature algorithms standardized in Russia and Ukraine.

Build

mkdir build
cd build
cmake [-DCMAKE_BUILD_TYPE={Release|Debug|Coverage|ASan|ASanDbg|MemSan|MemSanDbg|Check}]\
      [-DBUILD_FAST=ON]\
      [-DBASH_PLATFORM={BASH_32|BASH_64|BASH_AVX2|BASH_AVX512|BASH_NEON}]\
      ..
make
[make test]
[make install]

Note. To build on Windows you need to specify compiler and use the compiler-specific make command. The following example is for the MinGW compiler:

mkdir build
cd build
cmake [-DCMAKE_BUILD_TYPE={Release|Debug|Coverage|ASan|ASanDbg|MemSan|MemSanDbg|Check}]\
      [-DBUILD_FAST=ON]\
      [-DBASH_PLATFORM={BASH_32|BASH_64|BASH_AVX2|BASH_AVX512|BASH_NEON}]\
      -G "MinGW Makefiles"\
      ..
mingw32-make
[mingw32-make test]
[mingw32-make install]

Build types (Release by default):

• Coverage — test coverage;
• ASan, ASanDbg — address sanitizer;
• MemSan, MemSanDbg — memory sanitizer;
• Check — strict compile rules.

The BUILD_FAST option (OFF by default) switches from safe (constant-time) functions to fast (non-constant-time) ones.

The BASH_PLATFORM option (BASH_64 by default) requests to use a specific implementation of the STB 34.101.77 algorithms optimized for a given hardware platform. The request may be rejected if it conflicts with other options.

License

Bee2 is distributed under the Apache License version 2.0. See Apache 2.0 or LICENSE for details.

Third-party code

• whereami.

Automated tools

Platforms:

• Github Actions;
• Travis CI (archived).

Static analysis:

• Coverity Scan;
• PVS-Studio.

Code coverage:

• CodeCov.

Related projects

• Bee2evp: an OpenSSL engine over Bee2;
• Bee2j: a Java wrapper over Bee2.

What is the logo?

The logo of Bee2 is taken from a self-portrait engraving by Francysk Skaryna, the famous Belarusian medieval printer, enlightener, translator and writer. The engraving is full of riddles, mysteries and cryptograms. One version is that a bee in the right-bottom corner, our logo, designates the constellation known as Apes (Latin for bees) in Skaryna's time. This constellation was later renamed in Musca Borelias (Latin for northern fly) and then absorbed by Aries.

bee2's Issues

Memory leak in botpOCRARand and botpOCRAVerify

If an error occurs in botpOCRAVerify or botpOCRARand after calling blobCreate function, the assigned memory won't be freed and remain allocated. An attacker can make these functions consume all available memory and crash the whole service that uses bee2 lib.

A small example:

#include "stdafx.h"
#include <bee2/crypto/botp.h>
#include <cstring>

int main()
{
    char key[16] = { 
        0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
        0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
    };
    char* otp = "otp";
    char* suit = "suit";
    char q[] = { 'h', 'e', 'l', 'l', 'o' };
    char ctr[8] = { 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h' };
    char p[] = { 'w', 'o', 'r', 'l', 'd' };
    char s[] = { 's', 'e', 's', 's', 'i', 'o', 'n', 'i', 'd' };
    tm_time_t t = 1000;

    for (long i = 0; i < 100000000000; i++) {
        /*
        botpOCRAVerify(
            otp,
            suit,
            reinterpret_cast<const octet*>(key),
            sizeof(key),
            reinterpret_cast<const octet*>(q),
            sizeof(q),
            reinterpret_cast<const octet*>(ctr),
            reinterpret_cast<const octet*>(p),
            reinterpret_cast<const octet*>(s),
            t
            );
        */

        botpOCRARand(otp, suit, reinterpret_cast<const octet*>(key), sizeof(key), reinterpret_cast<const octet*>(q), sizeof(q),
            reinterpret_cast<const octet*>(ctr), reinterpret_cast<const octet*>(p), reinterpret_cast<const octet*>(s), t);
    }

    return 0;
}

The example being built and run on x86 system will consume 2GB of RAM and won't crash as the functions check memory allocation errors, but this doesn't prevent from crash other parts of the application that uses these functions.

SIgnature verify failed

bign_params params;
bignStdParams(&params, "1.2.112.0.2.0.34.101.45.3.1");
octet oid[] = {
        0x06, 0x09, 0x2A, 0x70, 0x00, 0x02, 0x00, 0x22, 0x65, 0x1F, 0x51,
};
octet buf[] = { 0x00, 0x07, 0xBF, 0x0C, 0x26, 0xC0, 0xE4, 0xEC, 0xE8, 0xED, 0x20, 0xCC, 0xCE, 0xCC, 0xCE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x95, 0x08, 0x0A, 0x17, 0x0C, 0x14, 0x24, 0x42, 0x59, 0x4E, 0x08, 0x71, 0x45, 0x99, 0x51, 0x69, 0x66, 0x00, 0x13, 0x88, 0x00, 0x00, 0x00, 0x00, 0x02, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
octet sig[] = { 0x95, 0x08, 0x73, 0xFA, 0x3D, 0xE4, 0xF0, 0x18, 0x08, 0x6B, 0x49, 0xAF, 0xBB, 0xAA, 0x4F, 0xB1, 0xCB, 0x49, 0x55, 0x82, 0x4A, 0x15, 0x9A, 0x16, 0x17, 0x7D, 0x14, 0xF8, 0xB7, 0x37, 0x8D, 0x9E, 0xD0, 0x30, 0xA8, 0xA6, 0xCA, 0x48, 0x50, 0x89, 0xE3, 0x70, 0xE1, 0x66, 0xA1, 0xD2, 0x13, 0x08 };
octet key[] = { 0x3C, 0xFC, 0x60, 0x0B, 0x6C, 0x93, 0xB1, 0x0F, 0x5A, 0xEC, 0xE8, 0x03, 0x9F, 0xCA, 0xA4, 0xD9, 0xE7, 0x0F, 0x09, 0x5F, 0x8B, 0x5E, 0xE9, 0xE6, 0x9D, 0x33, 0xC4, 0x59, 0x4E, 0x96, 0x48, 0x5D, 0x3E, 0x8E, 0xDE, 0x44, 0x68, 0x21, 0xB1, 0x46, 0xDA, 0x53, 0xDF, 0x24, 0x9B, 0x3B, 0x48, 0x23, 0xF7, 0xCE, 0xF8, 0xF7, 0x7B, 0x8D, 0xF6, 0xBF, 0xC1, 0x1A, 0x55, 0x20, 0xD1, 0x33, 0xEF, 0x89 };

octet hash[32];
beltHash(hash, buf, sizeof(buf));
err_t res = bignVerify(&params, oid, sizeof(oid), &hash, sig, key);
printf("bignVerify: %d\n", res);

Result: bignVerify: 510

s0: [95, 08, 73, FA, 3D, E4, F0, 18, 08, 6B, 49, AF, BB, AA, 4F, B1]
s1: [CB, 49, 55, 82, 4A, 15, 9A, 16, 17, 7D, 14, F8, B7, 37, 8D, 9E, D0, 30, A8, A6, CA, 48, 50, 89, E3, 70, E1, 66, A1, D2, 13, 08]
kx: [3C, FC, 60, 0B, 6C, 93, B1, 0F, 5A, EC, E8, 03, 9F, CA, A4, D9, E7, 0F, 09, 5F, 8B, 5E, E9, E6, 9D, 33, C4, 59, 4E, 96, 48, 5D]
ky: [3E, 8E, DE, 44, 68, 21, B1, 46, DA, 53, DF, 24, 9B, 3B, 48, 23, F7, CE, F8, F7, 7B, 8D, F6, BF, C1, 1A, 55, 20, D1, 33, EF, 89]
r: [AF, 0C, 7D, B3, C4, 8C, B4, 97, 7A, AA, 5F, 76, 5E, 3A, 50, AD, 88, DC, 53, 79, 5E, 49, 8A, EC, 39, F1, 29, 1A, 07, 26, DA, 4C, C0, A8, 0A, 19, 50, B5, 0D, A8, 13, 82, 49, 83, DE, F6, D6, BC, 51, 99, 45, 41, 59, 4B, 8C, B1, A0, 25, 7F, C3, 8F, 0A, 94, 00]
to_hash: [06, 09, 2A, 70, 00, 02, 00, 22, 65, 1F, 51, AF, 0C, 7D, B3, C4, 8C, B4, 97, 7A, AA, 5F, 76, 5E, 3A, 50, AD, 88, DC, 53, 79, 5E, 49, 8A, EC, 39, F1, 29, 1A, 07, 26, DA, 4C, 22, 68, 51, C3, 2E, 12, FC, FC, 9F, 95, 8B, DA, 85, C3, 80, 61, AC, D1, EB, 52, 26, E1, 0C, 69, 74, 1E, 9F, 7C, BF, 13, C6, 70]
t: [95, 08, 73, FA, 3D, E4, F0, 18, 08, 6B, 49, AF, BB, AA, 4F, B1]

But signature is correct. Checked it with my certified SKZI by OAC.

Недостижимый код в zzExGCD(), zzDivMod()

В функциях zzDivMod и zzExGCD в файле zz_gcd.c, присутствуют не достижимые участки кода, отвечающие за изменение переменных sign и sign0.
Например

bee2/src/math/zz/zz_gcd.c

Lines 420 to 424 in cf0f75d

	else if (wwCmp(da0, da, n) >= 0)
	zzSub2(da0, da, n);
	else
	zzSub(da0, da, da0, n),
	sign0 = 1 - sign0;

License

Bee2 is released under GNU GPLv3. However the files:

• https://github.com/agievich/bee2/blob/master/include/bee2/info.h
• https://github.com/agievich/bee2/blob/master/include/bee2/info.h.in
  seems to be under GPLv3+ that is GPLv3 or at your option, any later. Should these files be under GPLv3 only?

Null pointer dereference / possible sensitive data leakage

bee2/src/core/blob.c

Line 77 in 7ad61a4

if (blob == 0)

If NULL ptr is passed to the blobWipe function, it will be dereferenced and the app will crash. If blob is valid, it won't be wiped out and sensitive data will remain in memory.

Looks like a typo, it should be if(blob != 0)

Invalid lock operation within rngCreate

"Compare and increment" atomic operation, implemented in rngCreate as

if (_lock)
{
  ++_lock;
  return ERR_OK;
}

is not atomic as two threads could simultaneously check condition and jump over. This may lead to issues with creating and using mutex _mtx. Suggested fix is to create mutex once in a global library initialization routine (e.g. bee2Init) and increment _lock within critical section.

Support RDRAND on AMD Ryzen CPU

Ryzen series of AMD processors support instructions RDRAND and RDSEED. Instructions for checking of presence and random numbers generations are same on Intel and AMD platforms.

Bee2 checks manufacturer by CPUID 01 instruction to be Intel ("GenuineIntel" in a twelve-character ASCII string stored in EBX, EDX, ECX). AMD processors produce "AuthenticAMD" after same CPUID command.

Некорректное использование cpuid для проверки поддержки rdrand, rdseed.

Файл core/rng.c.
Для определения поддержки инструкции rdrand используется следующий код:
/* rdrand? _/
_cpuid((int)info, 1);
return (info[1] & 0x40000000) == 0x40000000;
Но проверять нужно значение (info[2] & 0x40000000) == 0x40000000;

В ветке #elif defined(GNUC) && (defined(i386) || defined(x86_64)) в функции rngReadTRNG используется инструкция rdseed (asm volatile ("rdseed %0; setc %1" : "=r" (_rand), "=qm" (ok));), но соответствующая проверка rngHasTRNG() проверяет (некорректно) поддержку инструкции rdrand.
Для поддержки инструкции rdseed нужно:
_cpuid((int)info, 7);
return (info[1] & 0x40000) == 0x40000;

no such instruction: `rdseed %esi'

При сборке в Linux с помощью gcc возникает ошибка ассемблера: no such instruction: `rdseed %esi'.
Нужно добавить проверку возможности использования компилятором инструкции rdseed (и rdrand) на этапе конфигурации проекта (например, компилятор msvc-2013 понимает инструкции rdrand, rdseed, хотя в x64 невозможно использовать ассемблерные вставки; компилятор gcc-4.9.2 в Debian x86_64 понимает rdrand, но не понимает rdseed).

RNG: bad detection of "trng" entropy source

rngHasTRNG seems to fail to detect presence of rdseed instruction which makes rngReadTRNG fail. /proc/cpuinfo command reports presence of rdseed. However, without such detection "trng" entropy source provides entropy successfully passing both rngTestFIPS1 and rngTestFIPS2 tests.

Tested with Intel(R) Core(TM) i9-10885H and linux kernel 5.8.0-50-generic.

Tests fail when building on Fedora Linux with GCC 13

Using Gcc 13 the tests

• bignTest: Err
• botpTest: Err
• brngTest: Err
• belsTest: Err
• bakeTest: Err

fail. Build log.

With clang, these tests pass. Build log.

BeltTest fails on S390x

Build log when using Clang compilers:

https://kojipkgs.fedoraproject.org//work/tasks/7062/97237062/build.log

Tests of bee2cmd fail on Linux

A test of bee2cmd bsum fails when testing script don't present in the working directory

Reproduce:

cd build/cmd
bash ../../cmd/test/test.sh

Output:

Testing ver... Success
Testing bsum... Failed
Testing pwd... Success
Testing kg... Success
Testing cvc... Success
Testing sig... Success
Testing es... Success

Possible solution: use absolute path to file (realpath instead of basename) in the test.sh

this=$(realpath $BASH_SOURCE)