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

Stream API #3

Closed
buhman opened this issue Mar 9, 2017 · 3 comments
Closed

Stream API #3

buhman opened this issue Mar 9, 2017 · 3 comments

Comments

@buhman
Copy link

buhman commented Mar 9, 2017

What do you think about providing one?

Usage would look something like this:

encryptor = AEAD(**kwargs).stream()

while True:
    data = read_chunk()
    out = encryptor.write(data)
    write_chunk(out)

encryptor.close()

It would also be nice to wrap all of that in __enter__ and __exit__ methods as well.

@Ayrx
Copy link
Owner

Ayrx commented Apr 16, 2017

Hi @buhman, apologies for the late reply! I have been pretty swamped the past month.

A stream API would be a nice thing to have but care must be taken to not allow the use of decrypted plaintext before completing the authentication check. If someone comes up with a more complete API and implementation proposal I would be very happy to review it. However, the key criteria that it must be extremely simple to use and extremely difficult to misuse.

@buhman
Copy link
Author

buhman commented Apr 18, 2017

not allow the use of decrypted plaintext before completing the authentication check

I played with this idea in cryptio. The way I did it there is the tag checking happens on close() (throws InvalidTag).

The way I was thinking of using that is some api service that has at-rest encryption for large blobs. Because an HTTP body would follow headers, and because the service would generally want to send plaintext as soon as it's available, I couldn't really think of how to make the "deferred plaintext invalidation" work--you can't really retroactively change HTTP status codes for example.

Have you considered this?

@Ayrx
Copy link
Owner

Ayrx commented Jul 31, 2017

I have given this some thought over the past few months and decided that I don't feel comfortable implementing an API like this without a concrete specification that has been reviewed by actual cryptographers to follow.

Thanks for bringing this up though!

@Ayrx Ayrx closed this as completed Jul 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants