bake.h(3)

📦
version 2.2.0 · 2 versions
, in fedora 44

💖 NAME 💖

bake.h — the protocols of СТБ 34.101.66 (aka bake). Yes bestie, this is a whole crypto standard chilling in one header, and this page (bake.h(3), from the Library Functions Manual, section 3) is about to explain it to you. 🫶


✨ SYNOPSIS ✨


#include 'bee2/defs.h'
#include 'bee2/crypto/bign.h'

🎀 Классы (Classes) 🎀

  • struct bake_settings — the bake settings, your config era ✨
  • struct bake_cert — a bake certificate 🎀

🦋 Макросы (Macros) 🦋

  • #define bakeDH bignDH — building the shared key of the Diffie–Hellman protocol 💫

🌸 Определения типов (Typedefs) 🌸

  • typedef err_t(* bake_certval_i) (octet pubkey[], const bign_params *params, const octet *data, size_t len) — certificate verification 🕵️♀️

🔥 Функции (Functions) 🔥

  • err_t bakeKDF (octet key[32], const octet secret[], size_t secret_len, const octet iv[], size_t iv_len, size_t num) — deriving a key 🔑
  • err_t bakeSWU (octet pt[], const bign_params *params, const octet msg[]) — building a point of the elliptic curve 🌈
  • size_t bakeBMQV_keep (size_t l) — how long the state of the BMQV functions is
  • err_t bakeBMQVStart (void *state, const bign_params *params, const bake_settings *settings, const octet privkey[], const bake_cert *cert) — initializing the BMQV protocol
  • err_t bakeBMQVStep2 (octet out[], void *state) — step 2 of the BMQV protocol
  • err_t bakeBMQVStep3 (octet out[], const octet in[], const bake_cert *certb, void *state) — step 3 of the BMQV protocol
  • err_t bakeBMQVStep4 (octet out[], const octet in[], const bake_cert *certa, void *state) — step 4 of the BMQV protocol
  • err_t bakeBMQVStep5 (const octet in[8], void *state) — step 5 of the BMQV protocol
  • err_t bakeBMQVStepG (octet key[32], void *state) — extracting the key of the BMQV protocol 🔑
  • err_t bakeBMQVRunB (octet key[32], const bign_params *params, const bake_settings *settings, const octet privkeyb[], const bake_cert *certb, const bake_cert *certa, read_i read, write_i write, void *file) — running BMQV as side B
  • err_t bakeBMQVRunA (octet key[32], const bign_params *params, const bake_settings *settings, const octet privkeya[], const bake_cert *certa, const bake_cert *certb, read_i read, write_i write, void *file) — running BMQV as side A
  • size_t bakeBSTS_keep (size_t l) — how long the state of the BSTS functions is
  • err_t bakeBSTSStart (void *state, const bign_params *params, const bake_settings *settings, const octet privkey[], const bake_cert *cert) — initializing the BSTS protocol
  • err_t bakeBSTSStep2 (octet out[], void *state) — step 2 of the BSTS protocol
  • err_t bakeBSTSStep3 (octet out[], const octet in[], void *state) — step 3 of the BSTS protocol
  • err_t bakeBSTSStep4 (octet out[], const octet in[], size_t in_len, bake_certval_i vala, void *state) — step 4 of the BSTS protocol
  • err_t bakeBSTSStep5 (const octet in[], size_t in_len, bake_certval_i valb, void *state) — step 5 of the BSTS protocol
  • err_t bakeBSTSStepG (octet key[32], void *state) — extracting the key of the BSTS protocol 🔑
  • err_t bakeBSTSRunB (octet key[32], const bign_params *params, const bake_settings *settings, const octet privkeyb[], const bake_cert *certb, bake_certval_i vala, read_i read, write_i write, void *file) — running BSTS as side B
  • err_t bakeBSTSRunA (octet key[32], const bign_params *params, const bake_settings *settings, const octet privkeya[], const bake_cert *certa, bake_certval_i valb, read_i read, write_i write, void *file) — running BSTS as side A
  • size_t bakeBPACE_keep (size_t l) — how long the state of the BPACE functions is
  • err_t bakeBPACEStart (void *state, const bign_params *params, const bake_settings *settings, const octet pwd[], size_t pwd_len) — initializing the BPACE protocol
  • err_t bakeBPACEStep2 (octet out[], void *state) — step 2 of the BPACE protocol
  • err_t bakeBPACEStep3 (octet out[], const octet in[], void *state) — step 3 of the BPACE protocol
  • err_t bakeBPACEStep4 (octet out[], const octet in[], void *state) — step 4 of the BPACE protocol
  • err_t bakeBPACEStep5 (octet out[], const octet in[], void *state) — step 5 of the BPACE protocol
  • err_t bakeBPACEStep6 (const octet in[8], void *state) — step 6 of the BPACE protocol
  • err_t bakeBPACEStepG (octet key[32], void *state) — extracting the key of the BPACE protocol 🔑
  • err_t bakeBPACERunB (octet key[32], const bign_params *params, const bake_settings *settings, const octet pwd[], size_t pwd_len, read_i read, write_i write, void *file) — running BPACE as side B
  • err_t bakeBPACERunA (octet key[32], const bign_params *params, const bake_settings *settings, const octet pwd[], size_t pwd_len, read_i read, write_i write, void *file) — running BPACE as side A

📖 Подробное описание (Detailed description) 📖

💜 СТБ 34.101.66 (bake): Общие положения 💜

The protocols and algorithms of СТБ 34.101.66 (bake) are implemented here. Whenever this page mentions protocols, tables or other objects, it means the sections of СТБ 34.101.66-2014 where those objects are defined. No cap. 📜

The long-term bake parameters are a copy of the long-term bign parameters, and they're given by a structure of type bign_params, described in the bign.h header file. You can grab the standard long-term parameters with the bignParamsStd() function, and check them with the bignParamsVal() function. ✨

Private and public keys follow the bign conventions. You can generate a keypair with the bignKeypairGen() function, check a public key with bignPubkeyVal(), and build a public key from a private one with bignPubkeyCalc(). 💅

The protocol settings are described by a structure of type bake_settings. In those settings you specify:

  • the kca flag — key confirmation by side A
  • the kcb flag — key confirmation by side B
  • the greeting message [helloa_len]helloa of side A
  • the greeting message [hellob_len]hellob of side B
  • the random number generator rng and its state rng_state

Depending on the kca and kcb flags, the number of transfers and the fragment lengths can change in the BMQV and BPACE protocols. 👀

Each protocol is implemented as a set of low-level functions that use a shared state and work by the scheme Start, Step2, Step3,.... The step numbers are given in accordance with the bake standard. The greeting messages are passed into the Start function, which is why step 1 of the standard — the one where they get transferred — is skipped. 🦋

The memory for the state is prepared by the calling program. The length of the state is given by the function with the keep suffix. The state contains pointers to internal memory fragments, and that's why you cannot copy it like an ordinary block of memory. 😭 (do not memcpy the state, bestie, I am begging)

The descriptions of the low-level StepX functions feature data that is set in the initializing Start function:

  • the security level l from the long-term parameters list
  • the flags kca and kcb from the settings list
  • the pointer cert to the protocol side's own certificate

Every protocol has two high-level functions with the RunA and RunB suffixes. These functions implement the full execution of the protocol on behalf of side A or side B. An implementation of the message transfer channel between the sides is passed into the function. 🫶

  • [ERR_BAD_INPUT] is expected — all input pointers, except the special-cased ones, are correct.
  • Also expected — during step-by-step execution of the protocol, the data passed in at initialization through the pointers stays correct and constant for the whole duration of the protocol run.
  • Регулярность (regularity) — todo

💌 Сертификаты 💌

The BMQV and BSTS protocols use certificates. A certificate is distributed as a structure of type bake_cert. Besides the actual certificate, this structure also specifies the function that checks it. 🕵️♀️

Прим. — The functions for checking one's own certificate and someone else's certificate can differ between the sides of the protocols.

