问题
We are having an android app which a decrypting and encrypting large (up to 100MB) files over HTTP-Streams.
Therefore, we are using CipherInputStreams and CipherOutputStreams which works fine for AES/CBC/PKCS7Padding. We recently switched to AES/GCM/NoPadding. Now the encryption and decryption is inacceptable slow for files over roughly 50MB.
Debugging into the android source code, reveals the issues: https://android.googlesource.com/platform/libcore/+/master/ojluni/src/main/java/javax/crypto/CipherInputStream.java#112
This method has byte buffer "oBuffer" which is reallocated and increased by 512bits until it can hold the whole message (see line: https://android.googlesource.com/platform/libcore/+/master/ojluni/src/main/java/javax/crypto/CipherInputStream.java#121)
I am aware of the note over this method which stated that in AEAD ciphers the whole message has to be buffered. This is one issue, because we cannot hold the whole message into a memory buffer. Another issue is that the oBuffer is constantly reallocated.
Is there any solution for using GCM with a streaming API?
回答1:
Splitting the file into the parts and chaining is a solution for you.
Assume that you divide the file into n parts. Encrypt each of them with AES-GCM with the following additions. Prefix each part before encryption as follows;
tag_0 = ''
for i from 1 to n
ciphertextBlock_i, tag_i = AES-GCM( i:n || tag_i-1 || plaintextBlock_i)
- prefix each part with the part number as
i:n - prefix each part except the first one with the authentication tag of the previous part.
With these, you have now a chain that can be controlled after decryption. You can detect, additions, deletions. The order is under your control, you can send even without the order. However, you need to check the prefix.
You can also
- add the part size, and
- add the time of encryption, too if you fear from the replay attack.
来源：https://stackoverflow.com/questions/54418429/android-cipherstream-api-for-aead-ciphers-inacceptable-slow