Coverage increased (+0.04%) to 91.696% when pulling 64d15c1 on adamantike:ceil-division into 7ebae9f on sybrenstuvel:master.

Why is not using the math library a good thing?

It is! However, I assumed the current solution was trying to avoid using math, maybe because of performance reasons. Feel free to close this PR if that's not the case, and I will use the built in ceil for MGF

I think avoiding the math module is irrelevant. However, your new approach doesn't convert an integer to a float and then back to an integer, and that'll save some time. Here are the timings:

In [1]: %timeit via_divmod(number)
The slowest run took 8.74 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 296 ns per loop

In [2]: %timeit via_math_module(number)
The slowest run took 10.96 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 409 ns per loop

I used this simplified code to do the tests:

#!/usr/bin/env python3

import secrets
import math
import timeit


def bit_size(number):
    return number.bit_length()


def via_math_module(number):
    return int(math.ceil(bit_size(number) / 8.0))


def via_divmod(number):
    quanta, mod = divmod(bit_size(number), 8)

    if mod:
         quanta += 1
    return quanta


number = int.from_bytes(secrets.token_bytes(2048), 'little')

and then ran that with ipython -i speedtest_pr_88.py to get an interactive session to run the timing commands.

We are talking about nanoseconds vs simplicity. However, as this method is super simple and the new tests cover it, I am OK with any approach in this case!

Worth to mention that it's good not to deal with floats, though