🫶 Протокол BMQV 🫶

🫶 Протокол BSTS 🫶

🫶 Протокол BPACE 🫶

🎀 Макросы 🎀

#define bakeDH bignDH

A reference is set to the bignDH() function, which implements the basic Diffie–Hellman protocol. 💫

Прим. — The basic Diffie–Hellman protocol is described in appendix A.

✨ Типы ✨

okay bestie, before we get to the functions there's exactly one typedef you need to know about, and she's lowkey important 💅


bake_certval_i

typedef err_t(* bake_certval_i) (octet pubkey[], const bign_params *params,
    const octet *data, size_t len)

So this is the callback that goes "is this certificate actually valid, and does it match the long-term params?" And if pubkey != 0, it pulls the public key [l / 2]pubkey straight out of the certificate. iconic.

Ожидается

  • params is correct. (like, actually correct. no cap 🫶)

Возвращает

ERR_OK if the certificate is valid, and an error code otherwise. periodt.

Прим.

Okay so here's the tea 🍵 — inside your bake_certval_i function you do not have to check that pubkey actually lies on the curve defined by params. That check definitely happens every single time one of the protocols runs. So don't stress, it's handled ✨

Аргументы

  • pubkey — the public key
  • params — the long-term parameters
  • data — the certificate data
  • len — the length of data, in octets

🔥 Функции 🔥


bakeBMQV_keep()

size_t bakeBMQV_keep (size_t l)

Returns the length of the state (in octets) for the BMQV protocol functions. Like, how much space you gotta reserve. girl math but make it cryptography 💅

Возвращает

The length of the state.

Аргументы

  • l — the security level

bakeBMQVRunA()

err_t bakeBMQVRunA (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet privkeya[], const bake_cert *
    certa, const bake_cert * certb, read_i read, write_i write, void * file)

Runs the BMQV protocol with parameters params and settings settings, as side A, over the channel file using the read function read and the write function write. Side A uses its private key [l / 4]privkeya, its matching certificate certa, and side B's certificate certb. When it's all done, the shared key key gets determined. slay 🔥

Ожидается

Same conditions as bakeBMQVStart() (just swap privkeya → privkey and certa → cert).

Возвращает

ERR_OK if the protocol completed successfully, and an error code otherwise.

Аргументы

  • key — the shared key
  • params — the long-term parameters
  • settings — the settings
  • privkeya — the private key
  • certa — side A's certificate
  • certb — side B's certificate
  • read — the read function
  • write — the write function
  • file — the communication channel

bakeBMQVRunB()

err_t bakeBMQVRunB (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet privkeyb[], const bake_cert *
    certb, const bake_cert * certa, read_i read, write_i write, void * file)

Same energy, but now it's the BMQV protocol running as side B 💖 Parameters params, settings settings, channel file, functions read and write. Side B uses its private key [l / 4]privkeyb, its matching certificate certb, and side A's certificate certa. And boom, the shared key key gets determined.

Ожидается

Same conditions as bakeBMQVStart() (just swap privkeyb → privkey and certb → cert).

Возвращает

ERR_OK if the protocol completed successfully, and an error code otherwise.

Аргументы

  • key — the shared key
  • params — the long-term parameters
  • settings — the settings
  • privkeyb — side B's private key
  • certb — side B's certificate
  • certa — side A's certificate
  • read — the read function
  • write — the write function
  • file — the communication channel

bakeBMQVStart()

err_t bakeBMQVStart (void * state, const bign_params * params, const
    bake_settings * settings, const octet privkey[], const bake_cert * cert)

Builds up, inside state, all the data structures the BMQV protocol needs — using parameters params, settings settings, the private key [l / 4]privkey, and the certificate cert of the corresponding public key. setting the stage, main character energy 👑

Предусловие

bakeBMQV_keep() octets are reserved at the address state.

