The setup.py file which appears on PyPI does not appear in this repository.

You may want to set up a CI workflow which publishes tagged commits to PyPI automatically, and for that you'd need to include the setup.py.

Running the example code from the README with

plaintext = "0000000000000000"

produces the error

ValueError: plaintext string is not within base/radix {self.radix}

The relevant part of the Python code is

        # Check if the plaintext message is formatted in the current radix
        x = int(plaintext, self.radix)
        if x == 0:
            raise ValueError("plaintext string is not within base/radix {self.radix}")

I don't follow the logic here since if there is a problem with the string not conforming to the base, the int() function should raise a ValueError, for example

>>> int("a", 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 2: 'a'

Thus it seems to me like the check for x == 0 should be removed.

The current release on PyPI is from Mar 17. It may be worth considering a workflow for automatically publishing tagged releases to PyPI, for example:

https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

We are currently using structlog in our application and I noticed a weird bug when using the FF3 package.

As soon as FF3 gets used in our code our structured logging breaks. This seems to be due to the use of logging.debug() in the FF3 package. We believe that its because logging.debug() uses the root logger.

Here an example of the use of this function in the FF3 code:
logging.debug(f"Tweak: {tweak}, tweakBytes:{tweakBytes.hex()}")

We suggest switching it to using a named logger like this:

logger = logging.getLogger(__name__) 
logger.debug(f"Tweak: {tweak}, tweakBytes:{tweakBytes.hex()}")

For example, a Chinese string "你好"?

Thanks for this! I'm using your library atm to protect some testing data and it works great. But how can I generate an ff3-1 key and tweak for usage with aes256 block cipher please?

When I do the following:

c = FF3Cipher(key, tweak, radix=36)
my_str = '100000'
fpe = c.encrypt(my_str)

I get this error:
ValueError: string 000 is not within base/radix

The same error will occur with my_str = '000001' but does not occur with my_str = '100001'. Is this expected? I don't see anything in the specification about a limitation on leading / trailing zeros.

Hi There,

I'm running this on Python 3.9.2 and I'm getting the package ff-3.py

\lib\site-packages\ff3\ff3.py", line 90, in init self.aesBlock = AES.AESCipher(reverse_string(self.key))

Code from ff-3.py line 90

aes.NewCipher automatically returns the correct block based on the length of the key

    # Always use the reversed key since Encrypt and Decrypt call ciph expecting that

    self.aesBlock = AES.AESCipher(reverse_string(self.key))

I've imported the package crypto. cipher but I couldn't find the AESCipher but it seems to be under crypto, let me know what do you think?

I just wanted to let you know that I have used some of your test vectors to verify my C-implementation of the FPE algorithms. Of course I have mentioned the source and credit. Please feel free to check out the testvectors folder of this repository and inform me of any issues.

Cheers

Hello, I'm using this module to convert the id of a order to a 12-digit confirmation number, for example:

Order ID 1 = 000000000001 --> 457845269874
Order ID 2 = 000000000002 --> 784378928745

My code goes like this:

key = 'C4D91A3F7B61834E90FD72563CACF01E'
tweak = 'ABD39280979565'
c = FF3Cipher(key, tweak)

order_id = 1
order_id_padded = f'{order_id:012}'
confirmation_number = c.encrypt(order_id_padded)

I assume that as long as I don't change the key or the tweak I should not have any collision issues of two order ids generating the same confirmation number. Is this correct?

Thanks for your time

I started using the FF3-1 implementation recently and its super cool. However I was approached if FF1 would also be an option.
I was told its "better" as in "more secure" than FF3-1.

I dont know if that is true, but I certainly know that I can not implement FF1 in Python now.

Would it be something to consider to also add FF1 support please?

Having a broad range of environment-specific stuff is good in my experience. That allows contributors to use whatever tools they want without going through the mess we saw with the .idea/ files. If the Python package is set up properly, the .gitignore won't be included in the PyPI distribution.

In the end, it won't prevent you from git adding files. It just prevents git from suggesting irrelevant files to add.

I read over @PuspenduBanerjee's .gitignore and it looks perfectly good to me. I'd recommend restoring it. Or at the very least find a standard Python-oriented .gitignore from somewhere.