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

aes-gcm online mode #424

Closed
BoOTheFurious opened this issue May 13, 2022 · 8 comments
Closed

aes-gcm online mode #424

BoOTheFurious opened this issue May 13, 2022 · 8 comments

Comments

@BoOTheFurious
Copy link

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

@tarcieri
Copy link
Member

tarcieri commented May 13, 2022

I would really prefer not to add such a feature to the aes-gcm crate.

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.

Note that I'm aware of the STREAM mode but it does not allow the ciphering of a large block all at once

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?

@BoOTheFurious
Copy link
Author

Ok, I think warning the user is sufficient as this kind of process is allowed by the standard but I understand your point.
In my case it is to use it in an All-or-Nothing Transform, where STREAM have a too large (size) overhead, and where the decryption weakness is not into concern.

@tarcieri
Copy link
Member

We generally follow the guidance in RFC5116 regarding how to construct AEAD APIs.

RFC5116 § 2.2 describes a one-shot decryption API:

The authenticated decryption operation has four inputs: K, N, A, and
C, as defined above. It has only a single output, either a plaintext
value P or a special symbol FAIL that indicates that the inputs are
not authentic. A ciphertext C, a nonce N, and associated data A are
authentic for key K when C is generated by the encrypt operation with
inputs K, N, P, and A, for some values of N, P, and A. The
authenticated decrypt operation will, with high probability, return
FAIL whenever the inputs N, P, and A were crafted by a nonce-
respecting adversary that does not know the secret key (assuming that
the AEAD algorithm is secure).

I am unaware of any specification which allows for the disclosure of unauthenticated decrypted plaintext prior to authenticating the tag.

@tarcieri
Copy link
Member

tarcieri commented May 14, 2022

Regarding this:

I think warning the user is sufficient

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.

@tarcieri
Copy link
Member

STREAM have a too large (size) overhead

If you use e.g. 1MB chunks, STREAM adds 16 bytes of overhead for every 1048576 bytes.

That's 0.0015% overhead.

@BoOTheFurious
Copy link
Author

Hi, I understand and I agree with the fact that in RustCrypto the primitives have to be as resistant as possible to misusage.
My use case is specific and should perhaps be the subject of an external crate for more experienced user. (I don't know what is the best way to have an usable API for non-sophisticated user without restrict legitimate (and rare) usage by more sophisticated users)

(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)

@tarcieri
Copy link
Member

FWIW it should be fairly easy to fork aes-gcm and add streaming encryption/decryption support. The overall code size is fairly small with the bulk of the functionality in the aes and ghash crates

@tarcieri
Copy link
Member

Going to close this, but if you do end up forking aes-gcm for these purposes feel free to post a link here for others who might have similar use cases

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