Github user omalley commented on a diff in the pull request:
https://github.com/apache/orc/pull/278#discussion_r202470866
--- Diff: java/core/src/java/org/apache/orc/impl/InStream.java ---
@@ -173,33 +203,208 @@ private static ByteBuffer allocateBuffer(int size,
boolean isDirect) {
}
}
+ /**
+ * Manage the state of the decryption, including the ability to seek.
+ */
+ static class EncryptionState {
+ private final String name;
+ private final EncryptionAlgorithm algorithm;
+ private final Key key;
+ private final byte[] iv;
+ private final Cipher cipher;
+ private ByteBuffer decrypted;
+
+ EncryptionState(String name, StreamOptions options) {
+ this.name = name;
+ algorithm = options.algorithm;
+ key = options.key;
+ iv = options.iv;
+ cipher = algorithm.createCipher();
+ }
+
+ /**
+ * We are seeking to a new range, so update the cipher to change the IV
+ * to match. This code assumes that we only support encryption in CTR
mode.
+ * @param offset where we are seeking to in the stream
+ */
+ void changeIv(long offset) {
+ int blockSize = cipher.getBlockSize();
+ long encryptionBlocks = offset / blockSize;
--- End diff --
No, we always start decryption on a block boundary and throw away the
leading bytes. See InStream.EncryptionState.changeIv(long offset) and the
"extra" and "wasted" variables.
---
