Format-Preserving Encryption Activity
Format-Preserving Encryption Library for Java
Brought to you by:
weydstone
Activity for Format-Preserving Encryption
-
Kevin Dean posted a comment on ticket #5
I'm not a Maven guru (yet), but I found this rather clever workaround: https://stackoverflow.com/questions/362055/setting-up-a-maven-repository-using-sourceforges-file-servers
-
It's a hybrid of a static (legacy) and dynamic system. I can't discuss the project in detail right now, but it's akin to having multiple data fields that need to be encrypted in place. The data fields all have different formats and all are candidates for FPE; rather than create an FPE implementation for each, I've created a library that you can feed a grep-like format for each field into and it comes up with the maximum radix (R) and minimum text length (L) to do the FPE work. Original text is converted...
-
Kai Johnson posted a comment on ticket #5
I hadn't really looked at what it might take to host it on SourceForge. Would you like to help with the setup?
-
Inconsistency in FF1 implementation
-
If you're performing operations that are within the range of the FF1 implementation, then I agree that you should use it rather than the FF1Parameters implementation for FFX. The FF1Parameters implementation demonstrates that it is possible to implement FF1 on FFX, but it's certainly not as well vetted as the NIST-approved FF1 algorithm. I'll close the ticket as you suggest. I'm curious what you're using FF1 for, though. FPE generally makes sense when you're forced into using a specific radix and...
-
Any plans for a Maven repository?
-
The other errors are all edge cases with a small radix; I'm getting "radix^minlen must be greater than or equal to 100", which was fine with a smaller minimum text size. I'll stick to the pure FF1 implementation rather than the FFX with FF1Parameters. Thanks for your help, and you may close this.
-
Thanks for looking into it. The code that triggered the failure in the first place uses an algorithm that optimizes for the maximum value of the radix and the minimum value of length for the encyrption/decryption process. I modified the code to require a minimum length of 4 (rather than the minimum length of 2 in the spec) and the test case now works. However, other errors have cropped up so I'm going to have to take a deeper look over the next few days.
-
The issue here is a subtle. FF1 is defined to use exactly ten rounds (i.e. iterations of the Feistel structure). FFX relies on the parameters to specify the number of rounds, and the FF1Parameters are hard coded to use ten rounds to match the FF1 specification. However, FFX also specifies lower bounds on the number of rounds to avoid known attacks. The lower bounds are specified at the bottom of p. 4 in The FFX Mode of Operation for Format-Preserving Encryption with some further discussion in Appendix...
-
Thanks for posting the issue and the source code. I'll take a look at it as soon as I get a chance, but it might be a couple of weeks.
-
Inconsistency in FF1 implementation
-
Corrected parameters for NIST FF1 Sample #6.
-
rearrange code for build
-
Paul Bemowski created merge request #1
rearrange code for build
-
Gordon Young posted a comment on discussion General Discussion
Hello! thank you for creating & opensourcing this library! Do you have any interest in contributing this package to the BouncyCastle project? I'm of the opionion that pulling this into BC would make opensource FPE more genrally available. Again thank you! Best regards, ~Gordon
-
BUG IFX
-
Thanks for getting in touch. Yes, there's a bug, but it might not be what you thing it is. For the radix array { 6, 10, 10 }, the input array { 6, 4, 7 } is actually invalid. As described in the documentation, the input array X is "a plaintext vector of length(W) integers such that 0 ≤ X[i] < W[i]," where W is the radix array. In this case, the value of X[0] is equal to the value of W[0], which is out of the permitted range. In fact, you should have gotten an exception for the inputs you provided,...
-
Fixed a bug that allowed input with elements of X equal to the corresponding radix in W.
-
Michiel van Grinsven modified a comment on ticket #2
BTW, when encrypting 999 with radix {9,9,9}, this just break the protocol. No matter which seed, decrypted 110 always happens: 999 (original) 230 (encryped) 110 (decrypted)
-
This is true for every number that is max for the radix range: 888 (max for radix {8,8,8}) 461 (this one differs from seed to seed) 110 (this one is always the same)
-
This is true for every number that is max for the radix range: 888 (max for radix {8,8,8}) 461 (this one differs from seed to seed) 110 (this one is always the same
-
BTW, when encrypting 999 with radix {9,9,9}, this just break the protocol. No matter which seed, this always happens: 999 (original) 230 (encryped) 110 (decrypted)
-
In other words, when encrypting 999 with radix {9,9,9} this translates the same as 099. There is a collision in the protocol.
-
BUG IFX
-
When I looked for a site to host this project, it looked like SourceForge was the...
-
sparty02 posted a comment on discussion General Discussion
First off, thanks for the great work on getting this library up and open sourcing...
-
Dan Kandinsky posted a comment on ticket #1
see this one for example: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/p...
-
I'm not aware of any patents on the FFX, A2, A10, FF1 or FF3 algorithms, but if there...
-
Patents
-
Added experimental IFX method of format-preserv...
-
New release with implementation of FFX and the ...
-
Clean build, clean javadocs.
-
First push to bitbucket.
1