Ожидается

  • [ERR_BAD_PARAMS] — parameters params are correct.
  • [ERR_BAD_INPUT] — the pointer settings->helloa is null, or the buffer [settings->helloa_len]settings->helloa is correct. The same requirement applies to the fields settings->hellob and settings->hellob_len.
  • [ERR_BAD_RNG] — the generator settings->rng (with state settings->rng_state) is correct.
  • The generator settings->rng is cryptographically strong. (do not skip this one, fr fr 🔥)
  • [ERR_BAD_CERT] — the certificate cert is correct.
  • The key privkey and the certificate cert are consistent with each other. If that consistency is broken, the protocol will finish with an error. 💀

Возвращает

ERR_OK if initialization completed successfully, and an error code otherwise.

Аргументы

  • state — the state
  • params — the long-term parameters
  • settings — the settings
  • privkey — the private key
  • cert — the certificate

bakeBMQVStep2()

err_t bakeBMQVStep2 (octet out[], void * state)

Does step 2 of the BMQV protocol with state state. Side B forms the message M1 = [l / 2]out.

Ожидается

bakeBMQVStart() < bakeBMQVStep2().

Возвращает

ERR_OK if the step completed successfully, and an error code otherwise.

Прим.

The hello message and side B's certificate are not transmitted inside M1. 🙈

Аргументы

  • out — the outgoing message M1
  • state — the state

bakeBMQVStep3()

err_t bakeBMQVStep3 (octet out[], const octet in[], const bake_cert * certb,
    void * state)

Does step 3 of the BMQV protocol with state state. Side A processes the message M1 = [l / 2]in and forms the message M2 = [l / 2 + (kca ? 8 : 0)]out. Side B's certificate certb gets used.

Ожидается

bakeBMQVStart() < bakeBMQVStep3().

Ожидается

bakeBMQVStep2() << bakeBMQVStep3().

Возвращает

ERR_OK if the step completed successfully, and an error code otherwise.

Прим.

Side A's certificate is not transmitted inside M2. 🦋

Аргументы

  • out — the outgoing message M2
  • in — the incoming message M1
  • certb — side B's certificate
  • state — the state

bakeBMQVStep4()

err_t bakeBMQVStep4 (octet out[], const octet in[], const bake_cert * certa,
    void * state)

Does step 4 of the BMQV protocol with state state. Side B processes the message M2 = [l / 2 + (kca ? 8 : 0)]in and forms the message M3 = [kcb ? 8 : 0]out. Side A's certificate certa gets used.

Ожидается

bakeBMQVStep2() < bakeBMQVStep4().

Ожидается

bakeBMQVStep3() << bakeBMQVStep4().

Возвращает

ERR_OK if the step completed successfully, and an error code otherwise.

Аргументы

  • out — the outgoing message M3
  • in — the incoming message M2
  • certa — side A's certificate
  • state — the state

bakeBMQVStep5()

err_t bakeBMQVStep5 (const octet in[8], void * state)

Does step 5 of the BMQV protocol with state state. Side A processes the message M3 = [8]in. This step only runs when B confirms the key (kcb == 0). like, conditional queen 💅

Ожидается

bakeBMQVStep5() < bakeBMQVStep3().

Ожидается

bakeBMQVStep4() << bakeBMQVStep5().

Возвращает

ERR_OK if the step completed successfully, and an error code otherwise.

Аргументы

  • in — the incoming message M3
  • state — the state

bakeBMQVStepG()

err_t bakeBMQVStepG (octet key[32], void * state)

Determines the shared secret key key obtained via the BMQV protocol with state state. the grand finale 🎀

Ожидается

bakeBMQVStep4() < bakeBMQVStepG().

Ожидается

If side B does not confirm the key, then bakeBMQVStep3() < bakeBMQVStepG(). If it does confirm, then bakeBMQVStep5() < bakeBMQVStepG().

Возвращает

ERR_OK if the step completed successfully, and an error code otherwise.

Аргументы

  • key — the shared key
  • state — the state

bakeBPACE_keep()

size_t bakeBPACE_keep (size_t l)

Returns the length of the state (in octets) for the BPACE protocol functions. same vibe as bakeBMQV_keep(), different protocol 🫶

Возвращает

The length of the state.

Аргументы

  • l — the security level

🌸 bakeBPACERunA 🌸

err_t bakeBPACERunA (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet pwd[], size_t pwd_len, read_i
    read, write_i write, void * file)

okay so bestie, this is the full-send version 💅 — the BPACE protocol runs top to bottom with parameters params and settings settings, and it's doing it as side A, over the channel file, using the read function read and the write function write. Side A is the one showing up with the password [pwd_len]pwd. And when the whole thing wraps up? The shared key gets determined and dropped right into key. iconic.

Expects — literally the same conditions as bakeBPACEStart(). That's it, that's the list. 🙈

Returns — ERR_OK if the protocol ran successfully, and an error code if it did not.

Arguments

  • key — the shared key
  • params — long-term parameters
  • settings — settings
  • pwd — the password
  • pwd_len — the password length
  • read — the read function
  • write — the write function
  • file — the comms channel

🦋 bakeBPACERunB 🦋

err_t bakeBPACERunB (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet pwd[], size_t pwd_len, read_i
    read, write_i write, void * file)

same vibe, different side ✨ — the BPACE protocol runs with parameters params and settings settings, except this time it's side B holding the mic, over the channel file with the read function read and the write function write. Side B is the one carrying the password [pwd_len]pwd. And yeah, the shared key gets determined and lands in key, no cap.

Expects — again, the conditions of bakeBPACEStart() all over again.

Returns — ERR_OK if the protocol completed successfully, or an error code otherwise.

Arguments

  • key — the shared key
  • params — long-term parameters
  • settings — settings
  • pwd — the password
  • pwd_len — the password length
  • read — the read function
  • write — the write function
  • file — the comms channel

🎀 bakeBPACEStart 🎀

err_t bakeBPACEStart (void * state, const bign_params * params, const
    bake_settings * settings, const octet pwd[], size_t pwd_len)

this is the setup era, bestie 🌸 — from the parameters params, the settings settings and the password [pwd_len]pwd, the data structures you need to actually run the BPACE protocol get built up inside state. everything starts here, fr fr.

Precondition — you already reserved bakeBPACE_keep() octets at the address state. no reserve, no service.

Expects [ERR_BAD_PARAMS] — the parameters params are correct.

Expects [ERR_BAD_INPUT] — the pointer settings->helloa is null, or the buffer [settings->helloa_len]settings->helloa is correct. same requirement applies to the fields settings->hellob and settings->hellob_len. (yes, both of them, don't be sneaky 👀)

Expects [ERR_BAD_RNG] — the generator settings->rng (with its state settings->rng_state) is correct.

Expects — the generator settings->rng is cryptographically strong. like, actually strong. this is not the place for a vibe-based RNG. 💀

Returns — ERR_OK if initialization succeeded, and an error code otherwise.

Arguments

  • state — the state
  • params — long-term parameters
  • settings — settings
  • pwd — the password
  • pwd_len — the password length

🧚 bakeBPACEStep2 🧚

err_t bakeBPACEStep2 (octet out[], void * state)

step 2 of the BPACE protocol, running with the state state ✨. Side B builds the message M1 = [l / 8]out.

Expects — bakeBPACEStart() < bakeBPACEStep2().

Returns — ERR_OK if the step went through, and an error code otherwise.

Note — side B's greeting message does NOT get passed along in M1. just so you know. 🙈

Arguments

  • out — the outgoing message M1
  • state — the state

💜 bakeBPACEStep3 💜

err_t bakeBPACEStep3 (octet out[], const octet in[], void * state)

step 3 of the BPACE protocol, state state in the building 🫶. Side A takes the message M1 = [l / 8]in, does its thing, and builds the message M2 = [5 * l / 8]out.

Expects — bakeBPACEStart() < bakeBPACEStep3().

Expects — bakeBPACEStep2() << bakeBPACEStep3().

Returns — ERR_OK if the step succeeded, and an error code otherwise.

Arguments

  • out — the outgoing message M2
  • in — the incoming message M1
  • state — the state

🍓 bakeBPACEStep4 🍓

err_t bakeBPACEStep4 (octet out[], const octet in[], void * state)

step 4 of the BPACE protocol, same state state energy 💖. Side B processes the message M2 = [5 * l / 8]in and builds the message M3 = [4 * l / 8 + (kcb ? 8 : 0)]out. look at that conditional, she's doing math ✨

Expects — bakeBPACEStep2() < bakeBPACEStep4().

Expects — bakeBPACEStep3() << bakeBPACEStep4().

Returns — ERR_OK if the step succeeded, and an error code otherwise.

Arguments

  • out — the outgoing message M3
  • in — the incoming message M2
  • state — the state

🌈 bakeBPACEStep5 🌈

err_t bakeBPACEStep5 (octet out[], const octet in[], void * state)

step 5 of the BPACE protocol with the state state 🦋. Side A handles the message M3 = [4 * l / 8 + (kcb ? 8 : 0)]in and builds the message M4 = [kca ? 8 : 0]out.

Expects — bakeBPACEStep3() < bakeBPACEStep5().

Expects — bakeBPACEStep4() << bakeBPACEStep5().

Returns — ERR_OK if the step succeeded, and an error code otherwise.

Arguments

  • out — the outgoing message M4
  • in — the incoming message M3
  • state — the state

⭐ bakeBPACEStep6 ⭐

err_t bakeBPACEStep6 (const octet in[8], void * state)

step 6 of the BPACE protocol, state state 🌸. Side B processes the message M4 = [8]in. and here's the thing, bestie — this step only happens when A confirms the key (kca == 0). otherwise she's just not running. periodt.

Expects — bakeBPACEStep4() < bakeBPACEStep6().

Expects — bakeBPACEStep5() << bakeBPACEStep6().

Returns — ERR_OK if the step succeeded, and an error code otherwise.

Arguments

  • in — the incoming message M4
  • state — the state

👑 bakeBPACEStepG 👑

err_t bakeBPACEStepG (octet key[32], void * state)

the moment we've all been waiting for 💅 — the shared secret key key gets determined, obtained via the BPACE protocol with the state state. main character energy, honestly.

Expects — bakeBPACEStep5() < bakeBPACEStepG().

Expects — if side A does not confirm the key, then bakeBPACEStep4() < bakeBPACEStepG(). if she does confirm it, then bakeBPACEStep6() < bakeBPACEStepG(). two roads, one destination 🫶

Returns — ERR_OK if the step succeeded, and an error code otherwise.

Arguments

  • key — the shared key
  • state — the state

🌸 bakeBSTS_keep 🌸

size_t bakeBSTS_keep (size_t l)

returns the length of the state (in octets) for the functions of the BSTS protocol ✨. like, how much room you gotta set aside. iykyk.

Returns — the length of the state.

Arguments

  • l — the security level

💖 bakeBSTSRunA 💖

err_t bakeBSTSRunA (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet privkeya[], const bake_cert *
    certa, bake_certval_i valb, read_i read, write_i write, void * file)

the BSTS protocol with parameters params and settings settings, running as side A over the channel file with the read function read and the write function write 🦋. Side A brings her private key [l / 4]privkeya, the matching certificate certa, and the function valb for checking side B's certificate. when it's done, the shared key key gets determined. slay.

Expects — the conditions of bakeBSTSStart() repeat (with privkeya swapped for privkey and certa swapped for сеrt).

Returns — ERR_OK if the protocol completed successfully, and an error code otherwise.

Arguments

  • key — the shared key
  • params — long-term parameters
  • settings — settings
  • privkeya — side A's private key
  • certa — side A's certificate
  • valb — the function that checks B's certificate
  • read — the read function
  • write — the write function
  • file — the comms channel

🎀 bakeBSTSRunB 🎀

err_t bakeBSTSRunB (octet key[32], const bign_params * params, const
    bake_settings * settings, const octet privkeyb[], const bake_cert *
    certb, bake_certval_i vala, read_i read, write_i write, void * file)

and the flip side 🫶 — the BSTS protocol with parameters params and settings settings, this time running as side B over the channel file with the read function read and the write function write. Side B uses her private key [l / 4]privkeyb, the matching certificate certb, and the function vala for checking side A's certificate. and yes, the shared key key gets determined at the end. both girls eat. 👑

Expects — the conditions of bakeBSTSStart() repeat (with privkeyb swapped for privkey and certb swapped for сеrt).

Возвращает ✨ — ERR_OK, если протокол успешно выполнен, и код ошибки в противном случае.

Аргументы 🎀 — вот они, все до одного, ничего не потерялось:

  • key — общий ключ
  • params — долговременные параметры
  • settings — настройки
  • privkeyb — личный ключ стороны B
  • certb — сертификат стороны B
  • vala — функция проверки сертификата A
  • read — функция чтения
  • write — функция записи
  • file — канал связи

err_t bakeBSTSStart (void * state, const bign_params * params, const bake_settings * settings, const octet privkey[], const bake_cert * cert)

okay so bakeBSTSStart — это типа "собираемся с силами перед протоколом BSTS" 💅 По параметрам params, настройкам settings, личному ключу [l / 4]privkey и сертификату cert соответствующего открытого ключа в state формируются структуры данных, необходимые для выполнения протокола BSTS. Просто разложила всё по полочкам, эстетично, main character energy.

Предусловие — по адресу state зарезервировано bakeBSTS_keep() октетов. Не зарезервировала? Ну всё, сама виновата 🙈

Ожидается (читай: без этого не взлетит):

  • [ERR_BAD_PARAMS] — параметры params корректны.
  • [ERR_BAD_INPUT] — settings->kca == TRUE && settings->kcb == TRUE.
  • [ERR_BAD_INPUT] — указатель settings->helloa нулевой, либо буфер [settings->helloa_len]settings->helloa корректен. Аналогичное требование касается полей settings->hellob, settings->hellob_len.
  • [ERR_BAD_RNG] — генератор settings->rng (с состоянием settings->rng_state) корректен.
  • Ожидается — генератор settings->rng является криптографически стойким. это не опционально, bestie
  • [ERR_BAD_CERT] — сертификат cert корректен.
  • Ожидается — ключ privkey и сертификат cert согласованы. Если согласование нарушено, то протокол будет завершен с ошибкой. не сошлись ключами — не сошлись вообще, periodt

Возвращает — ERR_OK, если инициализация успешно выполнена, и код ошибки в противном случае.

Аргументы 🦋:

  • state — состояние
  • params — долговременные параметры
  • settings — настройки
  • privkey — личный ключ
  • cert — сертификат

err_t bakeBSTSStep2 (octet out[], void * state)

Выполняется шаг 2 протокола BSTS с состоянием state. Сторона B формирует сообщение M1 = [l / 2]out. Вот и первое сообщение, полетело ✨

Ожидается — bakeBSTSStart() < bakeBSTSStep2(). То есть порядок вызовов важен, не переставляй 🙅

Возвращает — ERR_OK, если шаг успешно выполнен, и код ошибки в противном случае.

Прим. — Приветственное сообщение стороны B в M1 не передаются. Так задумано, это фича, не баг 🎀

Аргументы:

  • out — выходное сообщение M1
  • state — состояние

err_t bakeBSTSStep3 (octet out[], const octet in[], void * state)

Выполняется шаг 3 протокола BSTS с состоянием state. Сторона A обрабатывает сообщение M1 = [l / 2]in и формирует сообщение M2 = [3 * l / 4 + cert->len + 8]out. Сторона A врывается в чат 💅

Ожидается — bakeBSTSStart() < bakeBSTSStep3().

Ожидается — bakeBSTSStep2() << bakeBSTSStep3(). Двойная стрелочка, двойная ответственность, iykyk.

Возвращает — ERR_OK, если шаг успешно выполнен, и код ошибки в противном случае.

Аргументы:

  • out — выходное сообщение M2
  • in — входное сообщение M1
  • state — состояние

err_t bakeBSTSStep4 (octet out[], const octet in[], size_t in_len, bake_certval_i vala, void * state)

Выполняется шаг 4 протокола BSTS с состоянием state. Сторона B обрабатывает сообщение M2 = [in_len]in и формирует сообщение M3 = [l / 4 + cert->len + 8]out. Сторона B проверяет присланный в M2 сертификат стороны A с помощью функции vala. доверяй, но проверяй 🧚

Ожидается — bakeBSTSStep2() < bakeBSTSStep4().

Ожидается — bakeBSTSStep3() << bakeBSTSStep4().

Возвращает — ERR_OK, если шаг успешно выполнен, и код ошибки в противном случае.

Аргументы:

  • out — выходное сообщение M3
  • in — входное сообщение M2
  • in_len — длина in
  • vala — функция проверки сертификата стороны A
  • state — состояние

err_t bakeBSTSStep5 (const octet in[], size_t in_len, bake_certval_i valb, void * state)

Выполняется шаг 5 протокола BSTS с состоянием state. Сторона A обрабатывает сообщение M3 = [in_len]in. Сторона A проверяет присланный в M3 сертификат стороны B с помощью функции valb. Взаимная проверка, как в здоровых отношениях 💖

Ожидается — bakeBSTSStep5() < bakeBSTSStep3().

Ожидается — bakeBSTSStep4() << bakeBSTSStep5().

Возвращает — ERR_OK, если шаг успешно выполнен, и код ошибки в противном случае.

Аргументы:

  • in — входное сообщение M3
  • in_len — длина in
  • valb — функция проверки сертификата стороны B
  • state — состояние

err_t bakeBSTSStepG (octet key[32], void * state)

Определяется общий секретный ключ key, полученный с помощью протокола BSTS с состоянием state. вот он, финальный ключик, ради него всё и было 🔑

Ожидается — bakeBSTSStep4() < bakeBSTSStepG().

Ожидается — Если сторона B не подтверждает ключ, то bakeBSTSStep3() < bakeBSTSStepG(). Если подтверждает, то bakeBSTSStep5() < bakeBSTSStepG(). Два пути, один ключ, выбирай с умом ✨

Возвращает — ERR_OK, если шаг успешно выполнен, и код ошибки в противном случае.

Аргументы:

  • key — общий ключ
  • state — состояние

err_t bakeKDF (octet key[32], const octet secret[], size_t secret_len, const octet iv[], size_t iv_len, size_t num)

По секретному слову [secret_len]secret, дополнительному слову [iv_len]iv и номеру num строится ключ key. это буквально генератор ключей из секретика 🍓

Возвращает — ERR_OK, если ключ успешно построен, и код ошибки в противном случае.

Прим. — Реализован алгоритм 6.1.3.

Аргументы:

  • key — ключ
  • secret — секретное слово
  • secret_len — длина secret
  • iv — дополнительное слово
  • iv_len — длина iv
  • num — номер ключа

err_t bakeSWU (octet pt[], const bign_params * params, const octet msg[])

При долговременных параметрах params по сообщению [l / 4]msg строится точка [l / 2]pt эллиптической кривой, описываемой params. Сообщение в точку, точка в кривую — магия, но задокументированная 🦋

Ожидается:

  • [ERR_BAD_PARAMS] — Параметры params корректны.

Возвращает — ERR_OK, если точка успешно построена, и код ошибки в противном случае.

Прим. — Реализован алгоритм 6.2.3.

Аргументы:

  • pt — точка
  • params — долговременные параметры
  • msg — сообщение

✨ Автор ✨

Автоматически создано Doxygen для Библиотека Bee2 из исходного текста. Доксиген сделал всю работу, а мы просто навели красоту 💅


И вот, bestie, мы дошли до самого конца страницы 💖 Это был bake.h(3) из Библиотека Bee2, датированный Вс 25 Янв 2026 00:00:00. Ты это прочитала. Ты это осилила. Абсолютная победа, ate and left no crumbs 👑🎀✨

📦 where this page comes from