BN_SET_FLAGS(3)

πŸ“¦ version 4.4.0, in alpine 3.24, arch rolling

πŸ’… BN_SET_FLAGS β€” bestie's guide to BIGNUM flags ✨

okay so this is from BN_SET_FLAGS(3), part of the Library Functions Manual β€” yes, the Library Functions Manual, we're being fancy today πŸŽ€ β€” and it's literally all about turning flags on and peeking at them on BIGNUM objects. no cap.


✨ NAME ✨

BN_set_flags, BN_get_flags β€” enable and inspect flags on BIGNUM objects πŸ¦‹


🌸 SYNOPSIS 🌸

it's giving "library β€œlibcrypto”" energy first, then:

#include <openssl/bn.h>

void
BN_set_flags(BIGNUM *b, int flags);

int
BN_get_flags(const BIGNUM *b, int flags);

πŸ‘‘ DESCRIPTION πŸ‘‘

so BN_set_flags() enables the given flags on b. and the flags argument can contain zero or more of the following constants OR'ed together (yes, zero is allowed, she can be empty, we support her πŸ’œ):

  • BN_FLG_CONSTTIME β€” if this flag is set on the dividend a or the divisor d in BN_div(3), on the exponent p in BN_mod_exp(3), or on the divisor a or the modulus n in BN_mod_inverse(3), these functions pick algorithms whose execution time is independent of the respective numbers. which is the whole point: avoid exposing sensitive info to timing side-channel attacks πŸ”₯. this flag is off by default for BIGNUM objects created with BN_new(3).
  • BN_FLG_MALLOCED β€” if this flag is set, BN_free(3) and BN_clear_free(3) will not only clear and free the components of b, but also b itself, like, the whole girl πŸ’€. this flag is set internally by BN_new(3). setting it manually on an existing BIGNUM object is usually a bad idea and can cause calls to free(3) with bogus arguments. so… don't πŸ™ˆ.
  • BN_FLG_STATIC_DATA β€” if this flag is set, BN_clear_free(3) will neither clear nor free the memory used for storing the number. consequently, setting it manually on an existing BIGNUM object is usually a terrible idea that can cause both disclosure of secret data and memory leaks. two for one, but the bad kind 😭. this flag is automatically set on the constant BIGNUM object returned by BN_value_one(3).

and BN_get_flags() interprets flags as a bitmask and returns those of the given flags that are set in b, OR'ed together β€” or 0 if none of the given flags is set. the flags argument has the same syntax as for BN_set_flags(). iykyk πŸ’…


⭐ RETURN VALUES ⭐

BN_get_flags() returns zero or more of the above constants, OR'ed together. that's it, that's the return value 🫢


🌈 SEE ALSO 🌈

BN_mod_exp(3), BN_mod_inverse(3), BN_new(3), BN_with_flags(3) β€” go read those too, be a well-read icon πŸ‘‘


🧚 HISTORY 🧚

BN_set_flags() and BN_get_flags() first appeared in SSLeay 0.9.1 and have been available since OpenBSD 2.6. ancient. iconic. still serving ⭐


πŸ“ CAVEATS πŸ“

no public interface exists to clear a flag once it is set. like, once it's on, it's ON, no take-backs. so think twice before using BN_set_flags(). fr fr.

πŸ’€ BUGS πŸ’€

  • even if the BN_FLG_CONSTTIME flag is set on a or b, BN_gcd() neither fails nor operates in constant time β€” potentially allowing timing side-channel attacks. not her finest moment 😬.
  • even if the BN_FLG_CONSTTIME flag is set on p, if the modulus m is even, BN_mod_exp(3) does not operate in constant time, potentially allowing timing side-channel attacks. the even modulus really said "not today" πŸ™ƒ.
  • if BN_FLG_CONSTTIME is set on p, BN_exp() fails instead of operating in constant time. at least she's honest about it πŸŽ€.

and that's the whole page, bestie 🫢 this one's from Debian, dated June 8, 2025 β€” slay, go set your flags responsibly, and remember: you can't unset them πŸ’…βœ¨

πŸ“¦ where this page comes from