Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/crypto: Add FF1 and FF3 Format Preserving Encryption algorithms #18752

Closed
anitgandhi opened this issue Jan 22, 2017 · 9 comments
Closed

Comments

@anitgandhi
Copy link
Contributor

Introduction

I have a package written that implements the new NIST approved FF1 and FF3 Format Preserving Encryption (FPE) algorithms. You can read about FF1 and FF3 in the NIST 800-38G Recommendation.

While the algorithms are technically written to use any underlying block cipher, as of right now, only AES is approved to be used. As such, they are considered as new modes of AES.

There is a partial existing implementation however it generally only works with strings that aren't too long, as the uint64 buffers overflow; also it only implements FFX ("old" name of FF1, though the two are mathematically equivalent).

Proposal

I'm proposing that these be added to the golang.org/x/crypto package as fpe/ff1 and fpe/ff3 sub-packages.

If this proposal is accepted, I volunteer to provide the implementation.

Notes

As of right now, the way I have written my implementation, it requires Go 1.6 as it uses math/big Text function for interpreting numbers as strings of a certain base/radix. I will look into better backwards-compatible support if requested.

NIST has also provided test vectors, which I used for the test cases.

CC: @agl

@titanous titanous added this to the Proposal milestone Jan 23, 2017
@agl
Copy link
Contributor

agl commented Jan 23, 2017

Are these needed for implementing anything that Go coders might want to implement? (The bar for x/crypto is pretty low, but things are expected to be generally usefully to at least a small number of people.)

@minux
Copy link
Member

minux commented Jan 23, 2017 via email

@anitgandhi
Copy link
Contributor Author

I agree that it should at least be used/needed by others. I can say that it is certainly being used in my place of employment.

Perhaps part of the reason is that these algorithms themselves are relatively new. While their use is inherently niche, part of the reason they might not have propagated into wider scale use is because they are not as well known yet. I haven't even seen a reference implementation yet either.

I would understand if this proposal was declined for that reason :)

@anitgandhi
Copy link
Contributor Author

Gentle ping

@minux
Copy link
Member

minux commented Feb 1, 2017 via email

@rsc
Copy link
Contributor

rsc commented Apr 3, 2017

By putting this in the crypto repo we're taking on ownership and maintenance, so there is a cost that needs to be balanced with benefit to users. It sounds like there are very few users right now. Based on that, it sounds like we should decline this proposal for now (like Minux said, I'd encourage you to publish your own ff1/ff3 implementation GitHub for use with 'go get'), and then revisit if/when those become important.

@jefferai
Copy link

@rsc / @minux We get this request quite often from Vault users. I think the visibility issue is that most uses of this kind of encryption are in the financial and government worlds, and they generally don't like to talk publicly about anything they're doing that is security-related.

@anitgandhi
Copy link
Contributor Author

@jefferai and to anyone else who comes across this issue:

As I wrote the standalone/go-gettable package for my employer, we are evaluating whether or not we can open source the code. Depending on how things move forward, I will leave an update if I am able.

Thanks.

@anitgandhi
Copy link
Contributor Author

Good news folks; we've just open sourced the library!

Feel free to take a look and review/contribute!

https://github.com/capitalone/fpe

@golang golang locked and limited conversation to collaborators Sep 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants