Traditional block ciphers work on fixed blocks of data—as an example, AES is well-defined for 128/192/256 bits. But one of the issues is the need for padding—so if you need to encrypt small amounts of data you may end with a huge difference in input vs. output size. As an example, using AES/128 on ECB mode to encrypt an IPv4 address results in an input size of 32 bits, but an output size of 128 bits. This may not be desired for some applications.
To address such needs, we have designed the FNR encryption scheme. FNR stands for Flexible Naor and Reingold. Our proposed encryption scheme is a practical variant of Naor and Reingold’s work. We are releasing the reference implementation of the FNR encryption scheme under open source license LGPLv2.
FNR is an experimental small domain block cipher for encrypting objects (< 128 bits) like IPv4 addresses, MAC addresses, arbitrary strings, etc. while preserving their input lengths. Such length preserving encryption would be useful when encrypting sensitive fields of rigid packet formats, database columns of legacy systems, etc. in order to avoid any re-engineering efforts for privacy preservation.
The demo application written is for encryption of IPv4 addresses (the cipher preserves their formats as well if needed). When FNR is used in ECB mode, it realizes a deterministic encryption scheme. Like all deterministic encryption methods, this does not provide semantic security, but determinism is needed in situations where anonymizing telemetry and log data (especially in cloud based network monitoring scenarios) is necessary. This also lends itself nicely to achieving searchable encryption operations such as provided the cryptdb project. Due to the length preserving nature in FNR, it is a better fit in some scenarios than cryptdb, as the cryptdb method expands the data size, resulting in bandwidth and storage savings.
Importantly this is still an experimental block cipher, not ready for production yet.
 Naor, Moni, and Omer Reingold. “On the Construction of Pseudorandom Permutations: Luby—Rackoff Revisited.” Journal of Cryptology 12.1 (1999): 29-66