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

Does it make sense to support a binary encoding? #7

Open
fdr opened this issue May 9, 2014 · 13 comments
Open

Does it make sense to support a binary encoding? #7

fdr opened this issue May 9, 2014 · 13 comments

Comments

@fdr
Copy link

fdr commented May 9, 2014

I've noticed that encrypted payloads are base64 coded. Does it make any sense to have a binary mode? I'd like to use Fernet in a high-volume way (maybe that's against design ethos, I am not sure) and avoid paying for base64 in size blowup if possible.

@kr
Copy link
Contributor

kr commented May 10, 2014

Yes, totally makes sense IMO. I've wished for this myself once or twice.

@kr kr added the enhancement label May 10, 2014
@fdr
Copy link
Author

fdr commented May 12, 2014

How would you go about doing it while keeping Fernet's format self-describing? Use of the "version" byte (more like "variant" in this case?)

@kr
Copy link
Contributor

kr commented May 13, 2014

My first thought is to have two separate entry points and require
the user to know a priori which one to use. As you note, the version
byte would not match and/or it would be an invalid base64 encoding
if one used the wrong one, so there's no danger there. But somehow
it feels like making the programmer explicitly choose is more better?
It's what I'd expect anyway.

@kr
Copy link
Contributor

kr commented May 13, 2014

I guess that would be sort of against the "you can't do it wrong" spirit
of fernet though. Open to suggestions. cc @tmaher

@tmaher
Copy link

tmaher commented May 13, 2014

I'm weakly opposed to adding it as an option, mostly to prevent option bloat.

@alex - I'm more strongly opposed if pyca isn't going to add it as well.

@alex
Copy link

alex commented May 13, 2014

I'd have to think about it, but probably we'd add it as well /cc @dreid.

@dreid
Copy link

dreid commented May 13, 2014

I'm +1 on supporting the pre-base64 encoded form.

I assume this would just be for tokens and not affect keys?

@fdr
Copy link
Author

fdr commented May 13, 2014

Yeah: tokens only.

@kr
Copy link
Contributor

kr commented May 13, 2014

Though this has crossed my mind, I've never wanted it enough
to even bring it up in conversation before. And I agree with the
desire to avoid option bloat.

Note that one can do it oneself as a workaround. It's not hard
and IIUC not security sensitive to undo the base64 encoding
before storing or transmitting it, then redo it before decrypting.
It's wasteful of CPU, but if the point is to save space, maybe
that's okay.

@fdr
Copy link
Author

fdr commented May 13, 2014

How about this:

Before making any detailed decisions, I do have a specific application and lightweight benchmark. I'll hack in binary (aka "does less") fernet and see how much it matters, and post my result.

@kr
Copy link
Contributor

kr commented Sep 2, 2014

@fdr any results from your performance tests?

@fdr
Copy link
Author

fdr commented Sep 2, 2014

On Tue, Sep 2, 2014 at 1:10 AM, Keith Rarick [email protected]
wrote:

@fdr https://github.com/fdr any results from your performance tests?

Regretfully I had to abandon the project before having the need to complete
them.

@rafael2k
Copy link

Hi all. I'm interested in using binary bitstream communication using Fernet. How is the status binary encoding support in Fernet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants