-
Notifications
You must be signed in to change notification settings - Fork 160
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
aes-gcm online mode #424
Comments
I would really prefer not to add such a feature to the For one thing, it significantly complicates both the API design and implementing one-pass encryption/decryption (#74), which we are just starting to work on (#414). For maximum performance we're trying to avoid any kind of buffering, which any sort of streaming API almost certainly necessitates. Beyond that, I somewhat regret adding such an API to the EAX crate. It's a dangerous footgun. And now I see it's a slippery slope towards adding such a (mis)feature to all of our AEAD crates.
Protocols which rely on large AEAD messages are badly designed and we shouldn't encourage their proliferation. Adding online modes weakens AEAD security (IND-CCA3), and potentially opens up implementations to chosen ciphertext attacks. Can you give more information on your use case and why STREAM is inapplicable? |
Ok, I think warning the user is sufficient as this kind of process is allowed by the standard but I understand your point. |
We generally follow the guidance in RFC5116 regarding how to construct AEAD APIs. RFC5116 § 2.2 describes a one-shot decryption API:
I am unaware of any specification which allows for the disclosure of unauthenticated decrypted plaintext prior to authenticating the tag. |
Regarding this:
Modern cryptographic API design has largely moved to a notion of "misuse resistant" APIs, i.e. APIs that are hard-to-misuse, which try to minimize the amount of instructions a user must successfully comprehend to use the construction safely. This is a property that's especially desirable when using AEAD constructions, as for symmetric encryption these APIs are considered the minimum viable API for non-sophisticated users. |
If you use e.g. 1MB chunks, STREAM adds 16 bytes of overhead for every 1048576 bytes. That's 0.0015% overhead. |
Hi, I understand and I agree with the fact that in RustCrypto the primitives have to be as resistant as possible to misusage. (for the 0.0015% it's not only storage but also every download and I don't have all the control over the full protocol) |
FWIW it should be fairly easy to fork |
Going to close this, but if you do end up forking |
Hello,
Is it possible to have an online mode for AES-GCM (like EAX) ? I want to encrypt large chunk of data in a memory constraint way. The standard allows to cipher up to 64GiB.
Note that I'm aware of the STREAM mode but it does not allow the ciphering of a large block all at once
I'm also aware of the decryption unsafety but it is inherent of large chunk ciphering
The text was updated successfully, but these errors were encountered: